Re: [kbuild-devel] Re: Rename all derived CONFIG variables
On Mon, 12 Mar 2001, Keith Owens wrote: > On Mon, 12 Mar 2001 03:53:07 -0500, > "Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > >But if we're going to push Linus and the kernel crew to switch to > >CML2, then why invite the political tsuris of trying to get a large > >patch into 2.4 now? Maybe I'm missing something here, but this doesn't > >seem necessary to me. > > The derived config variables should be in a separate name space, > whether config is CML1 or CML2. This patch does it for CML1. I don't think this makes sense at all. The derivation of the config values is the concern of the configuration system, not the code. Consider something like CONFIG_CPU_HAS_FEATURE_FOO that might currently be derived from CONFIG_CPU_BAR but may in the future be made independent. Or vice-versa. Your proposed name-change means additional maintenance headache and gets you nothing that you couldn't get by simply including whatever script you wrote to deduce the dependencies. Such a script would at least be able to tell you what a variable was derived from. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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] Re: Rename all derived CONFIG variables
On Mon, 12 Mar 2001, Keith Owens wrote: On Mon, 12 Mar 2001 03:53:07 -0500, "Eric S. Raymond" [EMAIL PROTECTED] wrote: But if we're going to push Linus and the kernel crew to switch to CML2, then why invite the political tsuris of trying to get a large patch into 2.4 now? Maybe I'm missing something here, but this doesn't seem necessary to me. The derived config variables should be in a separate name space, whether config is CML1 or CML2. This patch does it for CML1. I don't think this makes sense at all. The derivation of the config values is the concern of the configuration system, not the code. Consider something like CONFIG_CPU_HAS_FEATURE_FOO that might currently be derived from CONFIG_CPU_BAR but may in the future be made independent. Or vice-versa. Your proposed name-change means additional maintenance headache and gets you nothing that you couldn't get by simply including whatever script you wrote to deduce the dependencies. Such a script would at least be able to tell you what a variable was derived from. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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] Re: Rename all derived CONFIG variables
> The derived config variables should be in a separate name space, > whether config is CML1 or CML2. This patch does it for CML1. Why ? The only tool that needs to seperate them is the config check script and that has enough information to deduce them - 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: Rename all derived CONFIG variables
> Not only do I think that CONFIG_xxx_DERIVED needlessly extends the name > of derived vars, but your patch does not belong in a stable series. > Derived CONFIG_xxx vars are likely to be referenced in source. Changing > those vars in the middle of a stable series pointlessly breaks external > source code. > > I hope vendors don't start applying this patch... I dont see them doing that. I'm not going to be applying it for -ac either. It would appear that this is a wrong way to fix the problem. The config option checker should be scanning for define_*** options and removing them from its output - 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: Rename all derived CONFIG variables
On Mon, 12 Mar 2001, Keith Owens wrote: > In 2.4.2-ac18 there are 130 CONFIG options that are always derived from > other options, the user has no control over them. It is useful for the > kernel build process to know which variables are derived and which > variables the user can control. If it's useful for the (future?) kernel build process to know this, shouldn't that config/build process derive this info itself, rather than going by _DERIVED on the end of a CONFIG_ name? And aren't there many CONFIG_ options (I think your "always" implies so) which are derived in some cases (e.g. on some architectures), specified by the user in others? Those don't get to be called _DERIVED though often they are derived. And easy to imagine an option always derived in one release, sometimes specified in the next, always derived in the next... Yes, we can keep on editing the CONFIG_ name in all sources affected, but I just don't think the name should be trying to carry that info. Hugh - 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: Rename all derived CONFIG variables
On Mon, Mar 12, 2001 at 06:03:22PM +1100, Keith Owens wrote: > In 2.4.2-ac18 there are 130 CONFIG options that are always derived from > other options, the user has no control over them. It is useful for the > kernel build process to know which variables are derived and which > variables the user can control. There are also 6 CONFIG options that Yes, it is. However, I don't see a reason to use a different namespace for them. At least some of the options below might become non-derived options again, and having that knowledge spread out over most of the kernel tree doesn't make any sense to me. - 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] Re: Rename all derived CONFIG variables
On Mon, 12 Mar 2001 03:53:07 -0500, "Eric S. Raymond" <[EMAIL PROTECTED]> wrote: >But if we're going to push Linus and the kernel crew to switch to >CML2, then why invite the political tsuris of trying to get a large >patch into 2.4 now? Maybe I'm missing something here, but this doesn't >seem necessary to me. The derived config variables should be in a separate name space, whether config is CML1 or CML2. This patch does it for CML1. - 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] Re: Rename all derived CONFIG variables
Peter Samuelson <[EMAIL PROTECTED]>: > > In 2.4.2-ac18 there are 130 CONFIG options that are always derived > > from other options, the user has no control over them. > > I've thought about these before ... but never got around to doing > anything about them. I agree they should have a separate namespace. > > However, I would vote the for namespace CONFIG__* rather than > CONFIG_*_DERIVED. As Jeff noted, _DERIVED is quite a mouthful to type, > and CONFIG__* seems all-around less intrusive. How much point is there to this kind of cleanup in CML1, really? After the fall LinuxWorld meeting I was under the impression that mec and the rest of the build team were planning to support switching to CML2 for the 2.5 series. If that's not true, someone should clue me in *now*, before I go misrepresenting anybody's position at the 2.5 kickoff workshop. But if we're going to push Linus and the kernel crew to switch to CML2, then why invite the political tsuris of trying to get a large patch into 2.4 now? Maybe I'm missing something here, but this doesn't seem necessary to me. -- http://www.tuxedo.org/~esr/">Eric S. Raymond The IRS has become morally corrupted by the enormous power which we in Congress have unwisely entrusted to it. Too often it acts like a Gestapo preying upon defenseless citizens. -- Senator Edward V. Long - 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: Rename all derived CONFIG variables
[kaos] > In 2.4.2-ac18 there are 130 CONFIG options that are always derived > from other options, the user has no control over them. I've thought about these before ... but never got around to doing anything about them. I agree they should have a separate namespace. However, I would vote the for namespace CONFIG__* rather than CONFIG_*_DERIVED. As Jeff noted, _DERIVED is quite a mouthful to type, and CONFIG__* seems all-around less intrusive. 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: Rename all derived CONFIG variables
[kaos] In 2.4.2-ac18 there are 130 CONFIG options that are always derived from other options, the user has no control over them. I've thought about these before ... but never got around to doing anything about them. I agree they should have a separate namespace. However, I would vote the for namespace CONFIG__* rather than CONFIG_*_DERIVED. As Jeff noted, _DERIVED is quite a mouthful to type, and CONFIG__* seems all-around less intrusive. 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] Re: Rename all derived CONFIG variables
Peter Samuelson [EMAIL PROTECTED]: In 2.4.2-ac18 there are 130 CONFIG options that are always derived from other options, the user has no control over them. I've thought about these before ... but never got around to doing anything about them. I agree they should have a separate namespace. However, I would vote the for namespace CONFIG__* rather than CONFIG_*_DERIVED. As Jeff noted, _DERIVED is quite a mouthful to type, and CONFIG__* seems all-around less intrusive. How much point is there to this kind of cleanup in CML1, really? After the fall LinuxWorld meeting I was under the impression that mec and the rest of the build team were planning to support switching to CML2 for the 2.5 series. If that's not true, someone should clue me in *now*, before I go misrepresenting anybody's position at the 2.5 kickoff workshop. But if we're going to push Linus and the kernel crew to switch to CML2, then why invite the political tsuris of trying to get a large patch into 2.4 now? Maybe I'm missing something here, but this doesn't seem necessary to me. -- a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a The IRS has become morally corrupted by the enormous power which we in Congress have unwisely entrusted to it. Too often it acts like a Gestapo preying upon defenseless citizens. -- Senator Edward V. Long - 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] Re: Rename all derived CONFIG variables
On Mon, 12 Mar 2001 03:53:07 -0500, "Eric S. Raymond" [EMAIL PROTECTED] wrote: But if we're going to push Linus and the kernel crew to switch to CML2, then why invite the political tsuris of trying to get a large patch into 2.4 now? Maybe I'm missing something here, but this doesn't seem necessary to me. The derived config variables should be in a separate name space, whether config is CML1 or CML2. This patch does it for CML1. - 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: Rename all derived CONFIG variables
On Mon, Mar 12, 2001 at 06:03:22PM +1100, Keith Owens wrote: In 2.4.2-ac18 there are 130 CONFIG options that are always derived from other options, the user has no control over them. It is useful for the kernel build process to know which variables are derived and which variables the user can control. There are also 6 CONFIG options that Yes, it is. However, I don't see a reason to use a different namespace for them. At least some of the options below might become non-derived options again, and having that knowledge spread out over most of the kernel tree doesn't make any sense to me. - 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: Rename all derived CONFIG variables
On Mon, 12 Mar 2001, Keith Owens wrote: In 2.4.2-ac18 there are 130 CONFIG options that are always derived from other options, the user has no control over them. It is useful for the kernel build process to know which variables are derived and which variables the user can control. If it's useful for the (future?) kernel build process to know this, shouldn't that config/build process derive this info itself, rather than going by _DERIVED on the end of a CONFIG_ name? And aren't there many CONFIG_ options (I think your "always" implies so) which are derived in some cases (e.g. on some architectures), specified by the user in others? Those don't get to be called _DERIVED though often they are derived. And easy to imagine an option always derived in one release, sometimes specified in the next, always derived in the next... Yes, we can keep on editing the CONFIG_ name in all sources affected, but I just don't think the name should be trying to carry that info. Hugh - 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] Re: Rename all derived CONFIG variables
The derived config variables should be in a separate name space, whether config is CML1 or CML2. This patch does it for CML1. Why ? The only tool that needs to seperate them is the config check script and that has enough information to deduce them - 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: Rename all derived CONFIG variables
Not only do I think that CONFIG_xxx_DERIVED needlessly extends the name of derived vars, but your patch does not belong in a stable series. Derived CONFIG_xxx vars are likely to be referenced in source. Changing those vars in the middle of a stable series pointlessly breaks external source code. I hope vendors don't start applying this patch... I dont see them doing that. I'm not going to be applying it for -ac either. It would appear that this is a wrong way to fix the problem. The config option checker should be scanning for define_*** options and removing them from its output - 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: Rename all derived CONFIG variables
Keith Owens wrote: > > In 2.4.2-ac18 there are 130 CONFIG options that are always derived from > other options, the user has no control over them. It is useful for the > kernel build process to know which variables are derived and which > variables the user can control. There are also 6 CONFIG options that > are not used anywhere. > > ftp://ftp.ocs.com.au/pub/2.4.2-ac18-config_derived.gz > > is a 583,904 byte (unzipped) 114,291 (gzipped) patch which removes the > unused variables and renames the 130 derived variables from CONFIG_FOO > to CONFIG_FOO_DERIVED. The affected variables are :- Not only do I think that CONFIG_xxx_DERIVED needlessly extends the name of derived vars, but your patch does not belong in a stable series. Derived CONFIG_xxx vars are likely to be referenced in source. Changing those vars in the middle of a stable series pointlessly breaks external source code. I hope vendors don't start applying this patch... Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - 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: Rename all derived CONFIG variables
Keith Owens wrote: In 2.4.2-ac18 there are 130 CONFIG options that are always derived from other options, the user has no control over them. It is useful for the kernel build process to know which variables are derived and which variables the user can control. There are also 6 CONFIG options that are not used anywhere. ftp://ftp.ocs.com.au/pub/2.4.2-ac18-config_derived.gz is a 583,904 byte (unzipped) 114,291 (gzipped) patch which removes the unused variables and renames the 130 derived variables from CONFIG_FOO to CONFIG_FOO_DERIVED. The affected variables are :- Not only do I think that CONFIG_xxx_DERIVED needlessly extends the name of derived vars, but your patch does not belong in a stable series. Derived CONFIG_xxx vars are likely to be referenced in source. Changing those vars in the middle of a stable series pointlessly breaks external source code. I hope vendors don't start applying this patch... Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - 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/
