Re: Background to the argument about CML2 design philosophy
On Tue, 22 May 2001 11:24:54 +0200,
Daniel Phillips <[EMAIL PROTECTED]> wrote:
>On Tuesday 22 May 2001 02:59, Keith Owens wrote:
>> # Not a real dependency, this checks for hand editing of .config.
>> $(KBUILD_OBJTREE)include/linux/autoconf.h: $(KBUILD_OBJTREE).config
>> @echo Your .config is newer than include/linux/autoconf.h,
>> this should not happen. @echo Always run make one of
>> "{menu,old,x}config" after manually updating .config. @/bin/false
>
>Ahem. What is wrong with revalidating it automatically? *Then* if there's a
>problem, bother the user.
Revalidate using which tool? Did the user even mean to edit .config?
This is a case where the user has to decide what to do.
-
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: Background to the argument about CML2 design philosophy
Jonathan Morton <[EMAIL PROTECTED]>: > I'm going to assume for now that CML2 saves two files - one storing a > relatively small number of symbols (which is strictly limited to those > explicitly set by the user), and one containing the full set for > consumption by the Makefiles. No, that's not the case. Would it be too much to ask that you learn how the existing language works brfore proposing improvements? -- http://www.tuxedo.org/~esr/;>Eric S. Raymond The prestige of government has undoubtedly been lowered considerably by the Prohibition law. For nothing is more destructive of respect for the government and the law of the land than passing laws which cannot be enforced. It is an open secret that the dangerous increase of crime in this country is closely connected with this. -- Albert Einstein, "My First Impression of the U.S.A.", 1921 - 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: Background to the argument about CML2 design philosophy
On Tuesday 22 May 2001 16:42, john slee wrote: > On Mon, May 21, 2001 at 10:00:07PM +0200, Urban Widmark wrote: > > On Mon, 21 May 2001, Eric S. Raymond wrote: > > > the NEW tag). That phase ended almost a month ago. Nobody who > > > has actually tried the CML2 tools more recently has reported that > > > the UI changes present any difficulty. > > > > What happened with the discussion on configurable colors in make > > menuconfig? Darkblue on black as frozen options get isn't exactly > > optimal ... at least not for my eyes. Being next to a bold, white > > text doesn't help either. > > if you don't like dark blue on black, change your terminal colours. > then you won't find it hard to read in other applications either. On the first day of my graduate course 'Advanced Topics in Computer Graphics' the professor walked in and wrote on the blackboard "Never Use Blue on Black". Yes, we had blackboards then. No, our eyes have not evolved since then. ;-) -- Daniel - 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: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] said: > I don't agree with this, since the current CML1 scheme has wierd, > unwanted and wrong dependencies already, which can't (or haven't) been > found. Since it would be put in during the 2.5.x branching, it's > expected that things will/can/should break, so I don't think there > will be any dire consequences. OK, I obviously don't expect the behaviour to be _exactly_ identical. If CML2 allows the authors' intent to be more closely adhered to, that's a good thing. But if the CML2 files exhibit behaviour which was clearly _not_ the intention of the original CML1, that is a change which should be made under separate cover. > Such as what? Do you have any examples here? The MAC/SCSI dependencies, which it seems were 'simplified' at the cost of preventing certain combinations which were unlikely but valid, and which it was possible to select with the original rules. Also of course the whole class of dependencies which people are talking about introducing for the benefit of the hypothetical Aunt Tillie. I don't know how many, if any, of this kind of changes are _actually_ made in the current CML2 rules files - what I'm saying is that there _should_ be none. Such large changes to the policy are entirely unrelated to CML2 itself, and should be discussed separately. If your response to this is "But there are no such changes, you misunderstood the MAC/SCSI dependency conversation and the Aunt Tillie stuff was all hypothetical, what are you talking about?", then good - that's precisely the answer I was after. All I'm asking for is a clear agreement that within reason, the behaviour of the CML2 rules files immediately after CML2 is merged will match the intended behaviour of the CML1 rules prior to the merge. -- dwmw2 - 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: Background to the argument about CML2 design philosophy
David> You appear to be responding to my email, yet you did not do me David> the courtesy of including me in the recipients. Should I assume David> you're asking this question of me directly, or was it a David> rhetorical question? It was more of an attempt to cutdown on the number of recipients, not any attempt to keep you out of the discussion. This time, I've left the recipients alone. David> Good. You should be prevented from creating a .config which is David> broken, and the existing CML1 rules attempt to achieve David> this. We are in agreement here, though I doubt that the CML1 ruleset really achieves this goal in any serious way. It just doesn't have the power. David> CML2 should continue to do so, and indeed should do so more David> effectively and flexibly. Agreed. David> What I fear is that such new, unwanted, dependencies may be David> introduced to the kernel -- either by accident or by deception David> -- in the large patch which introduces CML2 and converts the David> existing rules files. Subtle changes to the behaviour could David> easily go unnoticed in such a large patch. I don't agree with this, since the current CML1 scheme has wierd, unwanted and wrong dependencies already, which can't (or haven't) been found. Since it would be put in during the 2.5.x branching, it's expected that things will/can/should break, so I don't think there will be any dire consequences. David> I think you are being overly defensive. I was not saying that David> CML2 is wrong. I said that I was ambivalent about CML2, and the David> point I'm talking about is entirely irrelevant to CML2 - except David> that I'm trying to make sure that the large CML2 patch is not David> used as a vehicle for sneaking other, more contentious, changes David> into the kernel. Such as what? Do you have any examples here? David> I want to discuss those changes _separately_ once the CML2 David> issue is out of the way, because otherwise people just won't David> bother to read what I said, and will assume I'm arguing against David> CML2 itself. This is the first time you have come out and explicitly *said* what you are for and against in CML2. People need to be clear about what they are talking about. As a general question for all readers, how many are against CML2 in any shape or form? How many are like David, and don't mind CML2, but are worried about dependency issues? How many think CML2 and it's dependencies will be a step forward in kernel configuration? Thanks, John - 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: Background to the argument about CML2 design philosophy
On Tuesday 22 May 2001 02:59, Keith Owens wrote:
>
> # Not a real dependency, this checks for hand editing of .config.
> $(KBUILD_OBJTREE)include/linux/autoconf.h: $(KBUILD_OBJTREE).config
> @echo Your .config is newer than include/linux/autoconf.h,
> this should not happen. @echo Always run make one of
> "{menu,old,x}config" after manually updating .config. @/bin/false
Ahem. What is wrong with revalidating it automatically? *Then* if there's a
problem, bother the user.
"No news is good news".
--
Daniel
-
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: Background to the argument about CML2 design philosophy
On Mon, May 21, 2001 at 10:00:07PM +0200, Urban Widmark wrote: > On Mon, 21 May 2001, Eric S. Raymond wrote: > > > the NEW tag). That phase ended almost a month ago. Nobody who has > > actually tried the CML2 tools more recently has reported that the UI > > changes present any difficulty. > > What happened with the discussion on configurable colors in make > menuconfig? Darkblue on black as frozen options get isn't exactly optimal > ... at least not for my eyes. Being next to a bold, white text doesn't > help either. if you don't like dark blue on black, change your terminal colours. then you won't find it hard to read in other applications either. it's also far less effort this way... j. -- "Bobby, jiggle Grandpa's rat so it looks alive, please" -- gary larson - 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: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] said: > David> for the sake of the sanity of all concerned, do things one at a > David> time. Provide for merging into 2.5 a set of rules which > David> reproduce the existing CML1 behaviour in this respect. > Can you define what you mean here? It's not really clear to me, and I > suspect others. You appear to be responding to my email, yet you did not do me the courtesy of including me in the recipients. Should I assume you're asking this question of me directly, or was it a rhetorical question? [EMAIL PROTECTED] said: > I don't think he is introducing new modes, he's just trying to make > sure that you can't create a .config which is broken. Good. You should be prevented from creating a .config which is broken, and the existing CML1 rules attempt to achieve this. CML2 should continue to do so, and indeed should do so more effectively and flexibly. > - fear that CML2 won't let them make crazy configurations, such as an > 8-way SMP box with ISA. Can't see how CML2 would restrict this > choice myself. I do not fear that CML2 itself will prevent these 'crazy' configurations. That is why I said that the issue is entirely orthogonal to CML2. However, it would obviously be possible to introduce new dependencies to the rules files -- either CML1 or CML2 -- which do prevent such configurations. What I fear is that such new, unwanted, dependencies may be introduced to the kernel -- either by accident or by deception -- in the large patch which introduces CML2 and converts the existing rules files. Subtle changes to the behaviour could easily go unnoticed in such a large patch. I am asking that such a deception should not be attempted. The CML2 rules introduced to 2.5.n should exactly represent the behaviour of the CML1 rules in 2.5.(n-1). Changes to the policy represented within the rules files can then be presented afterwards, and should be considered entirely separate to the change in mechanism. [EMAIL PROTECTED] said: > If you run into a case where you have a config which would work, but > CML2 doesn't let you, why don't you fix the grammar instead of saying > CML2 is wrong? I think you are being overly defensive. I was not saying that CML2 is wrong. I said that I was ambivalent about CML2, and the point I'm talking about is entirely irrelevant to CML2 - except that I'm trying to make sure that the large CML2 patch is not used as a vehicle for sneaking other, more contentious, changes into the kernel. I want to discuss those changes _separately_ once the CML2 issue is out of the way, because otherwise people just won't bother to read what I said, and will assume I'm arguing against CML2 itself. -- dwmw2 - 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: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] said: David for the sake of the sanity of all concerned, do things one at a David time. Provide for merging into 2.5 a set of rules which David reproduce the existing CML1 behaviour in this respect. Can you define what you mean here? It's not really clear to me, and I suspect others. You appear to be responding to my email, yet you did not do me the courtesy of including me in the recipients. Should I assume you're asking this question of me directly, or was it a rhetorical question? [EMAIL PROTECTED] said: I don't think he is introducing new modes, he's just trying to make sure that you can't create a .config which is broken. Good. You should be prevented from creating a .config which is broken, and the existing CML1 rules attempt to achieve this. CML2 should continue to do so, and indeed should do so more effectively and flexibly. - fear that CML2 won't let them make crazy configurations, such as an 8-way SMP box with ISA. Can't see how CML2 would restrict this choice myself. I do not fear that CML2 itself will prevent these 'crazy' configurations. That is why I said that the issue is entirely orthogonal to CML2. However, it would obviously be possible to introduce new dependencies to the rules files -- either CML1 or CML2 -- which do prevent such configurations. What I fear is that such new, unwanted, dependencies may be introduced to the kernel -- either by accident or by deception -- in the large patch which introduces CML2 and converts the existing rules files. Subtle changes to the behaviour could easily go unnoticed in such a large patch. I am asking that such a deception should not be attempted. The CML2 rules introduced to 2.5.n should exactly represent the behaviour of the CML1 rules in 2.5.(n-1). Changes to the policy represented within the rules files can then be presented afterwards, and should be considered entirely separate to the change in mechanism. [EMAIL PROTECTED] said: If you run into a case where you have a config which would work, but CML2 doesn't let you, why don't you fix the grammar instead of saying CML2 is wrong? I think you are being overly defensive. I was not saying that CML2 is wrong. I said that I was ambivalent about CML2, and the point I'm talking about is entirely irrelevant to CML2 - except that I'm trying to make sure that the large CML2 patch is not used as a vehicle for sneaking other, more contentious, changes into the kernel. I want to discuss those changes _separately_ once the CML2 issue is out of the way, because otherwise people just won't bother to read what I said, and will assume I'm arguing against CML2 itself. -- dwmw2 - 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: Background to the argument about CML2 design philosophy
On Mon, May 21, 2001 at 10:00:07PM +0200, Urban Widmark wrote: On Mon, 21 May 2001, Eric S. Raymond wrote: the NEW tag). That phase ended almost a month ago. Nobody who has actually tried the CML2 tools more recently has reported that the UI changes present any difficulty. What happened with the discussion on configurable colors in make menuconfig? Darkblue on black as frozen options get isn't exactly optimal ... at least not for my eyes. Being next to a bold, white text doesn't help either. if you don't like dark blue on black, change your terminal colours. then you won't find it hard to read in other applications either. it's also far less effort this way... j. -- Bobby, jiggle Grandpa's rat so it looks alive, please -- gary larson - 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: Background to the argument about CML2 design philosophy
On Tuesday 22 May 2001 02:59, Keith Owens wrote:
# Not a real dependency, this checks for hand editing of .config.
$(KBUILD_OBJTREE)include/linux/autoconf.h: $(KBUILD_OBJTREE).config
@echo Your .config is newer than include/linux/autoconf.h,
this should not happen. @echo Always run make one of
{menu,old,x}config after manually updating .config. @/bin/false
Ahem. What is wrong with revalidating it automatically? *Then* if there's a
problem, bother the user.
No news is good news.
--
Daniel
-
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: Background to the argument about CML2 design philosophy
David You appear to be responding to my email, yet you did not do me David the courtesy of including me in the recipients. Should I assume David you're asking this question of me directly, or was it a David rhetorical question? It was more of an attempt to cutdown on the number of recipients, not any attempt to keep you out of the discussion. This time, I've left the recipients alone. David Good. You should be prevented from creating a .config which is David broken, and the existing CML1 rules attempt to achieve David this. We are in agreement here, though I doubt that the CML1 ruleset really achieves this goal in any serious way. It just doesn't have the power. David CML2 should continue to do so, and indeed should do so more David effectively and flexibly. Agreed. David What I fear is that such new, unwanted, dependencies may be David introduced to the kernel -- either by accident or by deception David -- in the large patch which introduces CML2 and converts the David existing rules files. Subtle changes to the behaviour could David easily go unnoticed in such a large patch. I don't agree with this, since the current CML1 scheme has wierd, unwanted and wrong dependencies already, which can't (or haven't) been found. Since it would be put in during the 2.5.x branching, it's expected that things will/can/should break, so I don't think there will be any dire consequences. David I think you are being overly defensive. I was not saying that David CML2 is wrong. I said that I was ambivalent about CML2, and the David point I'm talking about is entirely irrelevant to CML2 - except David that I'm trying to make sure that the large CML2 patch is not David used as a vehicle for sneaking other, more contentious, changes David into the kernel. Such as what? Do you have any examples here? David I want to discuss those changes _separately_ once the CML2 David issue is out of the way, because otherwise people just won't David bother to read what I said, and will assume I'm arguing against David CML2 itself. This is the first time you have come out and explicitly *said* what you are for and against in CML2. People need to be clear about what they are talking about. As a general question for all readers, how many are against CML2 in any shape or form? How many are like David, and don't mind CML2, but are worried about dependency issues? How many think CML2 and it's dependencies will be a step forward in kernel configuration? Thanks, John - 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: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] said: I don't agree with this, since the current CML1 scheme has wierd, unwanted and wrong dependencies already, which can't (or haven't) been found. Since it would be put in during the 2.5.x branching, it's expected that things will/can/should break, so I don't think there will be any dire consequences. OK, I obviously don't expect the behaviour to be _exactly_ identical. If CML2 allows the authors' intent to be more closely adhered to, that's a good thing. But if the CML2 files exhibit behaviour which was clearly _not_ the intention of the original CML1, that is a change which should be made under separate cover. Such as what? Do you have any examples here? The MAC/SCSI dependencies, which it seems were 'simplified' at the cost of preventing certain combinations which were unlikely but valid, and which it was possible to select with the original rules. Also of course the whole class of dependencies which people are talking about introducing for the benefit of the hypothetical Aunt Tillie. I don't know how many, if any, of this kind of changes are _actually_ made in the current CML2 rules files - what I'm saying is that there _should_ be none. Such large changes to the policy are entirely unrelated to CML2 itself, and should be discussed separately. If your response to this is But there are no such changes, you misunderstood the MAC/SCSI dependency conversation and the Aunt Tillie stuff was all hypothetical, what are you talking about?, then good - that's precisely the answer I was after. All I'm asking for is a clear agreement that within reason, the behaviour of the CML2 rules files immediately after CML2 is merged will match the intended behaviour of the CML1 rules prior to the merge. -- dwmw2 - 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: Background to the argument about CML2 design philosophy
On Tuesday 22 May 2001 16:42, john slee wrote: On Mon, May 21, 2001 at 10:00:07PM +0200, Urban Widmark wrote: On Mon, 21 May 2001, Eric S. Raymond wrote: the NEW tag). That phase ended almost a month ago. Nobody who has actually tried the CML2 tools more recently has reported that the UI changes present any difficulty. What happened with the discussion on configurable colors in make menuconfig? Darkblue on black as frozen options get isn't exactly optimal ... at least not for my eyes. Being next to a bold, white text doesn't help either. if you don't like dark blue on black, change your terminal colours. then you won't find it hard to read in other applications either. On the first day of my graduate course 'Advanced Topics in Computer Graphics' the professor walked in and wrote on the blackboard Never Use Blue on Black. Yes, we had blackboards then. No, our eyes have not evolved since then. ;-) -- Daniel - 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: Background to the argument about CML2 design philosophy
Jonathan Morton [EMAIL PROTECTED]: I'm going to assume for now that CML2 saves two files - one storing a relatively small number of symbols (which is strictly limited to those explicitly set by the user), and one containing the full set for consumption by the Makefiles. No, that's not the case. Would it be too much to ask that you learn how the existing language works brfore proposing improvements? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The prestige of government has undoubtedly been lowered considerably by the Prohibition law. For nothing is more destructive of respect for the government and the law of the land than passing laws which cannot be enforced. It is an open secret that the dangerous increase of crime in this country is closely connected with this. -- Albert Einstein, My First Impression of the U.S.A., 1921 - 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: Background to the argument about CML2 design philosophy
On Tue, 22 May 2001 11:24:54 +0200,
Daniel Phillips [EMAIL PROTECTED] wrote:
On Tuesday 22 May 2001 02:59, Keith Owens wrote:
# Not a real dependency, this checks for hand editing of .config.
$(KBUILD_OBJTREE)include/linux/autoconf.h: $(KBUILD_OBJTREE).config
@echo Your .config is newer than include/linux/autoconf.h,
this should not happen. @echo Always run make one of
{menu,old,x}config after manually updating .config. @/bin/false
Ahem. What is wrong with revalidating it automatically? *Then* if there's a
problem, bother the user.
Revalidate using which tool? Did the user even mean to edit .config?
This is a case where the user has to decide what to do.
-
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: Background to the argument about CML2 design philosophy
Urban Widmark <[EMAIL PROTECTED]>: > What happened with the discussion on configurable colors in make > menuconfig? Darkblue on black as frozen options get isn't exactly optimal > ... at least not for my eyes. Being next to a bold, white text doesn't > help either. Nobody could come up with a way to support configurable colors that didn't seem like way more trouble than it was worth. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond "...quemadmodum gladius neminem occidit, occidentis telum est." [...a sword never kills anybody; it's a tool in the killer's hand.] -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD), - 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: Background to the argument about CML2 design philosophy
On Mon, 21 May 2001 16:38:34 -0400,
John Stoffel <[EMAIL PROTECTED]> wrote:
>All that CML2 does is enforce dependencies in the configuration
>language. You can't make a .config which conflicts. Admittedly
>there's nothing stopping you from hacking it with vi after the fact,
>but why?
CML2 will not stop you hacking .config by hand. But the 2.5 makefile
rewrite will, because we have had too many bug reports caused by people
who hand edited .config, did not revalidate it and generated invalid
kernels. Yes, you can hand edit .config. No, you cannot compile until
.config has been (re-)validated.
# Not a real dependency, this checks for hand editing of .config.
$(KBUILD_OBJTREE)include/linux/autoconf.h: $(KBUILD_OBJTREE).config
@echo Your .config is newer than include/linux/autoconf.h, this should not
happen.
@echo Always run make one of "{menu,old,x}config" after manually updating
.config.
@/bin/false
And before people complain: Don't create a config that violates the CML
rules, correct the CML rules, the Makefiles and the source so .config
is valid. The kernel build requires a valid .config.
-
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: Background to the argument about CML2 design philosophy
>If you run into a case where you have a config which would work, but >CML2 doesn't let you, why don't you fix the grammar instead of saying >CML2 is wrong? Let's not confuse these two issues as well. Strongly agree. Especially since I'm pushing for an explicit recognition of the difference between a hard dependancy and a soft derivation. The latter can be over-ridden safely by someone who knows what he's after. The former will cause a miscompile. -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -END GEEK CODE BLOCK- - 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: Background to the argument about CML2 design philosophy
David> Actually, the current system has both types. As well as the David> "hard" dependencies, we also have stuff like David> CONFIG_PARTITION_ADVANCED, CONFIG_CPU_ADVANCED, David> CONFIG_FBCON_ADVANCED, CONFIG_MTD_DOCPROBE_ADVANCED, David> etc. CONFIG_EXPERIMENTAL serves a very similar purpose, too. David> These things have already been set up in the way that David> developers prefer it. *some* developers prefer it. Not all. David> CML2 allows us to be more flexible than we were before, and David> that can be a good thing when used in moderation. But please, David> for the sake of the sanity of all concerned, do things one at a David> time. Provide for merging into 2.5 a set of rules which David> reproduce the existing CML1 behaviour in this respect. Can you define what you mean here? It's not really clear to me, and I suspect others. David> Eric, if you want to make further changes later to introduce David> new 'modes' for kernel configuration, that's an entirely David> separate issue. Please don't confuse the issue by trying to do David> it at the same time as introducing CML2. I don't think he is introducing new modes, he's just trying to make sure that you can't create a .config which is broken. Part of my complaint early on was that it would just barf on a config it thought wasn't legall, and just drop me to the 'vi' level. I don't think this is acceptable because you (CML2 or CML) should be able to prompt the user for a suggested fix. David> CONFIG_AUNT_TILLIE does not require CML2. Correct. David> CML2 does not require CONFIG_AUNT_TILLIE. Correct. And never has offered it either! David> Let's not talk about CONFIG_AUNT_TILLIE any more, or change the David> existing behaviour of config options to make that the default, David> until we've settled the discussion about CML2. I think it comes down to people who just want one or more of: - the existing interface of vi .config; make oldconfig - fear that CML2 won't let them make crazy configurations, such as an 8-way SMP box with ISA. Can't see how CML2 would restrict this choice myself. - Don't want to install python 2.x for a kernel upgrade. - fear that some configuration corner case will be handled wrong for a strange (read not common) system config. All that CML2 does is enforce dependencies in the configuration language. You can't make a .config which conflicts. Admittedly there's nothing stopping you from hacking it with vi after the fact, but why? If you run into a case where you have a config which would work, but CML2 doesn't let you, why don't you fix the grammar instead of saying CML2 is wrong? Let's not confuse these two issues as well. John - 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: Background to the argument about CML2 design philosophy
On Mon, 21 May 2001, Eric S. Raymond wrote: > the NEW tag). That phase ended almost a month ago. Nobody who has > actually tried the CML2 tools more recently has reported that the UI > changes present any difficulty. What happened with the discussion on configurable colors in make menuconfig? Darkblue on black as frozen options get isn't exactly optimal ... at least not for my eyes. Being next to a bold, white text doesn't help either. > CML2 drops its configuration results in the same place, in the same > formats, as CML1. So you should in fact be able to type `make menuconfig' > and `make oldconfig' with good results. Have you actually tried this? It works for me, but anyone testing this should know that the CML2 tools read "config.out" if it finds one. So people that do things like: make mrproper ; cp ../.config-2.4 .config ; make oldconfig will have to change to copying config.out instead. Doing like this sort of works* if there is no config.out, otherwise it does not (as it uses the config.out). Saying that the config result ends up in the same place and same format is somewhat misleading, you do get a copy in the CML1 output format but the tools doesn't care about that if it can find a file in the new format. *) "Sort of works", since doing like I do will cause you to get a lot of questions that you have already answered. That appears to be a one-time problem as 'oldconfig' does not read "# CONFIG_FOO is not set" as "no". Would be nice if it did. make mrproper doesn't remove config.out. It should since that's what it does with .config* files. Not sure if it should remove the rules.out file also, but I think it should as the idea(?) with mrproper is to clean up anything that is generated. /Urban - 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: Background to the argument about CML2 design philosophy
On 05/21/2001 at 12:58:57 [EMAIL PROTECTED] wrote: >CML2 drops its configuration results in the same place, in the same >formats, as CML1. So you should in fact be able to type `make menuconfig' >and `make oldconfig' with good results. Have you actually tried this? No, I haven't tried it yet. I usually wait for things like this to be included in Linus' or Alan's kernels before trying them. In this case, I might have tried it by now but I only have Python 1.5.2 on my system and don't want to upgrade it until/unless it's absolutely necessary. So I probably won't see CML2 until Linus puts it in 2.5. My comments have been based on your descriptions of it on lkml. Wayne - 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: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] <[EMAIL PROTECTED]>: > Speaking from the perspective of a user of the CML tools, rather > than as a developer, all I've been trying to say is this: When I > type "make menuconfig" or "make oldconfig" in the future, I want to > see the same interface and the same results that I've always seen, > because it's always worked for me in the past. Visual details will differ, but I've been careful about maintaining functional compatibility. There was a phase of the development during which I was mostly processing feature requests from people who wanted features of the old system that I had not properly understood (such as the NEW tag). That phase ended almost a month ago. Nobody who has actually tried the CML2 tools more recently has reported that the UI changes present any difficulty. CML2 drops its configuration results in the same place, in the same formats, as CML1. So you should in fact be able to type `make menuconfig' and `make oldconfig' with good results. Have you actually tried this? -- http://www.tuxedo.org/~esr/;>Eric S. Raymond The right of the citizens to keep and bear arms has justly been considered as the palladium of the liberties of a republic; since it offers a strong moral check against usurpation and arbitrary power of rulers; and will generally, even if these are successful in the first instance, enable the people to resist and triumph over them." -- Supreme Court Justice Joseph Story of the John Marshall Court - 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: Background to the argument about CML2 design philosophy
On 05/21/2001 at 05:04:40 AM [EMAIL PROTECTED] wrote: >See, I've already written off the chronic bellyachers. Since I can't >please them without scrapping the whole plan, I'm going to ignore >them. In particular, anybody who repeated "fsck Python..." after Linus >ruled that Python is not an issue and Greg Banks announced the C >implementation of CML2 has got a sufficiently severe case of >rectocranial insertion that they've defined themselves out of the >conversation. I probably qualify as one of the bellyachers. If so, I apologize. It was not my intention to disparage the work of Eric or anyone else involved in this project. Speaking from the perspective of a user of the CML tools, rather than as a developer, all I've been trying to say is this: When I type "make menuconfig" or "make oldconfig" in the future, I want to see the same interface and the same results that I've always seen, because it's always worked for me in the past. It really doesn't matter to me if, down underneath, this is being done by CML1, CML2, or a little man in my computer who slaughters chickens and reads their entrails for omens to determine dependencies. Right now I can grab a new -pre or -ac patch, use oldconfig, and have a compile going in a few minutes, without knowing or caring about the details of the config process. In the rare case that a patch breaks an existing driver, it takes only a couple of minutes with menuconfig to disable that driver and compile without it, and then put it back in when it's fixed. And when, every once in a great while, I decide to scrap my .config and start over, I can fly through all the menuconfig options very quickly and make my customary selections almost without thinking about it. I just want to be able to keep using the tools in this way. If that's not going to be possible... well, I'll adapt. But from my point of view, learning a new set of tools just to keep doing the same things I've always done isn't a pleasant prospect. I understand that changes may be necessary to meet others' needs, but I'd like to see those changes made without affecting the way my own needs are met. I'm off my soapbox now and won't bellyache about it any further. Wayne - 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: Background to the argument about CML2 design philosophy
> > 2) Have a HACKERS submenu system which contains all the derivations > > that could *possibly* be un-defaulted, and allow our intrepid hacker > > to explicitly force each to a value or leave unset. > > I prefer the former, which is how it's already implemented in CML1. Its called Debugging in CML1 in -ac for a reason btw. Because its called debugging I get plenty of reports that start "I dont know much about this but I turned on all the debugging options and now instead of hanging it says Oops 0xA5A5A5A5 ..." which are a lot more useful. Names matter a lot - 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: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] said: > Having now briefly looked at the language constructs first-hand, I > can see two ways to go about this: > 1) Have a HACKER symbol which unsuppresses the "unusual" options, and > suppresses the "generalised" ones > 2) Have a HACKERS submenu system which contains all the derivations > that could *possibly* be un-defaulted, and allow our intrepid hacker > to explicitly force each to a value or leave unset. I prefer the former, which is how it's already implemented in CML1. But the discussion of this is entirely unrelated to the discussion of CML2, and changes along these lines must not be forced into the kernel with the CML2 patch. If ESR is going to sneak policy changes into the kernel with the CML2 mechanism patch, I'm sure we all have patches we'd like him to add to it too, because we don't want to have to justify them on their own. :) -- dwmw2 - 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: Background to the argument about CML2 design philosophy
>> order to hold down ruleset complexity and simplify the user >> experience. The cost of deciding that the answer to that question is > >The user experience can be simplified by a NOVICE/EASY/SANE_DEFAULTS >option, and perhaps a HACKER option for the really strange >but _theoretically_ ok stuff. Having now briefly looked at the language constructs first-hand, I can see two ways to go about this: 1) Have a HACKER symbol which unsuppresses the "unusual" options, and suppresses the "generalised" ones (like: "build all the sound drivers for my hardware, as modules"). This is kinda how it would be implemented in CML1, cf. EXPERIMENTAL. 2) Have a HACKERS submenu system which contains all the derivations that could *possibly* be un-defaulted, and allow our intrepid hacker to explicitly force each to a value or leave unset. Leaving unset means the derivation holds, forcing it to a value will explicitly enable or disable the option along with any hard dependencies. Head this submenu system with a big banner that says "FOR EXPERTS ONLY", or suppress it using an "Experts" switch. Is there already a language construct to support the difference between a "derivation" and a "dependency"? Yes, it's the difference between "unless FOO==n default BAR==y" and "require FOO!=n implies BAR==y" respectively (or something to that effect, if my syntax is wrong flame gently please!). With that in mind, the front-end UI could implement Option 2 easily, by presenting a mode which automatically collects defaulted but otherwise hidden symbols, and reveals them to the user when set to "hacker" mode. I'm going to assume for now that CML2 saves two files - one storing a relatively small number of symbols (which is strictly limited to those explicitly set by the user), and one containing the full set for consumption by the Makefiles. If this is the case, then if a "hacker" type switches something explicitly then it'll stay there even if the default changes for that option in a future kernel. Meanwhile, Aunt Tillie gets the changed default option applied with no extra effort. "make oldconfig" might as well be a thing of the past for certain purposes, although it should still be kept as a way of reminding people what the new options are. Incidentally, in this scenario, if we have "enable driver for device FOOBAR [NEW] [y/m/N]:" then pressing Return should *not* mark the symbol as "explicitly set" but left alone because "user accepted the default". If they pressed "N", then that has the same effect but is saved explicitly for future kernels, regardless of any defaults change for that option. Hope this makes sense and I'm not being a stark raving loonie... -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -END GEEK CODE BLOCK- - 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: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] said: > I don't think there is a "less contentious" part. The same people who > bitched about the engine are now bitching about the changes I'm > contemplating in the rulesfiles. It seems clear to me that their > attitude, in general, has little to do with technical specifics of the > engine or rulesets and everything to do with resistance to change in > general and fear of losing control and/or hard-won implicit knowledge > about the old system. No. I didn't bitch (much) about CML2 - I'm fairly ambivalent. But I absolutely object to _unconditionally_ dumbing down the config options, because it would hide options which I would frequently want to enable. Introduce new novice modes if you wish - that seems sensible - but do not reduce the functionality and flexibility of configuration which is currently available. Any simplifications you make _must_ be dependent on the novice mode, and the default mode should allow the same choices as the current rules. More importantly, do not attempt to force through this change in policy by sneaking it into the 2.5.1 CML2 patch which introduces the new mechanism. The two are entirely orthogonal, and should remain separate. [EMAIL PROTECTED] said: > I'm going to give Linus the same installation kit the people working > with CML2 have now. That will include both the CML2 engine and the > rulesfiles. Fine. What I'm asking is that you ensure that the CML2 rulesfiles at the time of the merge implement the dependencies present in the CML1 rulesfiles immediately prior to the merge. If you want to work on the change of policy right now, before CML2 is merged, then go ahead and do it in CML1. It's not difficult. The first step is to make CONFIG_*_ADVANCED depend on CONFIG_EXPERT, for example. Then get those changes merged into 2.5 before you merge CML2 - and you still keep the CML2 after the merge equivalent to the CML1 immediately before the merge. Otherwise, have patience and do it after CML2 is merged. All I'm asking is that you refrain from confusing the change in mechanism with the change in policy. That's not an unreasonable request, now is it? -- dwmw2 - 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: Background to the argument about CML2 design philosophy
David Woodhouse <[EMAIL PROTECTED]>: > Because it is evidently confusing the issue. Perhaps because it sounds like > you were intending to feed Linus large patches for 2.5.[12] which effect > _both_ changes. I'm going to give Linus the same installation kit the people working with CML2 have now. That will include both the CML2 engine and the rulesfiles. > Have patience - let the less contentious part of CML2 go in first, and then > we can deal with the other stuff later, once CML2 has been accepted (however > grudgingly in some cases) by developers. I don't think there is a "less contentious" part. The same people who bitched about the engine are now bitching about the changes I'm contemplating in the rulesfiles. It seems clear to me that their attitude, in general, has little to do with technical specifics of the engine or rulesets and everything to do with resistance to change in general and fear of losing control and/or hard-won implicit knowledge about the old system. I can sympathize with their upset, but I don't intend to let it stop me. And since I'm going to have these people angry at me unless I give up entirely, I figure I have little to lose by steaming ahead full. > > The engine is working. Why is it not yet time to discuss ruleset design > > and modes? > > For a man who claims to hack social systems, that's an incredibly naïve > question. You think so, eh? Heh. Experience has taught me that sometimes hacking social systems requires a certain amount of sheer bloodymindedness. See, I've already written off the chronic bellyachers. Since I can't please them without scrapping the whole plan, I'm going to ignore them. In particular, anybody who repeated "fsck Python..." after Linus ruled that Python is not an issue and Greg Banks announced the C implementation of CML2 has got a sufficiently severe case of rectocranial insertion that they've defined themselves out of the conversation. Instead I'll take my cues from people like you and Ray Knight and Tom Rini and Alan Cox and Martin Schwidefsky who are actually offering help and constructive criticism. (Arjan de Ven is trying but he's not up to speed on the language yet.) I trust you've noticed by now that I *do* listen very carefully in that situation, and I follow up with questions when I'm not sure what people are trying to tell me. I'll keep doing that. Eventually the bellyachers may get a message about what kind of behavior gains them influence and what kind loses them influence. That's a social-systems hack of a sort ;-). -- http://www.tuxedo.org/~esr/;>Eric S. Raymond I don't like the idea that the police department seems bent on keeping a pool of unarmed victims available for the predations of the criminal class. -- David Mohler, 1989, on being denied a carry permit in NYC - 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: Background to the argument about CML2 design philosophy
"Eric S. Raymond" wrote: > > To reduce the problem further, I looked for symbols with missing > entries that I could turn into derivations, eliminating their > questions and the requirement for a help entry. Adding help entries is nice. But please don't go around making "unlikely" choices unconditional in order to avoid writing help text. Leaving the help blank for such questions is better than eliminating the question. [...] > By doing this I killed two birds with one stone -- got rid of some holes > in Configure.help and (more importantly) moved the configuration experience > away from low-level, hardware-oriented questions towards where I think it > ought to be. That is, you specify a platform and the services you want and > the ruleset computes the low-level facilities to be linked in. > > 3. The MVME derivations are correct *if* (and only if) you agree to ignore > the possibility that somebody could want to ignore the onboard hardware, > plug outboard disk or Ethernet cards into the VME-bus connector, and > do something like running SCSI-over-ATAPI to the outboard device. > (I missed these possibilities when I wrote the derivations.) > > I used case 3 to explore a touchy question about design philosophy, which > is really what caused all hell to break loose. The question is this: > holding down configuration complexity is a good thing, but supporting > all hardware configurations that are conceivably possible is also a good > thing. How should we trade these good things off against one another? I'd say support all possible configurations that is supposed to work. You never know what someone might want to make out of spare parts and dusty old things. Particularly, not compiling (or modularizing) the driver for a built-in device is always a valid way of saving memory. I don't compile IDE on my home pc, because all my devices are scsi. And the built-in floppy controller is modularized because it is so rarely used. Why give it permanent unswappable memory? Your trade-off considerations should be wether "odd but possible" choices belong in an EXPERT category or if they should be there for everybody. Don't consider eliminating something that would work. Of course you don't have to worry too much about help texts for the expert stuff - let the experts add that themselves if you don't want to write for fringe cases. > The MVME situation is an almost perfect test case, because while > breaking the assumption behind that derivation is physically possible > it would be a rather perverse thing to do. The VME147 is an old > design, dating from 1988; it's long since been superseded by MPCxxx > SBCs based on the PowerPC that have a better processor, lower power > consumption, and more on-board peripheral hardware. IDE/ATAPI didn't > exist during most of its design lifetime, and the only way anyone is > ever going to hook an outboard device to one of these puppies again > is if some hacker pulls a dusty one off a shelf for some garage project. Hackers get things like this for free when companies get rid of them, then turns them into mp3 players or hobby device controllers. > So the real question here is whether it is ever acceptable to say that > a possible configuration is just silly and ruleset will ignore it, in Maybe it is acceptable to say something is too silly. You have to come up with a better example though. People may definitely want to not have a driver, or make a module instead of compiled-in. And they may want to not use the built-in device because they use something better. Like a fast ethernet connected to that old vme box because the net they connect to is fast even though the box may be too weak to really take advantage of it. Or wide scsi instead of the built-in thing. > order to hold down ruleset complexity and simplify the user > experience. The cost of deciding that the answer to that question is The user experience can be simplified by a NOVICE/EASY/SANE_DEFAULTS option, and perhaps a HACKER option for the really strange but _theoretically_ ok stuff. > "yes, sometimes" is that on rare occasions like this one you might > have to haul out a text editor to tweak something in your config. But > the cost of deciding that the answer is "no" will be some pretty > serious complexity headaches both in the configuration user experience > and (down the road) in the maintainability of the ruleset. If EXPERT options makes it too complex, consider having some rules that are advisory only. The debian packaging system has both absolute dependancies, and "suggestions". Consider: suggest MVME16x_SCC from MVME16x & SERIAL which means that someone who turns on MVME16x_SCC and SERIAL get MVME16x_SCC turned on when they do so. But the choice is visible and it is possible for the user to turn it off at will. Maybe shown in a different color or with some other hint that it is a defaulted but overrideable thing. Configuration gets simple for the vast amount of
Re: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] said: > What discussion is that? Unless Linus has changed his mind and I > don't know about it, CML2 is going in between 2.5.1 and 2.5.2. Because it is evidently confusing the issue. Perhaps because it sounds like you were intending to feed Linus large patches for 2.5.[12] which effect _both_ changes. Have patience - let the less contentious part of CML2 go in first, and then we can deal with the other stuff later, once CML2 has been accepted (however grudgingly in some cases) by developers. > The engine is working. Why is it not yet time to discuss ruleset design > and modes? For a man who claims to hack social systems, that's an incredibly naïve question. -- dwmw2 - 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: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] said: What discussion is that? Unless Linus has changed his mind and I don't know about it, CML2 is going in between 2.5.1 and 2.5.2. Because it is evidently confusing the issue. Perhaps because it sounds like you were intending to feed Linus large patches for 2.5.[12] which effect _both_ changes. Have patience - let the less contentious part of CML2 go in first, and then we can deal with the other stuff later, once CML2 has been accepted (however grudgingly in some cases) by developers. The engine is working. Why is it not yet time to discuss ruleset design and modes? For a man who claims to hack social systems, that's an incredibly naïve question. -- dwmw2 - 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: Background to the argument about CML2 design philosophy
Eric S. Raymond wrote: To reduce the problem further, I looked for symbols with missing entries that I could turn into derivations, eliminating their questions and the requirement for a help entry. Adding help entries is nice. But please don't go around making unlikely choices unconditional in order to avoid writing help text. Leaving the help blank for such questions is better than eliminating the question. [...] By doing this I killed two birds with one stone -- got rid of some holes in Configure.help and (more importantly) moved the configuration experience away from low-level, hardware-oriented questions towards where I think it ought to be. That is, you specify a platform and the services you want and the ruleset computes the low-level facilities to be linked in. 3. The MVME derivations are correct *if* (and only if) you agree to ignore the possibility that somebody could want to ignore the onboard hardware, plug outboard disk or Ethernet cards into the VME-bus connector, and do something like running SCSI-over-ATAPI to the outboard device. (I missed these possibilities when I wrote the derivations.) I used case 3 to explore a touchy question about design philosophy, which is really what caused all hell to break loose. The question is this: holding down configuration complexity is a good thing, but supporting all hardware configurations that are conceivably possible is also a good thing. How should we trade these good things off against one another? I'd say support all possible configurations that is supposed to work. You never know what someone might want to make out of spare parts and dusty old things. Particularly, not compiling (or modularizing) the driver for a built-in device is always a valid way of saving memory. I don't compile IDE on my home pc, because all my devices are scsi. And the built-in floppy controller is modularized because it is so rarely used. Why give it permanent unswappable memory? Your trade-off considerations should be wether odd but possible choices belong in an EXPERT category or if they should be there for everybody. Don't consider eliminating something that would work. Of course you don't have to worry too much about help texts for the expert stuff - let the experts add that themselves if you don't want to write for fringe cases. The MVME situation is an almost perfect test case, because while breaking the assumption behind that derivation is physically possible it would be a rather perverse thing to do. The VME147 is an old design, dating from 1988; it's long since been superseded by MPCxxx SBCs based on the PowerPC that have a better processor, lower power consumption, and more on-board peripheral hardware. IDE/ATAPI didn't exist during most of its design lifetime, and the only way anyone is ever going to hook an outboard device to one of these puppies again is if some hacker pulls a dusty one off a shelf for some garage project. Hackers get things like this for free when companies get rid of them, then turns them into mp3 players or hobby device controllers. So the real question here is whether it is ever acceptable to say that a possible configuration is just silly and ruleset will ignore it, in Maybe it is acceptable to say something is too silly. You have to come up with a better example though. People may definitely want to not have a driver, or make a module instead of compiled-in. And they may want to not use the built-in device because they use something better. Like a fast ethernet connected to that old vme box because the net they connect to is fast even though the box may be too weak to really take advantage of it. Or wide scsi instead of the built-in thing. order to hold down ruleset complexity and simplify the user experience. The cost of deciding that the answer to that question is The user experience can be simplified by a NOVICE/EASY/SANE_DEFAULTS option, and perhaps a HACKER option for the really strange but _theoretically_ ok stuff. yes, sometimes is that on rare occasions like this one you might have to haul out a text editor to tweak something in your config. But the cost of deciding that the answer is no will be some pretty serious complexity headaches both in the configuration user experience and (down the road) in the maintainability of the ruleset. If EXPERT options makes it too complex, consider having some rules that are advisory only. The debian packaging system has both absolute dependancies, and suggestions. Consider: suggest MVME16x_SCC from MVME16x SERIAL which means that someone who turns on MVME16x_SCC and SERIAL get MVME16x_SCC turned on when they do so. But the choice is visible and it is possible for the user to turn it off at will. Maybe shown in a different color or with some other hint that it is a defaulted but overrideable thing. Configuration gets simple for the vast amount of common cases, but experts can do whatever they want.
Re: Background to the argument about CML2 design philosophy
David Woodhouse [EMAIL PROTECTED]: Because it is evidently confusing the issue. Perhaps because it sounds like you were intending to feed Linus large patches for 2.5.[12] which effect _both_ changes. I'm going to give Linus the same installation kit the people working with CML2 have now. That will include both the CML2 engine and the rulesfiles. Have patience - let the less contentious part of CML2 go in first, and then we can deal with the other stuff later, once CML2 has been accepted (however grudgingly in some cases) by developers. I don't think there is a less contentious part. The same people who bitched about the engine are now bitching about the changes I'm contemplating in the rulesfiles. It seems clear to me that their attitude, in general, has little to do with technical specifics of the engine or rulesets and everything to do with resistance to change in general and fear of losing control and/or hard-won implicit knowledge about the old system. I can sympathize with their upset, but I don't intend to let it stop me. And since I'm going to have these people angry at me unless I give up entirely, I figure I have little to lose by steaming ahead full. The engine is working. Why is it not yet time to discuss ruleset design and modes? For a man who claims to hack social systems, that's an incredibly naïve question. You think so, eh? Heh. Experience has taught me that sometimes hacking social systems requires a certain amount of sheer bloodymindedness. See, I've already written off the chronic bellyachers. Since I can't please them without scrapping the whole plan, I'm going to ignore them. In particular, anybody who repeated fsck Python... after Linus ruled that Python is not an issue and Greg Banks announced the C implementation of CML2 has got a sufficiently severe case of rectocranial insertion that they've defined themselves out of the conversation. Instead I'll take my cues from people like you and Ray Knight and Tom Rini and Alan Cox and Martin Schwidefsky who are actually offering help and constructive criticism. (Arjan de Ven is trying but he's not up to speed on the language yet.) I trust you've noticed by now that I *do* listen very carefully in that situation, and I follow up with questions when I'm not sure what people are trying to tell me. I'll keep doing that. Eventually the bellyachers may get a message about what kind of behavior gains them influence and what kind loses them influence. That's a social-systems hack of a sort ;-). -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a I don't like the idea that the police department seems bent on keeping a pool of unarmed victims available for the predations of the criminal class. -- David Mohler, 1989, on being denied a carry permit in NYC - 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: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] said: I don't think there is a less contentious part. The same people who bitched about the engine are now bitching about the changes I'm contemplating in the rulesfiles. It seems clear to me that their attitude, in general, has little to do with technical specifics of the engine or rulesets and everything to do with resistance to change in general and fear of losing control and/or hard-won implicit knowledge about the old system. No. I didn't bitch (much) about CML2 - I'm fairly ambivalent. But I absolutely object to _unconditionally_ dumbing down the config options, because it would hide options which I would frequently want to enable. Introduce new novice modes if you wish - that seems sensible - but do not reduce the functionality and flexibility of configuration which is currently available. Any simplifications you make _must_ be dependent on the novice mode, and the default mode should allow the same choices as the current rules. More importantly, do not attempt to force through this change in policy by sneaking it into the 2.5.1 CML2 patch which introduces the new mechanism. The two are entirely orthogonal, and should remain separate. [EMAIL PROTECTED] said: I'm going to give Linus the same installation kit the people working with CML2 have now. That will include both the CML2 engine and the rulesfiles. Fine. What I'm asking is that you ensure that the CML2 rulesfiles at the time of the merge implement the dependencies present in the CML1 rulesfiles immediately prior to the merge. If you want to work on the change of policy right now, before CML2 is merged, then go ahead and do it in CML1. It's not difficult. The first step is to make CONFIG_*_ADVANCED depend on CONFIG_EXPERT, for example. Then get those changes merged into 2.5 before you merge CML2 - and you still keep the CML2 after the merge equivalent to the CML1 immediately before the merge. Otherwise, have patience and do it after CML2 is merged. All I'm asking is that you refrain from confusing the change in mechanism with the change in policy. That's not an unreasonable request, now is it? -- dwmw2 - 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: Background to the argument about CML2 design philosophy
order to hold down ruleset complexity and simplify the user experience. The cost of deciding that the answer to that question is The user experience can be simplified by a NOVICE/EASY/SANE_DEFAULTS option, and perhaps a HACKER option for the really strange but _theoretically_ ok stuff. Having now briefly looked at the language constructs first-hand, I can see two ways to go about this: 1) Have a HACKER symbol which unsuppresses the unusual options, and suppresses the generalised ones (like: build all the sound drivers for my hardware, as modules). This is kinda how it would be implemented in CML1, cf. EXPERIMENTAL. 2) Have a HACKERS submenu system which contains all the derivations that could *possibly* be un-defaulted, and allow our intrepid hacker to explicitly force each to a value or leave unset. Leaving unset means the derivation holds, forcing it to a value will explicitly enable or disable the option along with any hard dependencies. Head this submenu system with a big banner that says FOR EXPERTS ONLY, or suppress it using an Experts switch. Is there already a language construct to support the difference between a derivation and a dependency? Yes, it's the difference between unless FOO==n default BAR==y and require FOO!=n implies BAR==y respectively (or something to that effect, if my syntax is wrong flame gently please!). With that in mind, the front-end UI could implement Option 2 easily, by presenting a mode which automatically collects defaulted but otherwise hidden symbols, and reveals them to the user when set to hacker mode. I'm going to assume for now that CML2 saves two files - one storing a relatively small number of symbols (which is strictly limited to those explicitly set by the user), and one containing the full set for consumption by the Makefiles. If this is the case, then if a hacker type switches something explicitly then it'll stay there even if the default changes for that option in a future kernel. Meanwhile, Aunt Tillie gets the changed default option applied with no extra effort. make oldconfig might as well be a thing of the past for certain purposes, although it should still be kept as a way of reminding people what the new options are. Incidentally, in this scenario, if we have enable driver for device FOOBAR [NEW] [y/m/N]: then pressing Return should *not* mark the symbol as explicitly set but left alone because user accepted the default. If they pressed N, then that has the same effect but is saved explicitly for future kernels, regardless of any defaults change for that option. Hope this makes sense and I'm not being a stark raving loonie... -- from: Jonathan Chromatix Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -END GEEK CODE BLOCK- - 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: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] said: Having now briefly looked at the language constructs first-hand, I can see two ways to go about this: 1) Have a HACKER symbol which unsuppresses the unusual options, and suppresses the generalised ones 2) Have a HACKERS submenu system which contains all the derivations that could *possibly* be un-defaulted, and allow our intrepid hacker to explicitly force each to a value or leave unset. I prefer the former, which is how it's already implemented in CML1. But the discussion of this is entirely unrelated to the discussion of CML2, and changes along these lines must not be forced into the kernel with the CML2 patch. If ESR is going to sneak policy changes into the kernel with the CML2 mechanism patch, I'm sure we all have patches we'd like him to add to it too, because we don't want to have to justify them on their own. :) -- dwmw2 - 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: Background to the argument about CML2 design philosophy
On 05/21/2001 at 05:04:40 AM [EMAIL PROTECTED] wrote: See, I've already written off the chronic bellyachers. Since I can't please them without scrapping the whole plan, I'm going to ignore them. In particular, anybody who repeated fsck Python... after Linus ruled that Python is not an issue and Greg Banks announced the C implementation of CML2 has got a sufficiently severe case of rectocranial insertion that they've defined themselves out of the conversation. I probably qualify as one of the bellyachers. If so, I apologize. It was not my intention to disparage the work of Eric or anyone else involved in this project. Speaking from the perspective of a user of the CML tools, rather than as a developer, all I've been trying to say is this: When I type make menuconfig or make oldconfig in the future, I want to see the same interface and the same results that I've always seen, because it's always worked for me in the past. It really doesn't matter to me if, down underneath, this is being done by CML1, CML2, or a little man in my computer who slaughters chickens and reads their entrails for omens to determine dependencies. Right now I can grab a new -pre or -ac patch, use oldconfig, and have a compile going in a few minutes, without knowing or caring about the details of the config process. In the rare case that a patch breaks an existing driver, it takes only a couple of minutes with menuconfig to disable that driver and compile without it, and then put it back in when it's fixed. And when, every once in a great while, I decide to scrap my .config and start over, I can fly through all the menuconfig options very quickly and make my customary selections almost without thinking about it. I just want to be able to keep using the tools in this way. If that's not going to be possible... well, I'll adapt. But from my point of view, learning a new set of tools just to keep doing the same things I've always done isn't a pleasant prospect. I understand that changes may be necessary to meet others' needs, but I'd like to see those changes made without affecting the way my own needs are met. I'm off my soapbox now and won't bellyache about it any further. Wayne - 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: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] [EMAIL PROTECTED]: Speaking from the perspective of a user of the CML tools, rather than as a developer, all I've been trying to say is this: When I type make menuconfig or make oldconfig in the future, I want to see the same interface and the same results that I've always seen, because it's always worked for me in the past. Visual details will differ, but I've been careful about maintaining functional compatibility. There was a phase of the development during which I was mostly processing feature requests from people who wanted features of the old system that I had not properly understood (such as the NEW tag). That phase ended almost a month ago. Nobody who has actually tried the CML2 tools more recently has reported that the UI changes present any difficulty. CML2 drops its configuration results in the same place, in the same formats, as CML1. So you should in fact be able to type `make menuconfig' and `make oldconfig' with good results. Have you actually tried this? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The right of the citizens to keep and bear arms has justly been considered as the palladium of the liberties of a republic; since it offers a strong moral check against usurpation and arbitrary power of rulers; and will generally, even if these are successful in the first instance, enable the people to resist and triumph over them. -- Supreme Court Justice Joseph Story of the John Marshall Court - 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: Background to the argument about CML2 design philosophy
On 05/21/2001 at 12:58:57 [EMAIL PROTECTED] wrote: CML2 drops its configuration results in the same place, in the same formats, as CML1. So you should in fact be able to type `make menuconfig' and `make oldconfig' with good results. Have you actually tried this? No, I haven't tried it yet. I usually wait for things like this to be included in Linus' or Alan's kernels before trying them. In this case, I might have tried it by now but I only have Python 1.5.2 on my system and don't want to upgrade it until/unless it's absolutely necessary. So I probably won't see CML2 until Linus puts it in 2.5. My comments have been based on your descriptions of it on lkml. Wayne - 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: Background to the argument about CML2 design philosophy
On Mon, 21 May 2001, Eric S. Raymond wrote: the NEW tag). That phase ended almost a month ago. Nobody who has actually tried the CML2 tools more recently has reported that the UI changes present any difficulty. What happened with the discussion on configurable colors in make menuconfig? Darkblue on black as frozen options get isn't exactly optimal ... at least not for my eyes. Being next to a bold, white text doesn't help either. CML2 drops its configuration results in the same place, in the same formats, as CML1. So you should in fact be able to type `make menuconfig' and `make oldconfig' with good results. Have you actually tried this? It works for me, but anyone testing this should know that the CML2 tools read config.out if it finds one. So people that do things like: make mrproper ; cp ../.config-2.4 .config ; make oldconfig will have to change to copying config.out instead. Doing like this sort of works* if there is no config.out, otherwise it does not (as it uses the config.out). Saying that the config result ends up in the same place and same format is somewhat misleading, you do get a copy in the CML1 output format but the tools doesn't care about that if it can find a file in the new format. *) Sort of works, since doing like I do will cause you to get a lot of questions that you have already answered. That appears to be a one-time problem as 'oldconfig' does not read # CONFIG_FOO is not set as no. Would be nice if it did. make mrproper doesn't remove config.out. It should since that's what it does with .config* files. Not sure if it should remove the rules.out file also, but I think it should as the idea(?) with mrproper is to clean up anything that is generated. /Urban - 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: Background to the argument about CML2 design philosophy
David Actually, the current system has both types. As well as the David hard dependencies, we also have stuff like David CONFIG_PARTITION_ADVANCED, CONFIG_CPU_ADVANCED, David CONFIG_FBCON_ADVANCED, CONFIG_MTD_DOCPROBE_ADVANCED, David etc. CONFIG_EXPERIMENTAL serves a very similar purpose, too. David These things have already been set up in the way that David developers prefer it. *some* developers prefer it. Not all. David CML2 allows us to be more flexible than we were before, and David that can be a good thing when used in moderation. But please, David for the sake of the sanity of all concerned, do things one at a David time. Provide for merging into 2.5 a set of rules which David reproduce the existing CML1 behaviour in this respect. Can you define what you mean here? It's not really clear to me, and I suspect others. David Eric, if you want to make further changes later to introduce David new 'modes' for kernel configuration, that's an entirely David separate issue. Please don't confuse the issue by trying to do David it at the same time as introducing CML2. I don't think he is introducing new modes, he's just trying to make sure that you can't create a .config which is broken. Part of my complaint early on was that it would just barf on a config it thought wasn't legall, and just drop me to the 'vi' level. I don't think this is acceptable because you (CML2 or CML) should be able to prompt the user for a suggested fix. David CONFIG_AUNT_TILLIE does not require CML2. Correct. David CML2 does not require CONFIG_AUNT_TILLIE. Correct. And never has offered it either! David Let's not talk about CONFIG_AUNT_TILLIE any more, or change the David existing behaviour of config options to make that the default, David until we've settled the discussion about CML2. I think it comes down to people who just want one or more of: - the existing interface of vi .config; make oldconfig - fear that CML2 won't let them make crazy configurations, such as an 8-way SMP box with ISA. Can't see how CML2 would restrict this choice myself. - Don't want to install python 2.x for a kernel upgrade. - fear that some configuration corner case will be handled wrong for a strange (read not common) system config. All that CML2 does is enforce dependencies in the configuration language. You can't make a .config which conflicts. Admittedly there's nothing stopping you from hacking it with vi after the fact, but why? If you run into a case where you have a config which would work, but CML2 doesn't let you, why don't you fix the grammar instead of saying CML2 is wrong? Let's not confuse these two issues as well. John - 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: Background to the argument about CML2 design philosophy
If you run into a case where you have a config which would work, but CML2 doesn't let you, why don't you fix the grammar instead of saying CML2 is wrong? Let's not confuse these two issues as well. Strongly agree. Especially since I'm pushing for an explicit recognition of the difference between a hard dependancy and a soft derivation. The latter can be over-ridden safely by someone who knows what he's after. The former will cause a miscompile. -- from: Jonathan Chromatix Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -END GEEK CODE BLOCK- - 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: Background to the argument about CML2 design philosophy
2) Have a HACKERS submenu system which contains all the derivations that could *possibly* be un-defaulted, and allow our intrepid hacker to explicitly force each to a value or leave unset. I prefer the former, which is how it's already implemented in CML1. Its called Debugging in CML1 in -ac for a reason btw. Because its called debugging I get plenty of reports that start I dont know much about this but I turned on all the debugging options and now instead of hanging it says Oops 0xA5A5A5A5 ... which are a lot more useful. Names matter a lot - 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: Background to the argument about CML2 design philosophy
On Mon, 21 May 2001 16:38:34 -0400,
John Stoffel [EMAIL PROTECTED] wrote:
All that CML2 does is enforce dependencies in the configuration
language. You can't make a .config which conflicts. Admittedly
there's nothing stopping you from hacking it with vi after the fact,
but why?
CML2 will not stop you hacking .config by hand. But the 2.5 makefile
rewrite will, because we have had too many bug reports caused by people
who hand edited .config, did not revalidate it and generated invalid
kernels. Yes, you can hand edit .config. No, you cannot compile until
.config has been (re-)validated.
# Not a real dependency, this checks for hand editing of .config.
$(KBUILD_OBJTREE)include/linux/autoconf.h: $(KBUILD_OBJTREE).config
@echo Your .config is newer than include/linux/autoconf.h, this should not
happen.
@echo Always run make one of {menu,old,x}config after manually updating
.config.
@/bin/false
And before people complain: Don't create a config that violates the CML
rules, correct the CML rules, the Makefiles and the source so .config
is valid. The kernel build requires a valid .config.
-
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: Background to the argument about CML2 design philosophy
Urban Widmark [EMAIL PROTECTED]: What happened with the discussion on configurable colors in make menuconfig? Darkblue on black as frozen options get isn't exactly optimal ... at least not for my eyes. Being next to a bold, white text doesn't help either. Nobody could come up with a way to support configurable colors that didn't seem like way more trouble than it was worth. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a ...quemadmodum gladius neminem occidit, occidentis telum est. [...a sword never kills anybody; it's a tool in the killer's hand.] -- (Lucius Annaeus) Seneca the Younger (ca. 4 BC-65 AD), - 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: Background to the argument about CML2 design philosophy
On 20 May 2001, Robert M. Love wrote: > I feel that there should *never ever* be a legit situation that the > configuration tool does not allow. Not ever. Two reasons: > > First, I tend to trust the config tools (perhaps too much). If they > tell me x implies y, or x implies not y, I will believe it. I won't > think "hm, the code must be wrong, let me hand edit the config" (which > is something I don't want to have to do, anyhow). Then just don't go as far as using it in "Expert (might be unsafe)" mode. If you blindly trust the tool that much the intermediate mode might be what you need. Nicolas - 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: Background to the argument about CML2 design philosophy
On Sun, 20 May 2001, Eric S. Raymond wrote: > In order to prevent that happening, I would like to have some recognized > criterion for configuration cases that are so perverse that it is a > net loss to accept the additional complexity of handling them within the > configurator. Simple: That extreme perversion represent a kernel that wouldn't compile. You can't have NFS support if you didn't select networking support, etc. Such is the recognized basics. Next, you can ask the question if you would have to modify the ruleset to add a new driver to be able to use a feature. Exemple: will you need to write a new driver for a special IDE interface card and add it in the ruleset before you could use IDE cdrom support on the MVME147 SBC? If you have to edit it anyway then it shouldn't be much pain to remove the unconditionnal removal of IDE support for that target. For all other combinations where a slight possibility might make you doubt then the choice should remain at least in expert mode. People might also want to remove support for subsystems on a specific target even if the device comes soldered on it, just because they won't use it anyway and they want to optimize their kernel size for better memory usage. IMHO your design goal now is mainly about finding a way to describe rule derivation related to the selected expertise mode, and only enforce the strictly impossible combinations for expert mode, just like CML1 is doing while removing obvious derivations for novice users. Now you protest with: > That pushes the third button. I'm nervous that if we go down this path > we will end up with a thicket of modes and a combinatorial explosion > in ruleset complexity, leading immediately to a user configuration > experience that is more complex than necessary, and eventually to an > unmaintainable mess in the rulesfiles. Eric: with this I think you know what everybody here is wishing for, and you just perfectly stated your design constraint in achieving it. You can't avoid the "all semi-possible combination allowed" mode. So let's switch to the implementation discussion instead. Nicolas - 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: Background to the argument about CML2 design philosophy
> derive MVME147_SCSI from MVME147 & SCSI It seems that the preferred semantics would be: default MVME147_SCSI from MVME147 & SCSI That way the platform defines sane defaults, but no flexibility has been taken away. Presumably many of these defaulted options would also be ones that would be configured not to be changeable in novice mode. The novice gets the vanilla platform defaults without being bothered by detailed options, and can switch to expert mode if they need more control. The experts get all the options presented, but also get to benefit from the smart platform defaults. Ben - 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: Background to the argument about CML2 design philosophy
David Woodhouse <[EMAIL PROTECTED]>: > Let's not talk about CONFIG_AUNT_TILLIE any more, or change the existing > behaviour of config options to make that the default, until we've settled > the discussion about CML2. What discussion is that? Unless Linus has changed his mind and I don't know about it, CML2 is going in between 2.5.1 and 2.5.2. The engine is working. Why is it not yet time to discuss ruleset design and modes? -- http://www.tuxedo.org/~esr/;>Eric S. Raymond That the said Constitution shall never be construed to authorize Congress to infringe the just liberty of the press or the rights of conscience; or to prevent the people of the United states who are peaceable citizens from keeping their own arms... -- Samuel Adams, in "Phila. Independent Gazetteer", August 20, 1789 - 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: Background to the argument about CML2 design philosophy
> "Eric" == Eric S Raymond <[EMAIL PROTECTED]> writes: Eric> The first candidates I found were questions associated with Eric> built-in SCSI and Ethernet on Macintoshes, on the Sun 3 and Eric> Sun3x, and with built-in facilities on the MVME147 single-board Eric> computer. So I wrote derivations that looked like this: [snip derive rules] Eric> # These were separate questions in CML1 derive MAC_SCC from MAC Eric> & SERIAL derive MAC_SCSI from MAC & SCSI derive SUN3_SCSI from Eric> (SUN3 | SUN3X) & SCSI Eric> By doing this I killed two birds with one stone -- got rid of Eric> some holes in Configure.help and (more importantly) moved the Eric> configuration experience away from low-level, hardware-oriented Eric> questions towards where I think it ought to be. That is, you Eric> specify a platform and the services you want and the ruleset Eric> computes the low-level facilities to be linked in. And you suddenly imposed decisions on people. Wether or not you are an expert it is reasonable to expect that you want to use modules just as it is just as reasonable to expect that you do not. In some cases you want your Ethernet as a module in some case you want the low level SCSI driver but not the SCSI mid layer. Eric> After some back-and-forthing about the technical facts, several Eric> things emerged: Eric> 1. The Mac derivations were half-right. The MAC_SCC one is good Eric> but Macs can have either of two different SCSI controllers. I Eric> fixed that with help from Ray Knight, who maintains the 68K Mac Eric> port. Eric> 2. Nobody had a problem with the SUN3_SCSI derivation. Did you ever get an ACK on it or no answer? Eric> 3. The MVME derivations are correct *if* (and only if) you agree Eric> to ignore the possibility that somebody could want to ignore the Eric> onboard hardware, plug outboard disk or Ethernet cards into the Eric> VME-bus connector, and do something like running SCSI-over-ATAPI Eric> to the outboard device. (I missed these possibilities when I Eric> wrote the derivations.) Or wants to use modules. And yes Aunt Tillie might want to do so, if the person who sold her her Linux CD provided a bunch of scripts for packing up things in a specific way. Eric> The MVME situation is an almost perfect test case, because while Eric> breaking the assumption behind that derivation is physically Eric> possible it would be a rather perverse thing to do. The VME147 Eric> is an old design, dating from 1988; it's long since been Eric> superseded by MPCxxx SBCs based on the PowerPC that have a Eric> better processor, lower power consumption, and more on-board Eric> peripheral hardware. IDE/ATAPI didn't exist during most of its Eric> design lifetime, and the only way anyone is ever going to hook Eric> an outboard device to one of these puppies again is if some Eric> hacker pulls a dusty one off a shelf for some garage project. Bt wrong. The MVME cards are still heavily used in control systems and similar places. It's the only place where m68k usage is not dying for real. Eric> So far, I have to say I'm disappointed in the quality of the Eric> debate. Almoist nobody seems to want to think about this Eric> tradeoff globally, as a systems design issue. Instead, I'm Eric> hearing a lot of reflexive chuntering that we have to do things Eric> a certain way because we've always done them a certain way, and Eric> who am I to even dare *think* about raising different Eric> possibilities? So far the introduction of CML2 has been overly disppointing, from day one it's been 'I have this great idea and since I think it's great, you obviously have to think so as well'. Now I take it the derived rules are still only enforced under the 'novice' option, though you haven't exactly made that clear in the discussion (nor did you do so when you initially brought it up). Jes - 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: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] said: > Maybe it would be possible to separate "hard" dependencies like the > current system has with the "soft" ones one needs for entry-level > configtools. Actually, the current system has both types. As well as the "hard" dependencies, we also have stuff like CONFIG_PARTITION_ADVANCED, CONFIG_CPU_ADVANCED, CONFIG_FBCON_ADVANCED, CONFIG_MTD_DOCPROBE_ADVANCED, etc. CONFIG_EXPERIMENTAL serves a very similar purpose, too. These things have already been set up in the way that developers prefer it. CML2 allows us to be more flexible than we were before, and that can be a good thing when used in moderation. But please, for the sake of the sanity of all concerned, do things one at a time. Provide for merging into 2.5 a set of rules which reproduce the existing CML1 behaviour in this respect. Eric, if you want to make further changes later to introduce new 'modes' for kernel configuration, that's an entirely separate issue. Please don't confuse the issue by trying to do it at the same time as introducing CML2. CONFIG_AUNT_TILLIE does not require CML2. CML2 does not require CONFIG_AUNT_TILLIE. Let's not talk about CONFIG_AUNT_TILLIE any more, or change the existing behaviour of config options to make that the default, until we've settled the discussion about CML2. -- dwmw2 - 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: Background to the argument about CML2 design philosophy
On 20 May 2001 16:47:00 -0400, Eric S. Raymond wrote: > In order to prevent that happening, I would like to have some recognized > criterion for configuration cases that are so perverse that it is a > net loss to accept the additional complexity of handling them within the > configurator. > > A lot of people (including, apparently, you) are saying there are no such > cases. I wonder if you'll change your minds when you have to handle the > overhead yourselves? I feel that there should *never ever* be a legit situation that the configuration tool does not allow. Not ever. Two reasons: First, I tend to trust the config tools (perhaps too much). If they tell me x implies y, or x implies not y, I will believe it. I won't think "hm, the code must be wrong, let me hand edit the config" (which is something I don't want to have to do, anyhow). Second, I like having a lean kernel. Here is an example (I realize this probably won't ever manifest into a real rule): INTEL_I815 implies INTEL_RNG, DRM_I810, INTEL_AGP, I810_TCO, PCI, etc etc. -- I don't want the RNG or TCO watchdog. I don't use the on-board graphics. Nor, if my i815 model supported it, the sound. There are people who want to customize their kernel (hell, everyone at this level of the game). There are people, like David, who have custom setups. We need to support this, without hacking the config (especially if I have to rehack it after every make oldconfig!). I like your design to abstract away low levels features to a more general design. This makes it easier for the novice, and more intuitive for everyone. But not at the expense of limiting possible cases. -- Robert M. Love [EMAIL PROTECTED] [EMAIL PROTECTED] - 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: Background to the argument about CML2 design philosophy
On Sun, May 20, 2001 at 04:47:00PM -0400, Eric S. Raymond wrote: > In order to prevent that happening, I would like to have some recognized > criterion for configuration cases that are so perverse that it is a > net loss to accept the additional complexity of handling them within the > configurator. "It doesn't compile/link" would be a good one. "It requires subsystem FOO to operate" is another (think about IDE DMA drivers and the IDE subsystem, or NIC drivers vs CONFIG_NET) > A lot of people (including, apparently, you) are saying there are no such > cases. I wonder if you'll change your minds when you have to handle the > overhead yourselves? Somehow the current overhead isn't that high. You might argue that the current Config.in is broken given my definition. That is fixable with a day of work; I've been doing so on a regular basis with the tooling I wrote for automatic testing of this. Maybe it would be possible to separate "hard" dependencies like the current system has with the "soft" ones one needs for entry-level configtools. Or maybe it needs 2 files for that.. CML1 style (style, maybe not syntax) ones and the newstyle info. I liked the suggestion where the "automatic" derivations got turned into manual ones for expert mode... I haven't tried CML2 yet (I've yet to find a suitable .deb of Python2 for my Debian Potato playbox) so I don't know if that is actually possible, or that it requires some redesign. Greetings, Arjan van de Ven - 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: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] said: > I'm nervous that if we go down this path we will end up with a > thicket of modes and a combinatorial explosion in ruleset complexity, > leading immediately to a user configuration experience that is more > complex than necessary, and eventually to an unmaintainable mess in > the rulesfiles. Having too many such modes would be a horrible mess, I agree. > In order to prevent that happening, I would like to have some > recognized criterion for configuration cases that are so perverse that > it is a net loss to accept the additional complexity of handling them > within the configurator. > A lot of people (including, apparently, you) are saying there are no > such cases. I wonder if you'll change your minds when you have to > handle the overhead yourselves? Of course there are such cases. The criterion is that the code does not compile or if it did, it could never be expected to work - like SCSI drivers without SCSI generic, or PCI devices without CONFIG_PCI. This is the major criterion which has defined the dependencies already in the config files. You want to add a new mode which hides some of the more esoteric options. That's fine. So do so, and then we have two modes. It's still not an unmaintainable mess. If having even two modes is going to be too troublesome, then keep the one we have. You can try to simplify it later by encouraging individual maintainers to hide stuff behind CONFIG_*_ADVANCED options. But keep that strictly separate from the CML2 discussion. -- dwmw2 - 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: Background to the argument about CML2 design philosophy
David Woodhouse <[EMAIL PROTECTED]>: > I think you already have the mechanism required to answer this - in NOVICE > mode you disallow the strange choices, in EXPERT mode you allow them. That pushes the third button. I'm nervous that if we go down this path we will end up with a thicket of modes and a combinatorial explosion in ruleset complexity, leading immediately to a user configuration experience that is more complex than necessary, and eventually to an unmaintainable mess in the rulesfiles. In order to prevent that happening, I would like to have some recognized criterion for configuration cases that are so perverse that it is a net loss to accept the additional complexity of handling them within the configurator. A lot of people (including, apparently, you) are saying there are no such cases. I wonder if you'll change your minds when you have to handle the overhead yourselves? Sigh... -- http://www.tuxedo.org/~esr/;>Eric S. Raymond "Government is not reason, it is not eloquence, it is force; like fire, a troublesome servant and a fearful master. Never for a moment should it be left to irresponsible action." -- George Washington, in a speech of January 7, 1790 - 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: Background to the argument about CML2 design philosophy
Jonathan Morton <[EMAIL PROTECTED]>: > One caveat though - not all Macs have SCSI controllers, and not all that do > even have one of the two standard ones. I know. But these derivations are only for the old 68K macs, which don't have PCI. Closed issue. > >3. The MVME derivations are correct *if* (and only if) you agree to ignore > >the possibility that somebody could want to ignore the onboard hardware, > >plug outboard disk or Ethernet cards into the VME-bus connector, and > >do something like running SCSI-over-ATAPI to the outboard device. > > ...and then someone else mentioned the possibility of f*x0r3d hardware. In > this case, I would say this *isn't* a kernel-configuration issue but one of > being able to disable the drivers for the malfunctioning hardware. But the other side is going to ask: suppose you're memory-limited (quite likely on older SBCs) and don't want to pay the core cost of drivers you won't use? I don't really think we can duck this question by talking about boot-time parameters. > I think the MVME derivations are *perfectly* sensible - if the reference > board and most (read: virtually all) derivatives have those features, turn > them on by all means. That's my gut feeling, too. But a lot of people insist that the only right way is totally fine-grained control, even in weird edge cases like this one. > To satisfy some others, you might want to say "Hey, > these guys might want to *explicitly turn off* some of this stuff" - so > provide an option under "Are you insane?" which presents all the "derived" > symbols and allows the hackers to manually turn stuff off. Interesting thought... -- http://www.tuxedo.org/~esr/;>Eric S. Raymond I cannot undertake to lay my finger on that article of the Constitution which grant[s] a right to Congress of expending, on objects of benevolence, the money of their constituents. -- James Madison, 1794 - 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: Background to the argument about CML2 design philosophy
>1. The Mac derivations were half-right. The MAC_SCC one is good but Macs >can have either of two different SCSI controllers. I fixed that with help >from Ray Knight, who maintains the 68K Mac port. If I understand the "philosophy" correctly, it is still possible to specify additional cards for those Macs which have PCI slots. If so, absolutely fine - I can shove my Adaptec 19160 into my G4 and have it work just as well as it currently does in my Athlon. One caveat though - not all Macs have SCSI controllers, and not all that do even have one of the two standard ones. The "Blue and White G3", the iMac, the PowerBook G3 "Firewire" and later models on these lines all lack a built-in SCSI controller, but many could have one added via PCI or CardBus slots. The PowerBooks 5300 and 190 (and possibly others) use some non-standard P.O.S. hanging off the NuBus, which even mkLinux doesn't know how to drive. However, in these situations, disabling the extra drivers is usually not critical unless you're running low on space somewhere. At that point, you enable the "Are you insane?" module outlined below... >3. The MVME derivations are correct *if* (and only if) you agree to ignore >the possibility that somebody could want to ignore the onboard hardware, >plug outboard disk or Ethernet cards into the VME-bus connector, and >do something like running SCSI-over-ATAPI to the outboard device. >(I missed these possibilities when I wrote the derivations.) ...and then someone else mentioned the possibility of f*x0r3d hardware. In this case, I would say this *isn't* a kernel-configuration issue but one of being able to disable the drivers for the malfunctioning hardware. If I have a PCMCIA controller that reboots the machine as soon as the driver tries to switch it on, I should be able to send a command-line parameter to the kernel which tells it to switch it off *at run-time*. And iff I'm running with hardware which is so f*x0r3d that that isn't enough, I'd either fix the hardware or hack the config files. I don't see the problem. I think the MVME derivations are *perfectly* sensible - if the reference board and most (read: virtually all) derivatives have those features, turn them on by all means. To satisfy some others, you might want to say "Hey, these guys might want to *explicitly turn off* some of this stuff" - so provide an option under "Are you insane?" which presents all the "derived" symbols and allows the hackers to manually turn stuff off. -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -END GEEK CODE BLOCK- - 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: Background to the argument about CML2 design philosophy
Thankyou for the clarification. [EMAIL PROTECTED] said: > I used case 3 to explore a touchy question about design philosophy, > which is really what caused all hell to break loose. The question is > this: holding down configuration complexity is a good thing, but > supporting all hardware configurations that are conceivably possible > is also a good thing. How should we trade these good things off > against one another? I think you already have the mechanism required to answer this - in NOVICE mode you disallow the strange choices, in EXPERT mode you allow them. Embedded boards are a special case in this respect - people add all manner of strange crap to the reference designs - believe me, I've seen the ways in which they can fuck it up and yet still they manage to amaze me sometimes. And because of the multitude of ways in which the monkeys who glue together these boards can fuck it up, often you really really want to ignore the on-board Ethernet, for example, and use the PCMCIA card you plugged in, because they actually managed to route the PCMCIA interrupt to an IRQ line, not a GPIO pin. [EMAIL PROTECTED] said: > So the real question here is whether it is ever acceptable to say that > a possible configuration is just silly and ruleset will ignore it, in > order to hold down ruleset complexity and simplify the user > experience. The cost of deciding that the answer to that question is > "yes, sometimes" is that on rare occasions like this one you might > have to haul out a text editor to tweak something in your config. As I said earlier, there are two main cases which should be considered entirely separately. There are the cases which are insane, and which won't ever work, or probably even compile. Those should be hard-coded off in the ruleset and it should not be possible to enable them without hacking. For the cases where we just want to make life simpler for the users, the constraints should be dependent on the user mode. In NOVICE mode you hide them, in EXPERT mode you make them available. The current (CML1) solution has problems, and it only provides real support for a small range of people at the hacker end of the spectrum. Making CML2 useful for a far wider range of people is a laudable goal. But please take care to ensure that the set of people for whom CML2 is useful is a strict superset of those for whom CML1 was useful. In particular, please don't strive to make Aunt Tillie happy on the one occasion on which she configures her kernel at a cost of rendering CML2 less useful for those for whom kernel configuration is an every-day task. Once weighted appropriately, that tradeoff is particularly easy to decide upon. If you ever find yourself seriously suggesting that a developer would need to ditch CML2 and hack the config files directly in order to compile support for, for example, the DiskOnChip he just dropped into the DIL socket in his Ethernet card, then I would suggest that you have made a wrong choice somewhere down the road. Please backtrack and reconsider an earlier decision before you're eaten by a grue. We already have a distinction between config options which it's sensible to ask the user, and options for which you have to hack #defines in the source code. The options which I have put into drivers/mtd/Config.in are there because I _wanted_ the user to see them. The options which are hidden in the code are there because I made the opposite decision. There is a reasonably well-defined boundary for such things already, and it's found all over the kernel. Adding a new, higher boundary for Aunt Tillie is just fine - but please don't _move_ the existing one that most of us care about. -- dwmw2 - 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/
Background to the argument about CML2 design philosophy
Those of you who have become confused about the current argument over CML2 should read this... David Woodhouse <[EMAIL PROTECTED]>: > After the discussion of MAC and SCSI config options many moons ago in this > thread, I was left with the impression that the constraints which were > being objected to were not dependent upon a NOVICE mode, but were > unconditional. > > Was this merely a mistake in the conversion of the ruleset? Do you have a > policy that the default behaviour should be similar to that of CML1, or at > least that such behaviour should be available through one of the > modes? If not, please consider doing so. They were unconditional. It looks like a recap of history is in order. Until very recently, like ten days ago, I had a policy of altering the CML1 behavior as little as possible while I got CML2 up and running. Some change had been inevitable because of the move to a single-apex menu tree, but I tried to hold that to a minimum. But I have reached a point where the configurator codebase is stable and works as a drop-in install on top of a stock kernel tree. I'm not even getting requests for UI tweaks any more. So the CML2 engine is essentially done (modulo the occasional minor bugfix). This made it time to start thinking about tuning the rulesfile to make configuration easier. At the same time, I was dealing with another problem; missing entries in Configure.help. When I got handed the maintainer's baton, there were 547 of these. I have written outright over 300 new ones; Steven Cole and I have collected another 50 or so. To reduce the problem further, I looked for symbols with missing entries that I could turn into derivations, eliminating their questions and the requirement for a help entry. (A CML2 derivation is like a CML1 define; it's a formula that sets a symbol from the value of other symbols without user input.) The first candidates I found were questions associated with built-in SCSI and Ethernet on Macintoshes, on the Sun 3 and Sun3x, and with built-in facilities on the MVME147 single-board computer. So I wrote derivations that looked like this: # These were separate questions in CML1. They enable on-board peripheral # controllers in single-board computers. derive MVME147_NET from MVME147 & NET_ETHERNET derive MVME147_SCC from MVME147 & SERIAL derive MVME147_SCSI from MVME147 & SCSI derive MVME16x_NET from MVME16x & NET_ETHERNET derive MVME16x_SCC from MVME16x & SERIAL derive MVME16x_SCSI from MVME16x & SCSI derive BVME6000_NET from BVME6000 & NET_ETHERNET derive BVME6000_SCC from BVME6000 & SERIAL derive BVME6000_SCSI from BVME6000 & SCSI # These were separate questions in CML1 derive MAC_SCC from MAC & SERIAL derive MAC_SCSI from MAC & SCSI derive SUN3_SCSI from (SUN3 | SUN3X) & SCSI By doing this I killed two birds with one stone -- got rid of some holes in Configure.help and (more importantly) moved the configuration experience away from low-level, hardware-oriented questions towards where I think it ought to be. That is, you specify a platform and the services you want and the ruleset computes the low-level facilities to be linked in. This represented a change in the design philosophy of the ruleset, not something I wanted to do without input from the developers and port managers. So I broadcast "CML2 design philosophy heads up". After some back-and-forthing about the technical facts, several things emerged: 1. The Mac derivations were half-right. The MAC_SCC one is good but Macs can have either of two different SCSI controllers. I fixed that with help from Ray Knight, who maintains the 68K Mac port. 2. Nobody had a problem with the SUN3_SCSI derivation. 3. The MVME derivations are correct *if* (and only if) you agree to ignore the possibility that somebody could want to ignore the onboard hardware, plug outboard disk or Ethernet cards into the VME-bus connector, and do something like running SCSI-over-ATAPI to the outboard device. (I missed these possibilities when I wrote the derivations.) I used case 3 to explore a touchy question about design philosophy, which is really what caused all hell to break loose. The question is this: holding down configuration complexity is a good thing, but supporting all hardware configurations that are conceivably possible is also a good thing. How should we trade these good things off against one another? The MVME situation is an almost perfect test case, because while breaking the assumption behind that derivation is physically possible it would be a rather perverse thing to do. The VME147 is an old design, dating from 1988; it's long since been superseded by MPCxxx SBCs based on the PowerPC that have a better processor, lower power consumption, and more on-board peripheral hardware. IDE/ATAPI didn't exist during most of its design lifetime, and the only way anyone is ever going to hook an outboard device to one of these puppies again is if some hacker pulls a dusty one off a shelf for
Background to the argument about CML2 design philosophy
Those of you who have become confused about the current argument over CML2 should read this... David Woodhouse [EMAIL PROTECTED]: After the discussion of MAC and SCSI config options many moons ago in this thread, I was left with the impression that the constraints which were being objected to were not dependent upon a NOVICE mode, but were unconditional. Was this merely a mistake in the conversion of the ruleset? Do you have a policy that the default behaviour should be similar to that of CML1, or at least that such behaviour should be available through one of the modes? If not, please consider doing so. They were unconditional. It looks like a recap of history is in order. Until very recently, like ten days ago, I had a policy of altering the CML1 behavior as little as possible while I got CML2 up and running. Some change had been inevitable because of the move to a single-apex menu tree, but I tried to hold that to a minimum. But I have reached a point where the configurator codebase is stable and works as a drop-in install on top of a stock kernel tree. I'm not even getting requests for UI tweaks any more. So the CML2 engine is essentially done (modulo the occasional minor bugfix). This made it time to start thinking about tuning the rulesfile to make configuration easier. At the same time, I was dealing with another problem; missing entries in Configure.help. When I got handed the maintainer's baton, there were 547 of these. I have written outright over 300 new ones; Steven Cole and I have collected another 50 or so. To reduce the problem further, I looked for symbols with missing entries that I could turn into derivations, eliminating their questions and the requirement for a help entry. (A CML2 derivation is like a CML1 define; it's a formula that sets a symbol from the value of other symbols without user input.) The first candidates I found were questions associated with built-in SCSI and Ethernet on Macintoshes, on the Sun 3 and Sun3x, and with built-in facilities on the MVME147 single-board computer. So I wrote derivations that looked like this: # These were separate questions in CML1. They enable on-board peripheral # controllers in single-board computers. derive MVME147_NET from MVME147 NET_ETHERNET derive MVME147_SCC from MVME147 SERIAL derive MVME147_SCSI from MVME147 SCSI derive MVME16x_NET from MVME16x NET_ETHERNET derive MVME16x_SCC from MVME16x SERIAL derive MVME16x_SCSI from MVME16x SCSI derive BVME6000_NET from BVME6000 NET_ETHERNET derive BVME6000_SCC from BVME6000 SERIAL derive BVME6000_SCSI from BVME6000 SCSI # These were separate questions in CML1 derive MAC_SCC from MAC SERIAL derive MAC_SCSI from MAC SCSI derive SUN3_SCSI from (SUN3 | SUN3X) SCSI By doing this I killed two birds with one stone -- got rid of some holes in Configure.help and (more importantly) moved the configuration experience away from low-level, hardware-oriented questions towards where I think it ought to be. That is, you specify a platform and the services you want and the ruleset computes the low-level facilities to be linked in. This represented a change in the design philosophy of the ruleset, not something I wanted to do without input from the developers and port managers. So I broadcast CML2 design philosophy heads up. After some back-and-forthing about the technical facts, several things emerged: 1. The Mac derivations were half-right. The MAC_SCC one is good but Macs can have either of two different SCSI controllers. I fixed that with help from Ray Knight, who maintains the 68K Mac port. 2. Nobody had a problem with the SUN3_SCSI derivation. 3. The MVME derivations are correct *if* (and only if) you agree to ignore the possibility that somebody could want to ignore the onboard hardware, plug outboard disk or Ethernet cards into the VME-bus connector, and do something like running SCSI-over-ATAPI to the outboard device. (I missed these possibilities when I wrote the derivations.) I used case 3 to explore a touchy question about design philosophy, which is really what caused all hell to break loose. The question is this: holding down configuration complexity is a good thing, but supporting all hardware configurations that are conceivably possible is also a good thing. How should we trade these good things off against one another? The MVME situation is an almost perfect test case, because while breaking the assumption behind that derivation is physically possible it would be a rather perverse thing to do. The VME147 is an old design, dating from 1988; it's long since been superseded by MPCxxx SBCs based on the PowerPC that have a better processor, lower power consumption, and more on-board peripheral hardware. IDE/ATAPI didn't exist during most of its design lifetime, and the only way anyone is ever going to hook an outboard device to one of these puppies again is if some hacker pulls a dusty one off a shelf for some garage project. So
Re: Background to the argument about CML2 design philosophy
Thankyou for the clarification. [EMAIL PROTECTED] said: I used case 3 to explore a touchy question about design philosophy, which is really what caused all hell to break loose. The question is this: holding down configuration complexity is a good thing, but supporting all hardware configurations that are conceivably possible is also a good thing. How should we trade these good things off against one another? I think you already have the mechanism required to answer this - in NOVICE mode you disallow the strange choices, in EXPERT mode you allow them. Embedded boards are a special case in this respect - people add all manner of strange crap to the reference designs - believe me, I've seen the ways in which they can fuck it up and yet still they manage to amaze me sometimes. And because of the multitude of ways in which the monkeys who glue together these boards can fuck it up, often you really really want to ignore the on-board Ethernet, for example, and use the PCMCIA card you plugged in, because they actually managed to route the PCMCIA interrupt to an IRQ line, not a GPIO pin. [EMAIL PROTECTED] said: So the real question here is whether it is ever acceptable to say that a possible configuration is just silly and ruleset will ignore it, in order to hold down ruleset complexity and simplify the user experience. The cost of deciding that the answer to that question is yes, sometimes is that on rare occasions like this one you might have to haul out a text editor to tweak something in your config. As I said earlier, there are two main cases which should be considered entirely separately. There are the cases which are insane, and which won't ever work, or probably even compile. Those should be hard-coded off in the ruleset and it should not be possible to enable them without hacking. For the cases where we just want to make life simpler for the users, the constraints should be dependent on the user mode. In NOVICE mode you hide them, in EXPERT mode you make them available. The current (CML1) solution has problems, and it only provides real support for a small range of people at the hacker end of the spectrum. Making CML2 useful for a far wider range of people is a laudable goal. But please take care to ensure that the set of people for whom CML2 is useful is a strict superset of those for whom CML1 was useful. In particular, please don't strive to make Aunt Tillie happy on the one occasion on which she configures her kernel at a cost of rendering CML2 less useful for those for whom kernel configuration is an every-day task. Once weighted appropriately, that tradeoff is particularly easy to decide upon. If you ever find yourself seriously suggesting that a developer would need to ditch CML2 and hack the config files directly in order to compile support for, for example, the DiskOnChip he just dropped into the DIL socket in his Ethernet card, then I would suggest that you have made a wrong choice somewhere down the road. Please backtrack and reconsider an earlier decision before you're eaten by a grue. We already have a distinction between config options which it's sensible to ask the user, and options for which you have to hack #defines in the source code. The options which I have put into drivers/mtd/Config.in are there because I _wanted_ the user to see them. The options which are hidden in the code are there because I made the opposite decision. There is a reasonably well-defined boundary for such things already, and it's found all over the kernel. Adding a new, higher boundary for Aunt Tillie is just fine - but please don't _move_ the existing one that most of us care about. -- dwmw2 - 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: Background to the argument about CML2 design philosophy
1. The Mac derivations were half-right. The MAC_SCC one is good but Macs can have either of two different SCSI controllers. I fixed that with help from Ray Knight, who maintains the 68K Mac port. If I understand the philosophy correctly, it is still possible to specify additional cards for those Macs which have PCI slots. If so, absolutely fine - I can shove my Adaptec 19160 into my G4 and have it work just as well as it currently does in my Athlon. One caveat though - not all Macs have SCSI controllers, and not all that do even have one of the two standard ones. The Blue and White G3, the iMac, the PowerBook G3 Firewire and later models on these lines all lack a built-in SCSI controller, but many could have one added via PCI or CardBus slots. The PowerBooks 5300 and 190 (and possibly others) use some non-standard P.O.S. hanging off the NuBus, which even mkLinux doesn't know how to drive. However, in these situations, disabling the extra drivers is usually not critical unless you're running low on space somewhere. At that point, you enable the Are you insane? module outlined below... 3. The MVME derivations are correct *if* (and only if) you agree to ignore the possibility that somebody could want to ignore the onboard hardware, plug outboard disk or Ethernet cards into the VME-bus connector, and do something like running SCSI-over-ATAPI to the outboard device. (I missed these possibilities when I wrote the derivations.) ...and then someone else mentioned the possibility of f*x0r3d hardware. In this case, I would say this *isn't* a kernel-configuration issue but one of being able to disable the drivers for the malfunctioning hardware. If I have a PCMCIA controller that reboots the machine as soon as the driver tries to switch it on, I should be able to send a command-line parameter to the kernel which tells it to switch it off *at run-time*. And iff I'm running with hardware which is so f*x0r3d that that isn't enough, I'd either fix the hardware or hack the config files. I don't see the problem. I think the MVME derivations are *perfectly* sensible - if the reference board and most (read: virtually all) derivatives have those features, turn them on by all means. To satisfy some others, you might want to say Hey, these guys might want to *explicitly turn off* some of this stuff - so provide an option under Are you insane? which presents all the derived symbols and allows the hackers to manually turn stuff off. -- from: Jonathan Chromatix Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -END GEEK CODE BLOCK- - 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: Background to the argument about CML2 design philosophy
Jonathan Morton [EMAIL PROTECTED]: One caveat though - not all Macs have SCSI controllers, and not all that do even have one of the two standard ones. I know. But these derivations are only for the old 68K macs, which don't have PCI. Closed issue. 3. The MVME derivations are correct *if* (and only if) you agree to ignore the possibility that somebody could want to ignore the onboard hardware, plug outboard disk or Ethernet cards into the VME-bus connector, and do something like running SCSI-over-ATAPI to the outboard device. ...and then someone else mentioned the possibility of f*x0r3d hardware. In this case, I would say this *isn't* a kernel-configuration issue but one of being able to disable the drivers for the malfunctioning hardware. But the other side is going to ask: suppose you're memory-limited (quite likely on older SBCs) and don't want to pay the core cost of drivers you won't use? I don't really think we can duck this question by talking about boot-time parameters. I think the MVME derivations are *perfectly* sensible - if the reference board and most (read: virtually all) derivatives have those features, turn them on by all means. That's my gut feeling, too. But a lot of people insist that the only right way is totally fine-grained control, even in weird edge cases like this one. To satisfy some others, you might want to say Hey, these guys might want to *explicitly turn off* some of this stuff - so provide an option under Are you insane? which presents all the derived symbols and allows the hackers to manually turn stuff off. Interesting thought... -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a I cannot undertake to lay my finger on that article of the Constitution which grant[s] a right to Congress of expending, on objects of benevolence, the money of their constituents. -- James Madison, 1794 - 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: Background to the argument about CML2 design philosophy
David Woodhouse [EMAIL PROTECTED]: I think you already have the mechanism required to answer this - in NOVICE mode you disallow the strange choices, in EXPERT mode you allow them. That pushes the third button. I'm nervous that if we go down this path we will end up with a thicket of modes and a combinatorial explosion in ruleset complexity, leading immediately to a user configuration experience that is more complex than necessary, and eventually to an unmaintainable mess in the rulesfiles. In order to prevent that happening, I would like to have some recognized criterion for configuration cases that are so perverse that it is a net loss to accept the additional complexity of handling them within the configurator. A lot of people (including, apparently, you) are saying there are no such cases. I wonder if you'll change your minds when you have to handle the overhead yourselves? Sigh... -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Government is not reason, it is not eloquence, it is force; like fire, a troublesome servant and a fearful master. Never for a moment should it be left to irresponsible action. -- George Washington, in a speech of January 7, 1790 - 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: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] said: I'm nervous that if we go down this path we will end up with a thicket of modes and a combinatorial explosion in ruleset complexity, leading immediately to a user configuration experience that is more complex than necessary, and eventually to an unmaintainable mess in the rulesfiles. Having too many such modes would be a horrible mess, I agree. In order to prevent that happening, I would like to have some recognized criterion for configuration cases that are so perverse that it is a net loss to accept the additional complexity of handling them within the configurator. A lot of people (including, apparently, you) are saying there are no such cases. I wonder if you'll change your minds when you have to handle the overhead yourselves? Of course there are such cases. The criterion is that the code does not compile or if it did, it could never be expected to work - like SCSI drivers without SCSI generic, or PCI devices without CONFIG_PCI. This is the major criterion which has defined the dependencies already in the config files. You want to add a new mode which hides some of the more esoteric options. That's fine. So do so, and then we have two modes. It's still not an unmaintainable mess. If having even two modes is going to be too troublesome, then keep the one we have. You can try to simplify it later by encouraging individual maintainers to hide stuff behind CONFIG_*_ADVANCED options. But keep that strictly separate from the CML2 discussion. -- dwmw2 - 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: Background to the argument about CML2 design philosophy
On Sun, May 20, 2001 at 04:47:00PM -0400, Eric S. Raymond wrote: In order to prevent that happening, I would like to have some recognized criterion for configuration cases that are so perverse that it is a net loss to accept the additional complexity of handling them within the configurator. It doesn't compile/link would be a good one. It requires subsystem FOO to operate is another (think about IDE DMA drivers and the IDE subsystem, or NIC drivers vs CONFIG_NET) A lot of people (including, apparently, you) are saying there are no such cases. I wonder if you'll change your minds when you have to handle the overhead yourselves? Somehow the current overhead isn't that high. You might argue that the current Config.in is broken given my definition. That is fixable with a day of work; I've been doing so on a regular basis with the tooling I wrote for automatic testing of this. Maybe it would be possible to separate hard dependencies like the current system has with the soft ones one needs for entry-level configtools. Or maybe it needs 2 files for that.. CML1 style (style, maybe not syntax) ones and the newstyle info. I liked the suggestion where the automatic derivations got turned into manual ones for expert mode... I haven't tried CML2 yet (I've yet to find a suitable .deb of Python2 for my Debian Potato playbox) so I don't know if that is actually possible, or that it requires some redesign. Greetings, Arjan van de Ven - 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: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] said: Maybe it would be possible to separate hard dependencies like the current system has with the soft ones one needs for entry-level configtools. Actually, the current system has both types. As well as the hard dependencies, we also have stuff like CONFIG_PARTITION_ADVANCED, CONFIG_CPU_ADVANCED, CONFIG_FBCON_ADVANCED, CONFIG_MTD_DOCPROBE_ADVANCED, etc. CONFIG_EXPERIMENTAL serves a very similar purpose, too. These things have already been set up in the way that developers prefer it. CML2 allows us to be more flexible than we were before, and that can be a good thing when used in moderation. But please, for the sake of the sanity of all concerned, do things one at a time. Provide for merging into 2.5 a set of rules which reproduce the existing CML1 behaviour in this respect. Eric, if you want to make further changes later to introduce new 'modes' for kernel configuration, that's an entirely separate issue. Please don't confuse the issue by trying to do it at the same time as introducing CML2. CONFIG_AUNT_TILLIE does not require CML2. CML2 does not require CONFIG_AUNT_TILLIE. Let's not talk about CONFIG_AUNT_TILLIE any more, or change the existing behaviour of config options to make that the default, until we've settled the discussion about CML2. -- dwmw2 - 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: Background to the argument about CML2 design philosophy
Eric == Eric S Raymond [EMAIL PROTECTED] writes: Eric The first candidates I found were questions associated with Eric built-in SCSI and Ethernet on Macintoshes, on the Sun 3 and Eric Sun3x, and with built-in facilities on the MVME147 single-board Eric computer. So I wrote derivations that looked like this: [snip derive rules] Eric # These were separate questions in CML1 derive MAC_SCC from MAC Eric SERIAL derive MAC_SCSI from MAC SCSI derive SUN3_SCSI from Eric (SUN3 | SUN3X) SCSI Eric By doing this I killed two birds with one stone -- got rid of Eric some holes in Configure.help and (more importantly) moved the Eric configuration experience away from low-level, hardware-oriented Eric questions towards where I think it ought to be. That is, you Eric specify a platform and the services you want and the ruleset Eric computes the low-level facilities to be linked in. And you suddenly imposed decisions on people. Wether or not you are an expert it is reasonable to expect that you want to use modules just as it is just as reasonable to expect that you do not. In some cases you want your Ethernet as a module in some case you want the low level SCSI driver but not the SCSI mid layer. Eric After some back-and-forthing about the technical facts, several Eric things emerged: Eric 1. The Mac derivations were half-right. The MAC_SCC one is good Eric but Macs can have either of two different SCSI controllers. I Eric fixed that with help from Ray Knight, who maintains the 68K Mac Eric port. Eric 2. Nobody had a problem with the SUN3_SCSI derivation. Did you ever get an ACK on it or no answer? Eric 3. The MVME derivations are correct *if* (and only if) you agree Eric to ignore the possibility that somebody could want to ignore the Eric onboard hardware, plug outboard disk or Ethernet cards into the Eric VME-bus connector, and do something like running SCSI-over-ATAPI Eric to the outboard device. (I missed these possibilities when I Eric wrote the derivations.) Or wants to use modules. And yes Aunt Tillie might want to do so, if the person who sold her her Linux CD provided a bunch of scripts for packing up things in a specific way. Eric The MVME situation is an almost perfect test case, because while Eric breaking the assumption behind that derivation is physically Eric possible it would be a rather perverse thing to do. The VME147 Eric is an old design, dating from 1988; it's long since been Eric superseded by MPCxxx SBCs based on the PowerPC that have a Eric better processor, lower power consumption, and more on-board Eric peripheral hardware. IDE/ATAPI didn't exist during most of its Eric design lifetime, and the only way anyone is ever going to hook Eric an outboard device to one of these puppies again is if some Eric hacker pulls a dusty one off a shelf for some garage project. Bt wrong. The MVME cards are still heavily used in control systems and similar places. It's the only place where m68k usage is not dying for real. Eric So far, I have to say I'm disappointed in the quality of the Eric debate. Almoist nobody seems to want to think about this Eric tradeoff globally, as a systems design issue. Instead, I'm Eric hearing a lot of reflexive chuntering that we have to do things Eric a certain way because we've always done them a certain way, and Eric who am I to even dare *think* about raising different Eric possibilities? So far the introduction of CML2 has been overly disppointing, from day one it's been 'I have this great idea and since I think it's great, you obviously have to think so as well'. Now I take it the derived rules are still only enforced under the 'novice' option, though you haven't exactly made that clear in the discussion (nor did you do so when you initially brought it up). Jes - 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: Background to the argument about CML2 design philosophy
David Woodhouse [EMAIL PROTECTED]: Let's not talk about CONFIG_AUNT_TILLIE any more, or change the existing behaviour of config options to make that the default, until we've settled the discussion about CML2. What discussion is that? Unless Linus has changed his mind and I don't know about it, CML2 is going in between 2.5.1 and 2.5.2. The engine is working. Why is it not yet time to discuss ruleset design and modes? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a That the said Constitution shall never be construed to authorize Congress to infringe the just liberty of the press or the rights of conscience; or to prevent the people of the United states who are peaceable citizens from keeping their own arms... -- Samuel Adams, in Phila. Independent Gazetteer, August 20, 1789 - 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: Background to the argument about CML2 design philosophy
derive MVME147_SCSI from MVME147 SCSI It seems that the preferred semantics would be: default MVME147_SCSI from MVME147 SCSI That way the platform defines sane defaults, but no flexibility has been taken away. Presumably many of these defaulted options would also be ones that would be configured not to be changeable in novice mode. The novice gets the vanilla platform defaults without being bothered by detailed options, and can switch to expert mode if they need more control. The experts get all the options presented, but also get to benefit from the smart platform defaults. Ben - 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: Background to the argument about CML2 design philosophy
On Sun, 20 May 2001, Eric S. Raymond wrote: In order to prevent that happening, I would like to have some recognized criterion for configuration cases that are so perverse that it is a net loss to accept the additional complexity of handling them within the configurator. Simple: That extreme perversion represent a kernel that wouldn't compile. You can't have NFS support if you didn't select networking support, etc. Such is the recognized basics. Next, you can ask the question if you would have to modify the ruleset to add a new driver to be able to use a feature. Exemple: will you need to write a new driver for a special IDE interface card and add it in the ruleset before you could use IDE cdrom support on the MVME147 SBC? If you have to edit it anyway then it shouldn't be much pain to remove the unconditionnal removal of IDE support for that target. For all other combinations where a slight possibility might make you doubt then the choice should remain at least in expert mode. People might also want to remove support for subsystems on a specific target even if the device comes soldered on it, just because they won't use it anyway and they want to optimize their kernel size for better memory usage. IMHO your design goal now is mainly about finding a way to describe rule derivation related to the selected expertise mode, and only enforce the strictly impossible combinations for expert mode, just like CML1 is doing while removing obvious derivations for novice users. Now you protest with: That pushes the third button. I'm nervous that if we go down this path we will end up with a thicket of modes and a combinatorial explosion in ruleset complexity, leading immediately to a user configuration experience that is more complex than necessary, and eventually to an unmaintainable mess in the rulesfiles. Eric: with this I think you know what everybody here is wishing for, and you just perfectly stated your design constraint in achieving it. You can't avoid the all semi-possible combination allowed mode. So let's switch to the implementation discussion instead. Nicolas - 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: Background to the argument about CML2 design philosophy
On 20 May 2001, Robert M. Love wrote: I feel that there should *never ever* be a legit situation that the configuration tool does not allow. Not ever. Two reasons: First, I tend to trust the config tools (perhaps too much). If they tell me x implies y, or x implies not y, I will believe it. I won't think hm, the code must be wrong, let me hand edit the config (which is something I don't want to have to do, anyhow). Then just don't go as far as using it in Expert (might be unsafe) mode. If you blindly trust the tool that much the intermediate mode might be what you need. Nicolas - 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/
