Re: [kbuild-devel] [PATCH] automatic multi-part link rules (fwd)
[Kai Germaschewski] > However, I don't think it's hard to verify that my patch works as > well, it's about ten lines added to Rules.make. It's particularly > easy to verify that it doesn't change behavior for objects listed in > $(list-multi) at all. Yes, we can say this, but people are right to be paranoid. Remember that the first version of your patch (several months ago) required a particular version of GNU Make I submitted a cleanup patch for 2.2.18pre that was 100% safe in that it just made use of a script that was already in the tree (scripts/kwhich). But sure enough, it broke for users of older Red Hat installations who were still on bash 1.x. It seems scripts/kwhich hadn't been used that way before, so nobody had noticed that it didn't work with bash 1. That said, I think your current version is in fact bug-free and if it were up to me I would put it in the tree. But I also understand why others are hesitant to trust it. The bugs it fixes are fairly minor, after all. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] [PATCH] automatic multi-part link rules (fwd)
On Tue, 1 May 2001, J . A . Magallon wrote: > On 05.01 Keith Owens wrote: > > > > The patch appears to work but is it worth applying now? The existing > > 2.4 rules work fine and the entire kbuild system will be rewritten for > > 2.5, including the case you identified here. It struck me as a decent > > change but for no benefit and, given that the 2.4 kbuild system is so > > fragile, why not live with something we know works until 2.5 is > > available? Well, yes, that's an argument. However, I don't think it's hard to verify that my patch works as well, it's about ten lines added to Rules.make. It's particularly easy to verify that it doesn't change behavior for objects listed in $(list-multi) at all. > We will have to live with 2.4 until 2.6, 'cause 2.5 will not be stable. > 2.4 will be the stable and non "brain damaged" kernel in distros. > So every thing that can make 2.4 more clean, better. Think in 2.4.57, > and we still are in 4. And feature backports, and new drivers... > The 2.5 rewrite is not excuse. The knowledge on the actual state, yes. Yes, 2.4 will be around for a long time from now. Of course, no experimental changes should be done now, but cleanup patches are applied all the time now. Or are you arguing that we shouldn't include patches which fix the compiler warnings either, just because it's proven that the current behavior works? Anyway, I also have the additional argument that the patches fixes at least theoretical bugs, because it adds flags handling for the link rules. I don't know if it ever happens, but one can imagine a case where foo-objs = foo1.o foo2.o, or foo-objs = foo1.o foo2.o foo3.o, respectively, depending on some config option. So if you go from the latter config to the former and rebuild, foo.o won't get relinked, you end up with the old version. Also, the patch allows you to rewrite e.g. fs/ext2/Makefile from --- obj-y:= acl.o balloc.o bitmap.o dir.o file.o fsync.o ialloc.o inode.o \ ioctl.o namei.o super.o symlink.o obj-m:= $(O_TARGET) --- to --- obj-$(CONFIG_EXT2_FS) += ext2.o ext2-objs := acl.o balloc.o bitmap.o dir.o file.o fsync.o \ ialloc.o inode.o ioctl.o namei.o super.o symlink.o --- which fixes another fragile aspect of the current Makefiles, which you complained about yourself: make SUBDIRS=fs/ext2 is currently broken w.r.t to compilation flags. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] [PATCH] automatic multi-part link rules (fwd)
On Tue, 1 May 2001, J . A . Magallon wrote: On 05.01 Keith Owens wrote: The patch appears to work but is it worth applying now? The existing 2.4 rules work fine and the entire kbuild system will be rewritten for 2.5, including the case you identified here. It struck me as a decent change but for no benefit and, given that the 2.4 kbuild system is so fragile, why not live with something we know works until 2.5 is available? Well, yes, that's an argument. However, I don't think it's hard to verify that my patch works as well, it's about ten lines added to Rules.make. It's particularly easy to verify that it doesn't change behavior for objects listed in $(list-multi) at all. We will have to live with 2.4 until 2.6, 'cause 2.5 will not be stable. 2.4 will be the stable and non brain damaged kernel in distros. So every thing that can make 2.4 more clean, better. Think in 2.4.57, and we still are in 4. And feature backports, and new drivers... The 2.5 rewrite is not excuse. The knowledge on the actual state, yes. Yes, 2.4 will be around for a long time from now. Of course, no experimental changes should be done now, but cleanup patches are applied all the time now. Or are you arguing that we shouldn't include patches which fix the compiler warnings either, just because it's proven that the current behavior works? Anyway, I also have the additional argument that the patches fixes at least theoretical bugs, because it adds flags handling for the link rules. I don't know if it ever happens, but one can imagine a case where foo-objs = foo1.o foo2.o, or foo-objs = foo1.o foo2.o foo3.o, respectively, depending on some config option. So if you go from the latter config to the former and rebuild, foo.o won't get relinked, you end up with the old version. Also, the patch allows you to rewrite e.g. fs/ext2/Makefile from --- obj-y:= acl.o balloc.o bitmap.o dir.o file.o fsync.o ialloc.o inode.o \ ioctl.o namei.o super.o symlink.o obj-m:= $(O_TARGET) --- to --- obj-$(CONFIG_EXT2_FS) += ext2.o ext2-objs := acl.o balloc.o bitmap.o dir.o file.o fsync.o \ ialloc.o inode.o ioctl.o namei.o super.o symlink.o --- which fixes another fragile aspect of the current Makefiles, which you complained about yourself: make SUBDIRS=fs/ext2 is currently broken w.r.t to compilation flags. --Kai - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] [PATCH] automatic multi-part link rules (fwd)
[Kai Germaschewski] However, I don't think it's hard to verify that my patch works as well, it's about ten lines added to Rules.make. It's particularly easy to verify that it doesn't change behavior for objects listed in $(list-multi) at all. Yes, we can say this, but people are right to be paranoid. Remember that the first version of your patch (several months ago) required a particular version of GNU Make I submitted a cleanup patch for 2.2.18pre that was 100% safe in that it just made use of a script that was already in the tree (scripts/kwhich). But sure enough, it broke for users of older Red Hat installations who were still on bash 1.x. It seems scripts/kwhich hadn't been used that way before, so nobody had noticed that it didn't work with bash 1. That said, I think your current version is in fact bug-free and if it were up to me I would put it in the tree. But I also understand why others are hesitant to trust it. The bugs it fixes are fairly minor, after all. Peter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] [PATCH] automatic multi-part link rules (fwd)
On Tue, 1 May 2001 01:31:20 +0200, "J . A . Magallon" <[EMAIL PROTECTED]> wrote: >On 05.01 Keith Owens wrote: >> The patch appears to work but is it worth applying now? The existing >> 2.4 rules work fine and the entire kbuild system will be rewritten for >> 2.5 > >We will have to live with 2.4 until 2.6, 'cause 2.5 will not be stable. >2.4 will be the stable and non "brain damaged" kernel in distros. >So every thing that can make 2.4 more clean, better. Think in 2.4.57, >and we still are in 4. And feature backports, and new drivers... >The 2.5 rewrite is not excuse. The knowledge on the actual state, yes. But 2.4 kbuild for multi part objects already works, there is no bug to fix or live with. 2.4 is supposed to be bug fixes only. IMHO keeping the existing boilerplate method for multi part objects in 2.4 is the safer approach, don't rock the boat. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] [PATCH] automatic multi-part link rules (fwd)
On 05.01 Keith Owens wrote: > > The patch appears to work but is it worth applying now? The existing > 2.4 rules work fine and the entire kbuild system will be rewritten for > 2.5, including the case you identified here. It struck me as a decent > change but for no benefit and, given that the 2.4 kbuild system is so > fragile, why not live with something we know works until 2.5 is > available? > We will have to live with 2.4 until 2.6, 'cause 2.5 will not be stable. 2.4 will be the stable and non "brain damaged" kernel in distros. So every thing that can make 2.4 more clean, better. Think in 2.4.57, and we still are in 4. And feature backports, and new drivers... The 2.5 rewrite is not excuse. The knowledge on the actual state, yes. -- J.A. Magallon # Let the source mailto:[EMAIL PROTECTED] # be with you, Luke... Linux werewolf 2.4.4 #1 SMP Sat Apr 28 11:45:02 CEST 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] [PATCH] automatic multi-part link rules (fwd)
On Tue, 1 May 2001 00:43:42 +0200 (CEST), Kai Germaschewski <[EMAIL PROTECTED]> wrote: >I sent this to the kbuild list about a week ago, and I received exactly >zero replies, so I'm posting to l-k now. This may mean that the idea is >totally stupid (but I'd like to know) or unquestionably good (that's what >I'd prefer :), well, maybe I'll get some feedback this time. The patch appears to work but is it worth applying now? The existing 2.4 rules work fine and the entire kbuild system will be rewritten for 2.5, including the case you identified here. It struck me as a decent change but for no benefit and, given that the 2.4 kbuild system is so fragile, why not live with something we know works until 2.5 is available? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] [PATCH] automatic multi-part link rules (fwd)
On Tue, 1 May 2001 00:43:42 +0200 (CEST), Kai Germaschewski [EMAIL PROTECTED] wrote: I sent this to the kbuild list about a week ago, and I received exactly zero replies, so I'm posting to l-k now. This may mean that the idea is totally stupid (but I'd like to know) or unquestionably good (that's what I'd prefer :), well, maybe I'll get some feedback this time. The patch appears to work but is it worth applying now? The existing 2.4 rules work fine and the entire kbuild system will be rewritten for 2.5, including the case you identified here. It struck me as a decent change but for no benefit and, given that the 2.4 kbuild system is so fragile, why not live with something we know works until 2.5 is available? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] [PATCH] automatic multi-part link rules (fwd)
On 05.01 Keith Owens wrote: The patch appears to work but is it worth applying now? The existing 2.4 rules work fine and the entire kbuild system will be rewritten for 2.5, including the case you identified here. It struck me as a decent change but for no benefit and, given that the 2.4 kbuild system is so fragile, why not live with something we know works until 2.5 is available? We will have to live with 2.4 until 2.6, 'cause 2.5 will not be stable. 2.4 will be the stable and non brain damaged kernel in distros. So every thing that can make 2.4 more clean, better. Think in 2.4.57, and we still are in 4. And feature backports, and new drivers... The 2.5 rewrite is not excuse. The knowledge on the actual state, yes. -- J.A. Magallon # Let the source mailto:[EMAIL PROTECTED] # be with you, Luke... Linux werewolf 2.4.4 #1 SMP Sat Apr 28 11:45:02 CEST 2001 i686 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] [PATCH] automatic multi-part link rules (fwd)
On Tue, 1 May 2001 01:31:20 +0200, J . A . Magallon [EMAIL PROTECTED] wrote: On 05.01 Keith Owens wrote: The patch appears to work but is it worth applying now? The existing 2.4 rules work fine and the entire kbuild system will be rewritten for 2.5 We will have to live with 2.4 until 2.6, 'cause 2.5 will not be stable. 2.4 will be the stable and non brain damaged kernel in distros. So every thing that can make 2.4 more clean, better. Think in 2.4.57, and we still are in 4. And feature backports, and new drivers... The 2.5 rewrite is not excuse. The knowledge on the actual state, yes. But 2.4 kbuild for multi part objects already works, there is no bug to fix or live with. 2.4 is supposed to be bug fixes only. IMHO keeping the existing boilerplate method for multi part objects in 2.4 is the safer approach, don't rock the boat. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/