Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 February 2007 10:16:17 -0500, Mark Lord wrote: > > That interface is driven entirely backwards. > The funtionality option should always be visible, You are absolutely correct. The _interface_ is horrible. And changing the config language won't change that fact one bit. Make *config is broken, not the Kconfig files underneith. Jörn -- Joern's library part 13: http://www.chip-architect.com/ - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 Feb 2007, Mark Lord wrote: I'm with Linus 100% here. It's really irritating to upgrade to a newer kernel, using the same old .config file, and then discover that my MythTV box no longer auto-boots to record programs. The reason being, that /proc/acpi/alarm no longer exists, and the kernel option to configure it has mysteriously disappeared from the menus. After an hour of hand examining and grep'ing Kconfig files, I eventually find the secret little totally-unrelated option that has to be selected to make the ACPI alarm option visible again. Doh! That interface is driven entirely backwards. The funtionality option should always be visible, and should "select" (or hey, invent a better mechanism, I'm not fussy), the underlying crap required to let me use it. I've been compiling and deploying kernels since 0.99 days, and I still get bit by this sort of thing. This is one of the reasons why I've liked the minimal config option that Rob Landley has proposed a few times wher eyou specify the things that you need and let the build system put in the nessasary dependancies. I started out useing menuconfig, used the TCL based xconfig, but went back to menuconfig when the new xconfig came out (I now do most of my kernel compiles on remote machines that I may or may not have X access to anyway) especially if a particular driver/feature doesn't want to compile, tracking down how to turn it off can be a pain. The idea that Alan posted of saying 'disabling this function will disable the following things as well' would be an extremely useful enhancement. I think that there are more of us out here that configure and compile kernels, but aren't kernel hackers then most people (especialy the distros) want to admit. (and for that matter, many of the distro support policies activly discourage people from telling the distro when they compile a kernel) David Lang - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 Feb 2007, Mark Lord wrote: I'm with Linus 100% here. It's really irritating to upgrade to a newer kernel, using the same old .config file, and then discover that my MythTV box no longer auto-boots to record programs. The reason being, that /proc/acpi/alarm no longer exists, and the kernel option to configure it has mysteriously disappeared from the menus. After an hour of hand examining and grep'ing Kconfig files, I eventually find the secret little totally-unrelated option that has to be selected to make the ACPI alarm option visible again. Doh! That interface is driven entirely backwards. The funtionality option should always be visible, and should select (or hey, invent a better mechanism, I'm not fussy), the underlying crap required to let me use it. I've been compiling and deploying kernels since 0.99 days, and I still get bit by this sort of thing. This is one of the reasons why I've liked the minimal config option that Rob Landley has proposed a few times wher eyou specify the things that you need and let the build system put in the nessasary dependancies. I started out useing menuconfig, used the TCL based xconfig, but went back to menuconfig when the new xconfig came out (I now do most of my kernel compiles on remote machines that I may or may not have X access to anyway) especially if a particular driver/feature doesn't want to compile, tracking down how to turn it off can be a pain. The idea that Alan posted of saying 'disabling this function will disable the following things as well' would be an extremely useful enhancement. I think that there are more of us out here that configure and compile kernels, but aren't kernel hackers then most people (especialy the distros) want to admit. (and for that matter, many of the distro support policies activly discourage people from telling the distro when they compile a kernel) David Lang - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 February 2007 10:16:17 -0500, Mark Lord wrote: That interface is driven entirely backwards. The funtionality option should always be visible, You are absolutely correct. The _interface_ is horrible. And changing the config language won't change that fact one bit. Make *config is broken, not the Kconfig files underneith. Jörn -- Joern's library part 13: http://www.chip-architect.com/ - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On 2/7/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: And yes, then it's almost always correct to "turn things on as needed to make everything work out right", while turning things off would be actively wrong. I see a scenario (many others may have got this idea):- Reading H/W config at the time of doing make (x)config. Idea is to tell the user.hey you have SATA disk, so you can't disable this! (making life easier while compiling the kernel, kinda fast track auto support) Can we do this (some how by Kconfig) by reading from the device info /etc/sysconfig/hwconf or any other way? If we could do that like above, how to manage dynamic devices - say I plug in a USB based Printer? Or a simple USB Thumb drive? Giving the user "Optional Selection" settings from Kconfig? Say, after H/W auto detection by Kconfig, hand over the user an option - "Buddy, do you want to add any other device support into this kernel?" Does this makes sense, Linus? Linus ~Akula2 - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On 2/7/07, Linus Torvalds [EMAIL PROTECTED] wrote: And yes, then it's almost always correct to turn things on as needed to make everything work out right, while turning things off would be actively wrong. I see a scenario (many others may have got this idea):- Reading H/W config at the time of doing make (x)config. Idea is to tell the user.hey you have SATA disk, so you can't disable this! (making life easier while compiling the kernel, kinda fast track auto support) Can we do this (some how by Kconfig) by reading from the device info /etc/sysconfig/hwconf or any other way? If we could do that like above, how to manage dynamic devices - say I plug in a USB based Printer? Or a simple USB Thumb drive? Giving the user Optional Selection settings from Kconfig? Say, after H/W auto detection by Kconfig, hand over the user an option - Buddy, do you want to add any other device support into this kernel? Does this makes sense, Linus? Linus ~Akula2 - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Wed, 7 Feb 2007, David Woodhouse wrote:
>
> I think 'make oldconfig_noselect' is the way forward. We can both have
> what we want.
Actually, I think there might be an even more interesting schenario.
The Kconfig language right not is ternary, which is fine as an arithmetic,
but the problem *may* be that we actually want it to be more expressive.
If instead of a ternary "y/m/n" calculus, we would use a "Y/y/m/n/N"
quinary logic, where "Y" and "N" are like "force on/off", you might have
the following:
"y + depends on => n"
"Y + depends on => Y, and the depends on to Y too"
"n/N + depends on => n"
"y/Y + selected => y"
"n + select => y"
"N + select => N, and the select to N"
In other words, "Y" means "force to Y, even if it has a dependency (which
we'll also have to force", while "N" means "force to N, even if it is
getting selected, in which case the selection will also be forced to N").
So then you can say things like
- edit .config, and set *any* value to "Y", and it will force-enable
anything that that depends on when you run "make oldconfig", even if it
was an "depends on"
- edit .config, and set *any* value to "N", and it fill force-disable
anything that selects that when you you run "make oldconfig"
The problem here is that:
- you can get inconsistent situations ("but he wanted to both force that
on *and* off!")
- "select" actually is much nicer, in that it unambiguously selects one
other symbol. But "depends on" is very hard to force, because you may
have something like (totally made up)
depends on X86 || (ALPHA && PCI)
which is impossible to force (*which* one do you force?) on.
but something like this would be nice for both the text-based "make
oldconfig" kind of thing *and* for any graphical configuration things
("dammit, I want this OFF, when I press the force-off-buffon you turn
anything off that needs it!")
But the two problems above might make it impractical..
Linus
-
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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 2007-02-06 at 16:21 -0800, Linus Torvalds wrote: > > On Wed, 7 Feb 2007, David Woodhouse wrote: > > > > It isn't that far off, and we could improve it if we wanted to. In > > _general_ it's quite good already. > > I agree that it's close to hierarchical. But it's literally the exceptions > that get you. > > Let me mention (again) USB_STORAGE and ATA. > > They are not "under" SCSI. Making them do that would be insane. But in the graphical tool that's _good_. Because those are the options you _wanted_ to see. You don't want to go digging around under the SCSI menu where all those boring hostadapters are, but you _do_ get to see the USB and ATA stuff elsewhere. But that's only for the graphical tool, which is where I actually expected the handholding to be required. If you want it in 'oldconfig' then I think that's weird, but I don't have a better solution than 'select', unfortunately. > > It would work quite nicely in the graphical tools, although you've > > thrown me a little by wanting it in the hacker's tool 'oldconfig' too. > > You obviously care more about turning stuff _on_ with 'make oldconfig' > > while other people who've spoken up seem to care more, as I do, about > > turning stuff _off_ that way. If I want my hand held, I'm happy enough > > to use the graphical tools. > > I tend to just edit the .config file, and run "make oldconfig". And I know > I'm not the only one, because I've talked to others who do the same. That's exactly what I do too. > And yes, then it's almost always correct to "turn things on as needed to > make everything work out right", while turning things off would be > actively wrong. My experience is exactly the opposite; perhaps because I spend so much of my time working on the Fedora kernel where almost everything starts off enabled by default, and I only ever want to turn stuff off. I think 'make oldconfig_noselect' is the way forward. We can both have what we want. -- 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
Linus Torvalds wrote: On Wed, 7 Feb 2007, David Woodhouse wrote: It isn't that far off, and we could improve it if we wanted to. In _general_ it's quite good already. I agree that it's close to hierarchical. But it's literally the exceptions that get you. Let me mention (again) USB_STORAGE and ATA. They are not "under" SCSI. Making them do that would be insane. But yes, you can do hierarchies by adding "pseudo-variables": as mentioned several times, we could actually split CONFIG_SCSI into two separate ones: CONFIG_SCSI that selects the core infrastructure, and CONFIG_SCSI_DRIVER that actually controls the "hierarchical visibility". Then CONFIG_SCSI_DRIVER (and USB_STORAGE, and SATA) would just do a simple 'select SCSI'. It would _not_ be hierarchical, and it would very much use that same old "select", but it would possibly be a cleanup at least in the sense that now CONFIG_SCSI wouldn't be used two different ways (one to hide most SCSI drivers, and one to enable the core SCSI infrastructure code). It would work quite nicely in the graphical tools, although you've thrown me a little by wanting it in the hacker's tool 'oldconfig' too. You obviously care more about turning stuff _on_ with 'make oldconfig' while other people who've spoken up seem to care more, as I do, about turning stuff _off_ that way. If I want my hand held, I'm happy enough to use the graphical tools. I tend to just edit the .config file, and run "make oldconfig". And I know I'm not the only one, because I've talked to others who do the same. And yes, then it's almost always correct to "turn things on as needed to make everything work out right", while turning things off would be actively wrong. That seems odd to me. I usually use edit + oldconfig to disable a symbol. Maybe to enable a symbol occasionally. But the symbols that I want to enable usually aren't listed in .config at all, so I end up using another config tool to enable them. E.g., a sound driver when SOUND is completely disabled. -- ~Randy - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Wed, 7 Feb 2007, David Woodhouse wrote: > > It isn't that far off, and we could improve it if we wanted to. In > _general_ it's quite good already. I agree that it's close to hierarchical. But it's literally the exceptions that get you. Let me mention (again) USB_STORAGE and ATA. They are not "under" SCSI. Making them do that would be insane. But yes, you can do hierarchies by adding "pseudo-variables": as mentioned several times, we could actually split CONFIG_SCSI into two separate ones: CONFIG_SCSI that selects the core infrastructure, and CONFIG_SCSI_DRIVER that actually controls the "hierarchical visibility". Then CONFIG_SCSI_DRIVER (and USB_STORAGE, and SATA) would just do a simple 'select SCSI'. It would _not_ be hierarchical, and it would very much use that same old "select", but it would possibly be a cleanup at least in the sense that now CONFIG_SCSI wouldn't be used two different ways (one to hide most SCSI drivers, and one to enable the core SCSI infrastructure code). > It would work quite nicely in the graphical tools, although you've > thrown me a little by wanting it in the hacker's tool 'oldconfig' too. > You obviously care more about turning stuff _on_ with 'make oldconfig' > while other people who've spoken up seem to care more, as I do, about > turning stuff _off_ that way. If I want my hand held, I'm happy enough > to use the graphical tools. I tend to just edit the .config file, and run "make oldconfig". And I know I'm not the only one, because I've talked to others who do the same. And yes, then it's almost always correct to "turn things on as needed to make everything work out right", while turning things off would be actively wrong. Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 2007-02-06 at 15:55 -0800, Linus Torvalds wrote: > > On Tue, 6 Feb 2007, David Woodhouse wrote: > > > > Really, if our config is set up in sensible submenus (as in general it > > _is_), the "see everything" behaviour really isn't bad. > > There are two fundamental problems with that statement: > > - no, it really isn't always > >Quite often, our Kconfig files have dependencies that are about where >the *code* exists, rather than about some nice hierarchical system. > >Think of it this way: would you use a programming language that didn't >allow you anything but totally hierarcical language constructs? No sane >person would - because real life isn't hierarchical. Yes, there are >many things that are, but not all things are. > >Example: many cryptographic algorithms are in crypto/. But then a lot >of them ARE NOT. They are in arch/so-and-so/crypto/ or similar. Notice? > >NOT HIERARCHICAL. It isn't that far off, and we could improve it if we wanted to. In _general_ it's quite good already. > - I don't use menus at all. I use the good old textual "make oldconfig". >Trust me, I _want_ those irrelevant questions gone. They aren't "grayed >out". > > So you seem to have this *wish* that real life was different than it is. > But we aren't hierarchical, and even if we were, it *still* wouldn't work > the way you want things to work. It would work quite nicely in the graphical tools, although you've thrown me a little by wanting it in the hacker's tool 'oldconfig' too. You obviously care more about turning stuff _on_ with 'make oldconfig' while other people who've spoken up seem to care more, as I do, about turning stuff _off_ that way. If I want my hand held, I'm happy enough to use the graphical tools. I think the answer is probably just to go ahead and implement the 'make oldconfig_noselect' so we can all have what we want. -- 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 Feb 2007, David Woodhouse wrote: > > Really, if our config is set up in sensible submenus (as in general it > _is_), the "see everything" behaviour really isn't bad. There are two fundamental problems with that statement: - no, it really isn't always Quite often, our Kconfig files have dependencies that are about where the *code* exists, rather than about some nice hierarchical system. Think of it this way: would you use a programming language that didn't allow you anything but totally hierarcical language constructs? No sane person would - because real life isn't hierarchical. Yes, there are many things that are, but not all things are. Example: many cryptographic algorithms are in crypto/. But then a lot of them ARE NOT. They are in arch/so-and-so/crypto/ or similar. Notice? NOT HIERARCHICAL. - I don't use menus at all. I use the good old textual "make oldconfig". Trust me, I _want_ those irrelevant questions gone. They aren't "grayed out". So you seem to have this *wish* that real life was different than it is. But we aren't hierarchical, and even if we were, it *still* wouldn't work the way you want things to work. Linus "reality bites" Torvalds - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 Feb 2007, Randy Dunlap wrote: > Besides this select business, Bill (or someone :) mentioned a > feature that I requested about 8 months ago: the ability to disable > or enable groups of drivers at one swoop. i vaguely recall that *i* was pushing that idea, and even submitted a couple patches to start the process, but it never really went anywhere. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 Feb 2007, David Woodhouse wrote: > > Out of interest, which people would this be? Not me, certainly. > I _use_ select, for options which don't have questions. There were two > such instances in the context of Ingo's mail of $subject, even. > > And the thing Randy was saying "yes" to, which you elided but I've > restored in the above quotation, was the idea of turning 'select' into > 'depends on' for _user-visible_ options. NOT for the ones which don't > have a question. Example: crypto api. SCSI. firewall "expert mode". Any number of things. Qutie often, the questions themselves are *conditional*. For example, look at the whole INPUT layer thing. It is a real question, but only for EMBEDDED - normally, we just assume we'll use it (but it's a classic example of where we could have used a "select" from the keyboard driver instead). For normal people, it's a question that simply shouldn't be asked. You don't ask normal users whether they want to hook up keyboards and mice (and trust me when I say that: we _used_ to ask. It generated tons of totally idiotic noise). Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 2007-02-06 at 15:41 -0800, Randy Dunlap wrote: > It's quite subjective. E.g., I made/submitted a patch maybe 1 year > ago that tried to put all video graphics (frame buffer, AGP, DRM/DRI, > etc.) into one localized place in the menu structure. > OK, perhaps I wasn't persistent enough, but no one was interested > in it. (That probably just means that config menus are low > priority.) Compared with making the bloody _code_ actually cooperate, in that particular respect, I think the config options are indeed a fairly low priority :) -- 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 06 Feb 2007 23:36:23 + David Woodhouse wrote: > On Tue, 2007-02-06 at 15:28 -0800, Linus Torvalds wrote: > > (Example: I don't want to see IPV6 questions if IPV6 is off, BUT I might > > still want to be able to see the question about NFSv8.1, which only works > > on top of IPV6. I might not even *know* I want IPV6, but I know my company > > uses NFSv8.1, so I say "yes"). > > (Quoting very sparsely but I think honestly -- I think the above is the > essence of what you were saying). > > Actually it doesn't have to be that much of a problem if the config > stuff is laid out sensibly, as Ingo mentioned earlier. Those IPv6 > options you don't want to see are likely to be all in an 'IPv6' submenu > of the networking stuff which nobody forces you to visit. Yet > 'NFSv8.1' (*shudder*) would be elsewhere under networked file systems, > or some suboption of NFS, and you'd see it just fine. > > > And I realize that was a contrieved example, but there are *real* examples > > of this in the kernel today. I may well know that I want 802.11 WEP > > encryption, for example, but I sure as hell had *no* clue that it requires > > ARC4. > > Again, if you don't care about crypto then you're unlikely to be delving > in the crypto menus. Nobody forces you to go there. But when you look at > the greyed-out WEP option and you click on it and it tells you "You need > ARC4 for this. Do you want me to turn it on for you?" (or whatever), you > get what you wanted. > > Really, if our config is set up in sensible submenus (as in general it > _is_), the "see everything" behaviour really isn't bad. Well, there's layout and then there's the tool(s). Besides this select business, Bill (or someone :) mentioned a feature that I requested about 8 months ago: the ability to disable or enable groups of drivers at one swoop. And Matt has made some good scripting suggestions. For layout, we may not all agree on that part either. :) It's quite subjective. E.g., I made/submitted a patch maybe 1 year ago that tried to put all video graphics (frame buffer, AGP, DRM/DRI, etc.) into one localized place in the menu structure. OK, perhaps I wasn't persistent enough, but no one was interested in it. (That probably just means that config menus are low priority.) --- ~Randy - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 2007-02-06 at 15:28 -0800, Linus Torvalds wrote: > (Example: I don't want to see IPV6 questions if IPV6 is off, BUT I might > still want to be able to see the question about NFSv8.1, which only works > on top of IPV6. I might not even *know* I want IPV6, but I know my company > uses NFSv8.1, so I say "yes"). (Quoting very sparsely but I think honestly -- I think the above is the essence of what you were saying). Actually it doesn't have to be that much of a problem if the config stuff is laid out sensibly, as Ingo mentioned earlier. Those IPv6 options you don't want to see are likely to be all in an 'IPv6' submenu of the networking stuff which nobody forces you to visit. Yet 'NFSv8.1' (*shudder*) would be elsewhere under networked file systems, or some suboption of NFS, and you'd see it just fine. > And I realize that was a contrieved example, but there are *real* examples > of this in the kernel today. I may well know that I want 802.11 WEP > encryption, for example, but I sure as hell had *no* clue that it requires > ARC4. Again, if you don't care about crypto then you're unlikely to be delving in the crypto menus. Nobody forces you to go there. But when you look at the greyed-out WEP option and you click on it and it tells you "You need ARC4 for this. Do you want me to turn it on for you?" (or whatever), you get what you wanted. Really, if our config is set up in sensible submenus (as in general it _is_), the "see everything" behaviour really isn't bad. -- 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 Feb 2007, David Woodhouse wrote: > > The other possibility which comes to mind, and which I _have_ seen > implemented, is not to hide the disabled option but to _show_ it, and > represent its dependencies right there next to it somehow. That would probably work, especially if you had some way to "warp" to the other options (so that if you see "depends on SCSI" you could say "ok, go to SCSI then". However, I have this suspicion that you'd just drown in options that you really don't want to see. > Well one option, as you suggest, is just that if you go into the > graphical tool and enable USB_STORAGE, you get SCSI turned on > automatically. Yes. That basically is what "select" means, though. The difference is, indeed, largely about visibility. If everything was always visible, there really wouldn't be much of a difference between "depends on" and "select". In both cases, when you click on something that depends on or selects something else, the config tool would obviously select it. So yes, you can make "depends on" and "select" mean _exactly_ the same thing. But basically only by always showing everything. Which I don't think you want. If I say I don't want IPv6, I really am not interested in seeing some IPv6-only questions. But on the other hand, maybe there is something that _needs_ IPv6 to work, and then maybe I'd like it enabled.. (Example: I don't want to see IPV6 questions if IPV6 is off, BUT I might still want to be able to see the question about NFSv8.1, which only works on top of IPV6. I might not even *know* I want IPV6, but I know my company uses NFSv8.1, so I say "yes"). And I realize that was a contrieved example, but there are *real* examples of this in the kernel today. I may well know that I want 802.11 WEP encryption, for example, but I sure as hell had *no* clue that it requires ARC4. See the problem? I may be a well-educated user who doesn't even *know* that I actually want an encrytion algorithm that I've never heard of. For all I knew, the 802.11 WEP stuff was done inside the wireless cards by hardware.. Does that mean that if I don't have CRYPTO_ARC4 enabled (which in turn would need CRYPTO_ALGAPI enabled too) I'd not even get the choice of WEP? Obviously that is broken. And yes, if you *always* get the choice of *everyting*, then it all boils down to the same thing. I just don't think you do.. Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 2007-02-06 at 15:11 -0800, Linus Torvalds wrote: > > On Tue, 6 Feb 2007, Randy Dunlap wrote: > > > But it doesn't matter. I'll come up with a hack for the tools which make > > > them (optionally) treat 'select' of a user-visible option as if it > > > was just 'depends on'. And that should fix the problem. > > > > Yes, that's the solution that I decided on during lunch also: > > select <==> depends on > > I think yuou can certainly enable an "expert mode", which just reads > "select" as "depends on". > > You'll probably have to do *more* changes to the tools than my suggestion > to just make them let you know why they can't turn something off, though. > Why? Some things don't even have questions at all right now, and their > only life is as implied options that are turned on by others. > > And yes, some silly people who hate "select" have tried to turn them into Out of interest, which people would this be? Not me, certainly. I _use_ select, for options which don't have questions. There were two such instances in the context of Ingo's mail of $subject, even. And the thing Randy was saying "yes" to, which you elided but I've restored in the above quotation, was the idea of turning 'select' into 'depends on' for _user-visible_ options. NOT for the ones which don't have a 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 Feb 2007, Linus Torvalds wrote: > > On Tue, 6 Feb 2007, Randy Dunlap wrote: > > > > Yes, that's the solution that I decided on during lunch also: > > select <==> depends on > > I think yuou can certainly enable an "expert mode", which just reads > "select" as "depends on". Actually, it's probably more useful if you do it for a single symbol only. If you really want to force something off, mark that *single* symbol as having "select " being translated into "depends on", and it will probably work fine in practice. Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 2007-02-06 at 14:53 -0800, Linus Torvalds wrote: > I don't think you've ever showed any such example. > > And if you did, it would all boil down to *exactly* what 'select' does: > config options that get set automatically based on other choices. That's one option which I don't think I've seen implemented. The other possibility which comes to mind, and which I _have_ seen implemented, is not to hide the disabled option but to _show_ it, and represent its dependencies right there next to it somehow. Where I saw this done was actually in the Nemesis kernel configuration, which was based on our old tcl xconfig tool. It actually worked quite well. It's a _long_ time ago now, but IIRC it was in a cell below the disabled option. It'd look something like (remember hte old xconfig?): | USB Mass storage support | o Y o M ✓ N| | depends on: o SCSI ✓ USB | I'm sure I had a screenshot of it once. But it doesn't matter; you get the idea -- our current tools would do it differently anyway. But they _could_ do it. > So care to give a real example? Start with USB automatically selecting > SCSI support without the user having to even know it uses SCSI. Tell me > how it's supposed to work sanely without 'select'. Well one option, as you suggest, is just that if you go into the graphical tool and enable USB_STORAGE, you get SCSI turned on automatically. That's simple enough and the xconfig tool can do it quite easily. It just needs to _show_ you the option, which isn't particularly hard. But what I care about is that when you when you explicitly set # CONFIG_SCSI is not set and run 'make oldconfig' it doesn't get turned back on again. But as I said, I'm not entirely averse to having to do 'make oldconfig-noselect' or something like that to preserve the old behaviour. And then you can sprinkle 'select' wherever you like without bothering those of us who object. -- 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 Feb 2007, Randy Dunlap wrote: > > Yes, that's the solution that I decided on during lunch also: > select <==> depends on I think yuou can certainly enable an "expert mode", which just reads "select" as "depends on". You'll probably have to do *more* changes to the tools than my suggestion to just make them let you know why they can't turn something off, though. Why? Some things don't even have questions at all right now, and their only life is as implied options that are turned on by others. And yes, some silly people who hate "select" have tried to turn them into bool SUBSYSTEM default y depends on X || Y || Z || XY || XZ || YZ or similar, which is a hell of a lot less maintainable than just letting X, Y, Z etc do 'select SUBSYSTEM'. But "select SUBSYSTEM" still does exist, notably in places like SND_PCM (where it would just be INSANE to list all the different sound drivers that want it as a shitload of "depends on") but also for things like NET_CLS and CRYPTO etc. Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 Feb 2007, David Woodhouse wrote: > > I claim that there are _better_ ways to do it than 'select'. I don't think you've ever showed any such example. And if you did, it would all boil down to *exactly* what 'select' does: config options that get set automatically based on other choices. So care to give a real example? Start with USB automatically selecting SCSI support without the user having to even know it uses SCSI. Tell me how it's supposed to work sanely without 'select'. Put up, or shut up. Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 Feb 2007, Haavard Skinnemoen wrote: > > I disagree. I did the exact same thing on AVR32 because !EMBEDDED > forces on tons of crap that just isn't useful on many embedded > platforms. I do agree. EMBEDDED largely means "non-generic/non-standard" these days. It's also true that EMBEDDED does *not* necessarily mean "small", since some of the choices that it disables can often be choices that you want on *big* machines. For example, the whole thing where VGA and keyboard/mouse support default to on when EMBEDDED isn't selected is quite possibly a good reason to enable EMBEDDED on big servers that aren't even meant to be general- purpose, but simply optimized for a particular environment. That is, technically, what "embedded" really means. A lot of the time people talk about it as if it was always "small", but it can be a big computer that is just used in a very specific turn-key environment where some of the default kernel choices may not be sensible. Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 06 Feb 2007 22:38:04 + David Woodhouse wrote: > On Tue, 2007-02-06 at 08:53 -0800, Linus Torvalds wrote: > > > > WE WANT TO BE NICE. > > - the firewall example was not an example of 'select', but of the "we > >want to be nice". But you simply DID NOT GET IT. > > It's a very clever straw man, Linus, but it's still bogus. Not only do I > _agree_ about the firewall example, I've even implemented very similar > things already, of my own accord. I really do get it. > > I don't claim that we shouldn't "be nice". You keep coming back to that > but it bears no relation to what I'm actually saying. > > > - the USB and SATA examples are *also* examples of "we want to be nice", > >and hell yeah, you need 'select' to do them. Claiming anything else is > >just stupid. > > > > So: are you stupid, or do you just refuse to even think about it? > > I claim that there are _better_ ways to do it than 'select'. I claim > that we can 'be nice' without actually screwing over the people who use > non-interactive config methods and need to turn stuff off. A number of > whom have spoken up already but are perhaps less quixotic than I am so > have given up on getting you to listen. Even with the interactive tools it's difficult to turn symbols off if they are selected in multiple places. But that's the old tools issue. But Andrew has done a great job of trying to minimize 'select' in Kconfig files. > 99% of the times I configure a kernel, it's in an RPM package. The > answer "you can use xconfig and press the question mark" isn't > wonderfully useful -- although having xconfig be the answer for those > who need the extra guidance that 'select' currently offers is perhaps a > more reasonable solution. > > But it doesn't matter. I'll come up with a hack for the tools which make > them (optionally) treat 'select' of a user-visible option as if it was > just 'depends on'. And that should fix the problem. Yes, that's the solution that I decided on during lunch also: select <==> depends on --- ~Randy - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On 2/6/07, Matt Mackall <[EMAIL PROTECTED]> wrote: A number of current users are indeed bogus. Stuff like: config SUPERH bool default y select EMBEDDED Just because you're using a SuperH board doesn't mean you want to turn off standard features. I disagree. I did the exact same thing on AVR32 because !EMBEDDED forces on tons of crap that just isn't useful on many embedded platforms. I trust our users to actually enable for example virtual terminal support if they happen to need it. Far from everyone do, and it's going to end up as dead code unless they also enable the right framebuffer driver. Haavard - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 2007-02-06 at 08:53 -0800, Linus Torvalds wrote: > > WE WANT TO BE NICE. > - the firewall example was not an example of 'select', but of the "we >want to be nice". But you simply DID NOT GET IT. It's a very clever straw man, Linus, but it's still bogus. Not only do I _agree_ about the firewall example, I've even implemented very similar things already, of my own accord. I really do get it. I don't claim that we shouldn't "be nice". You keep coming back to that but it bears no relation to what I'm actually saying. > - the USB and SATA examples are *also* examples of "we want to be nice", >and hell yeah, you need 'select' to do them. Claiming anything else is >just stupid. > > So: are you stupid, or do you just refuse to even think about it? I claim that there are _better_ ways to do it than 'select'. I claim that we can 'be nice' without actually screwing over the people who use non-interactive config methods and need to turn stuff off. A number of whom have spoken up already but are perhaps less quixotic than I am so have given up on getting you to listen. 99% of the times I configure a kernel, it's in an RPM package. The answer "you can use xconfig and press the question mark" isn't wonderfully useful -- although having xconfig be the answer for those who need the extra guidance that 'select' currently offers is perhaps a more reasonable solution. But it doesn't matter. I'll come up with a hack for the tools which make them (optionally) treat 'select' of a user-visible option as if it was just 'depends on'. And that should fix the problem. -- 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
Matt Mackall wrote: On Tue, Feb 06, 2007 at 11:04:31AM -0500, Bill Davidsen wrote: There's no reason we shouldn't be able to do exactly that with config symbols in Kconfig-land. The only difference is that we've got slightly different semantics for our "depend" keyword. Things which don't have their "depend" requirements met aren't offered as options. Whereas "select" is "automatically pull in dependencies" apt/yum-style. Perhaps this is because there is a lacking keyword. The depends controls visibility, perhaps a "requires" could be used to provide advisory information which mean "these other things will be turned on if you build this feature." "require" is a bad name as it's a synonym of "depend". While we're at it, it would also be nice to be able to do: $ kconfig enable ACPI CONFIG_ACPI conflicts with CONFIG_APM $ kconfig enable -F ACPI disabling CONFIG_APM $ kconfig disable SCSI CONFIG_USB_STORAGE depends on CONFIG_SCSI $ kconfig disable -f SCSI disabling USB_STORAGE $ make I think depends and select provide this now, the postulated "requires" might make building the trees easier. The above is all about having a scriptable command line interface so that people don't need the broken sed + make oldconfig thing. I didn't say that clearly, I meant that the information to do this was present, not the functionality. Someone suggested that 'requires' was a synonym of 'depends on' and was a bad choice. I think the requirement is in fasct the same, what I was after was not to prevent visibility of the option as 'depends' does. And we still probably need depends to avoid way too many choices. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, Feb 06, 2007 at 11:04:31AM -0500, Bill Davidsen wrote: > >There's no reason we shouldn't be able to do exactly that with config > >symbols in Kconfig-land. The only difference is that we've got > >slightly different semantics for our "depend" keyword. Things which > >don't have their "depend" requirements met aren't offered as options. > >Whereas "select" is "automatically pull in dependencies" > >apt/yum-style. > > Perhaps this is because there is a lacking keyword. The depends controls > visibility, perhaps a "requires" could be used to provide advisory > information which mean "these other things will be turned on if you > build this feature." "require" is a bad name as it's a synonym of "depend". > >While we're at it, it would also be nice to be able to do: > > > >$ kconfig enable ACPI > >CONFIG_ACPI conflicts with CONFIG_APM > >$ kconfig enable -F ACPI > >disabling CONFIG_APM > >$ kconfig disable SCSI > >CONFIG_USB_STORAGE depends on CONFIG_SCSI > >$ kconfig disable -f SCSI > >disabling USB_STORAGE > >$ make > > > I think depends and select provide this now, the postulated "requires" > might make building the trees easier. The above is all about having a scriptable command line interface so that people don't need the broken sed + make oldconfig thing. -- Mathematics is the supreme nostalgia of our time. - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 Feb 2007, David Woodhouse wrote: > > It's a bad example because it's not relevant to the 'select' question, > and you're trying to use it as a straw man; assigning to me a belief I > just don't have. It *is* relevant. Why are you ignoring the ATA example? Which is exactly the same thing? (And where we do the right thing - we just "select SCSI") Why are you ignoring the USB example - which is exactly the same thing (and where we do the *wrong* thing: we "depend on SCSI" and then we have about 5 lines of warning both around USB and around SCSI and documentation just to say that USB needs it!) > Perhaps I haven't spoken carefully enough. I mean to argue that being > nice is good -- but that we shouldn't do so in a way which _costs_ those > who use the system most. It costs you nothing but arguing. > No, you really aren't paying attention. You CAN DO IT WITHOUT SELECT. No, I was paying attention. You seem to just be obtuse on purpose. WE WANT TO BE NICE. - the firewall example was not an example of 'select', but of the "we want to be nice". But you simply DID NOT GET IT. - the USB and SATA examples are *also* examples of "we want to be nice", and hell yeah, you need 'select' to do them. Claiming anything else is just stupid. So: are you stupid, or do you just refuse to even think about it? > My point is not that we shouldn't be helpful. My point is that 'select' > is the _wrong_ way to be 'helpful', because that's a PITA for other > people. It's a PITA just because you don't listen, and ignore everything I say. In other words, the problem is *you*. The problem is NOT "select". People have even pointed out that you don't even have to create new tools. Use menuconfig and "?", which apparently already tells you what the dependencies are, and why you can't turn something off.. And yes, I just tried. I couldn't turn SCSI off in menuconfig, so I pressed '?', and at the end it does actually say: Selected by: ATA && BLOCK && (!M32R && !M68K || BROKEN) && (!SUN4 || BROKEN) Not hugely readable, and I'm sure it could be improved a lot. And yes, I certainly think that it would be a good idea if there would be other tools that told you too. The Kconfig engine *internally* already knows all this, of course, so all the hard work has already effectively been done, it's just not *shown*. So you should just face it: the problem *really* isn't 'select'. Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Feb 6, 2007, at 9:55 AM, Bill Davidsen wrote: Mark Rustad wrote: On Feb 5, 2007, at 5:32 PM, Linus Torvalds wrote: And I told you that you could just improve the tools that track those dependencies ANYWAY! They aren't that bad even now. Using menuconfig (I'm a fossil that just uses curses for most things), hitting ? shows what depends or selects any particular entry. That is good enough for me now. Maybe I am just willing to ask for help, but the help already seems to be there. I think the problem Linus referenced with not even seeing an option is an issue, you can't "?" on an option you can't see. An I use menuconfig also, from long habit (accessing a remote compile server with slow dialup). Yes, of course. My point was that if you are "the embedded guy" (like I often am) trying to turn something off, the tools show you what to look at already. They are currently no help if the option does not appear, as you say. So automatically selecting things that are required for something is much better than hiding too much. At least it is easy to find out why something is selected if you really want to turn it off. If more things worked as Linus suggests, I don't think the tools need much in the way of improvement. It really is more about how they are used as they are. That is not to say that tools improvements are not always welcome, but the current tools seem to work pretty well. -- Mark Rustad, [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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
Matt Mackall wrote: On Mon, Feb 05, 2007 at 08:09:58PM -0500, Theodore Tso wrote: On Mon, Feb 05, 2007 at 11:21:34PM +, David Woodhouse wrote: But Alan makes a reasonable suggestion -- we could work around this in the tools too. I wouldn't call it "work around this" in the tools. It's a useful feature we can add in the tools for developers who aren't men enough to use "sed/grep" pipelines. :-) But I have to agree with Linus here that we should be optimizing the tools for people who know how to compile the kernel, but who aren't necessarily familiar with all of the hidden dependencies in the literally hundreds of config options in the kernel tree. In reality, you want to make it easy to turn on *or* off any arbitrary config option, and to understand what you need to do so you can turn an arbitrary config option on or off. If that means tools enhancements, so be it. With apt (or presumably with yum), you can happily apt-remove a package that nothing else depends on. If you remove something that other things depend on, you get a list of those things and opportunity to force it (with a -f flag, for instance). If you ask for a package that has other dependencies, it automatically pulls all those things in unless there's a conflict. In which case you can force it again. There's no reason we shouldn't be able to do exactly that with config symbols in Kconfig-land. The only difference is that we've got slightly different semantics for our "depend" keyword. Things which don't have their "depend" requirements met aren't offered as options. Whereas "select" is "automatically pull in dependencies" apt/yum-style. Perhaps this is because there is a lacking keyword. The depends controls visibility, perhaps a "requires" could be used to provide advisory information which mean "these other things will be turned on if you build this feature." While we're at it, it would also be nice to be able to do: $ kconfig enable ACPI CONFIG_ACPI conflicts with CONFIG_APM $ kconfig enable -F ACPI disabling CONFIG_APM $ kconfig disable SCSI CONFIG_USB_STORAGE depends on CONFIG_SCSI $ kconfig disable -f SCSI disabling USB_STORAGE $ make I think depends and select provide this now, the postulated "requires" might make building the trees easier. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
Mark Rustad wrote: On Feb 5, 2007, at 5:32 PM, Linus Torvalds wrote: And I told you that you could just improve the tools that track those dependencies ANYWAY! They aren't that bad even now. Using menuconfig (I'm a fossil that just uses curses for most things), hitting ? shows what depends or selects any particular entry. That is good enough for me now. Maybe I am just willing to ask for help, but the help already seems to be there. I think the problem Linus referenced with not even seeing an option is an issue, you can't "?" on an option you can't see. An I use menuconfig also, from long habit (accessing a remote compile server with slow dialup). -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
David Woodhouse wrote: On Mon, 2007-02-05 at 15:32 -0800, Linus Torvalds wrote: On Mon, 5 Feb 2007, David Woodhouse wrote: The netfilter example is totally irrelevant here, since 'select' is neither necessary nor sufficient for that. Russell and I have both pointed that out to you already. No, the example IS relevant. Why? Because you don't seem to be getting the whole "be nice" part. If you'd come down from your high horse for a moment you might realise that I _agree_ with the 'be nice' part, as long as you don't pessimise things for those who _do_ know what they're doing. The thing you want for netfilter is a _GOOD IDEA_. I agree. I've even implemented something _very_ similar, for JFFS2 compression options. If you want to play about with individual compressors you have to enable the 'Advanced options' first; otherwise you get the sane defaults. Unless you really want to get your hands dirty, you don't have to know which compressors we use by default. One thing which can be solved at the tool level, particularly for netfilter, is to provide options for "turn it all of and I'll select," "turn it all on (or module)," and "reset this page to defaults." Because those starting points will cover a majority of the options. Useful for device drivers as well, particularly network cards and disk controllers, where there are a vast number of choices. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
Linus Torvalds wrote: On Mon, 5 Feb 2007, David Woodhouse wrote: Ten years ago, people used 'depends on' to fix the tools, so that then you want to enable something like USB_STORAGE, it can automatically turn SCSI on for you. Isn't that what you wanted? Try it. It's not what it does. If you have a depends on SCSI and you did not say you wanted SCSI, you'll never even *see* the question. It will *not* turn on SCSI automatically for you. Quite the reverse. It will not even show you the option. My favorite example of this is selinux, which you don't see unless you enable other unobvious things first. I say unobvious because until you do it the first few times you don't see the option, you ask menuconfig where it is, and it isn't there. So you go use your favorite tool to search the Kconfig until you find out why. Now that's in part a failure of the menuconfig tool I use, which may not be in xconfig (I'll try that later today when I build a new kernel), but it seem odd that a major feature would not show unless something obscure were selected, and that the crypto features needed for selinux would be good candidates for SELECT. Just because config is something mostly done by advanced user doesn't mean it should be difficult or time-consuming. And why say "should have done" for the SCSI mess, it's correctable, if everyone agrees that you are right (who would dare disagree ;-) then it can be fixed. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, Feb 05, 2007 at 11:46:12PM -0600, Matt Mackall wrote: > I'd be happy to turn this into CONFIG_NONSTANDARD or > CONFIG_EXPERT, which is how I described it in the Kconfig help texts: > > menuconfig EMBEDDED > bool "Configure standard kernel features (for small systems)" > help > This option allows certain base kernel options and settings > to be disabled or tweaked. This is for specialized > environments which can tolerate a "non-standard" kernel. > Only use this if you really know what you are doing. > > A number of current users are indeed bogus. Stuff like: > > config SUPERH > bool > default y > select EMBEDDED > > Just because you're using a SuperH board doesn't mean you want to turn > off standard features. > The only thing bogus is the CONFIG_EMBEDDED use itself, if it were only limited to turning options off, you'd be correct, but both PCI and IDE use it for other things. We specifically wanted it for IDE in this case. I'd be quite happy to see CONFIG_EMBEDDED separated entirely from the "advanced/expert/screwing aunt tillie" selection menu, or whatever we're choosing to call it these days. Then we wouldn't have to deal with these confusing defconfigs that expose far more than most users are going to care about. There are a number of other architectures that do this too, so it may be worth separating so we can finally get rid of the confusion. - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
I'm with Linus 100% here. It's really irritating to upgrade to a newer kernel, using the same old .config file, and then discover that my MythTV box no longer auto-boots to record programs. The reason being, that /proc/acpi/alarm no longer exists, and the kernel option to configure it has mysteriously disappeared from the menus. After an hour of hand examining and grep'ing Kconfig files, I eventually find the secret little totally-unrelated option that has to be selected to make the ACPI alarm option visible again. Doh! That interface is driven entirely backwards. The funtionality option should always be visible, and should "select" (or hey, invent a better mechanism, I'm not fussy), the underlying crap required to let me use it. Cheers - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 5 February 2007 15:09:15 -0800, Linus Torvalds wrote: > > Why? You could *trivially* have a tool tell you. Make "xconfig" or > something just pop up a window saying "sorry, you can't disable SCSI, > because you've got ATA enabled, and ATA wants SCSI". That would be useful for both select and depend, as many have pointed out. And ignoring the fairly subjective "be nice" part, either select or depend can completely get removed once the tools have it. What I disagree with is the *trivially* part. For one, the problem is known for some time and has annoyed enough people, yet we don't have patches yet. Secondly, we'd need patches for most, if not all tools. Not having used "xconfig" for the last eight years, I doubt that you'd reach a majority of users with any of the plethora of make *config targets. We _need_ this support and I welcome anyone getting his/her hands dirty writing it up. Jörn -- Fantasy is more important than knowledge. Knowledge is limited, while fantasy embraces the whole world. -- Albert Einstein - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 5 Feb 2007, Ingo Oeser wrote: > On Monday, 5. February 2007, Linus Torvalds wrote: > > So thank God for the few selects we have, and we should add a whole lot > > more! > > But "select" is not fine grained enough. > > I would like to have "require", "recommend", "suggest" for feature A. > > require X > does not work without X, but X is way down the tree > e.g. ext3 and block device or how select currently is intended > > recommend X > it is usable but uncomfortable without X, enabled per default > e.g. firewalling recommends connection tracking support > or NAT recommends all NAT helpers > > suggest X > many people use A together with X, > so you might be interested in enabling it, but I disabled it > per default unless you said "featuritis mode" before. > e.g. highmem and SMP or a network driver and NAPI. > > That is what the Debian/Ubuntu package management does and maybe other too. > And this also gives us new keywords to replace select with, > so migration is doable :-) > > This would also make "EMBEDDED" superflous, because it would just mean > "disable anything not required". > > And this would enable an individual tree for the users current configuration > problem instead of a global one. I think "package manager" is the best possible way to think about this problem. I can't tell you how often I've wished the kernel config process behaved like apt and just prompted me with a list of things it would need to enable to allow me to use the option and ask me if I still want to do it. The reverse when I try and remove something important would be good too just ask me if I really want to remove all those as well. A functional equivelant of deborphan would be cool too. Just run it and have it tell me what is enabled that no devices depend on. The config system is nasty even for power users. There is a fun part of the netfilter code where I find myself having to enable all from one menu, go to the next menu down enable everything and then go back to the first menu. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 2007-02-05 at 15:32 -0800, Linus Torvalds wrote: > On Mon, 5 Feb 2007, David Woodhouse wrote: > > > > The netfilter example is totally irrelevant here, since 'select' is > > neither necessary nor sufficient for that. Russell and I have both > > pointed that out to you already. > > No, the example IS relevant. > > Why? > > Because you don't seem to be getting the whole "be nice" part. If you'd come down from your high horse for a moment you might realise that I _agree_ with the 'be nice' part, as long as you don't pessimise things for those who _do_ know what they're doing. The thing you want for netfilter is a _GOOD IDEA_. I agree. I've even implemented something _very_ similar, for JFFS2 compression options. If you want to play about with individual compressors you have to enable the 'Advanced options' first; otherwise you get the sane defaults. Unless you really want to get your hands dirty, you don't have to know which compressors we use by default. It's a bad example because it's not relevant to the 'select' question, and you're trying to use it as a straw man; assigning to me a belief I just don't have. > You continually argue as if being nice isn't an issue, and shouldn't be > even an option. Perhaps I haven't spoken carefully enough. I mean to argue that being nice is good -- but that we shouldn't do so in a way which _costs_ those who use the system most. > And maybe you can do it without select for netfilter, but you sure as HELL > cannot do it for things like SCSI and the USB/ATA question. No, you really aren't paying attention. You CAN DO IT WITHOUT SELECT. My point is not that we shouldn't be helpful. My point is that 'select' is the _wrong_ way to be 'helpful', because that's a PITA for other people. My point is that if we _want_ someone less experienced to be able to see 'SCSI' light up automatically when they enable USB_STORAGE, then we can do that IN THE TOOLS, as was demonstrated quite capably a decade ago by the Nemesis folks. But you're obviously not actually interested in reading what people say, so I fully expect you to again pick one sentence out of the above and go off at a tangent with a straw man again. So forget it. At least some guidance on when to use depends vs. select _has_ come out of the thread, which can be written up in Documentation/ and referred to later. That should at least improve the _completely_ arbitrary use of 'select' we currently see, such as the patch which started this thread. And I'll go fix the kconfig tools to have an option for treating all 'select' of user-visible options as dependencies, but the benefit of the people who are the _normal_ users of Kconfig stuff. -- 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 2007-02-05 at 15:32 -0800, Linus Torvalds wrote: On Mon, 5 Feb 2007, David Woodhouse wrote: The netfilter example is totally irrelevant here, since 'select' is neither necessary nor sufficient for that. Russell and I have both pointed that out to you already. No, the example IS relevant. Why? Because you don't seem to be getting the whole be nice part. If you'd come down from your high horse for a moment you might realise that I _agree_ with the 'be nice' part, as long as you don't pessimise things for those who _do_ know what they're doing. The thing you want for netfilter is a _GOOD IDEA_. I agree. I've even implemented something _very_ similar, for JFFS2 compression options. If you want to play about with individual compressors you have to enable the 'Advanced options' first; otherwise you get the sane defaults. Unless you really want to get your hands dirty, you don't have to know which compressors we use by default. It's a bad example because it's not relevant to the 'select' question, and you're trying to use it as a straw man; assigning to me a belief I just don't have. You continually argue as if being nice isn't an issue, and shouldn't be even an option. Perhaps I haven't spoken carefully enough. I mean to argue that being nice is good -- but that we shouldn't do so in a way which _costs_ those who use the system most. And maybe you can do it without select for netfilter, but you sure as HELL cannot do it for things like SCSI and the USB/ATA question. No, you really aren't paying attention. You CAN DO IT WITHOUT SELECT. My point is not that we shouldn't be helpful. My point is that 'select' is the _wrong_ way to be 'helpful', because that's a PITA for other people. My point is that if we _want_ someone less experienced to be able to see 'SCSI' light up automatically when they enable USB_STORAGE, then we can do that IN THE TOOLS, as was demonstrated quite capably a decade ago by the Nemesis folks. But you're obviously not actually interested in reading what people say, so I fully expect you to again pick one sentence out of the above and go off at a tangent with a straw man again. So forget it. At least some guidance on when to use depends vs. select _has_ come out of the thread, which can be written up in Documentation/ and referred to later. That should at least improve the _completely_ arbitrary use of 'select' we currently see, such as the patch which started this thread. And I'll go fix the kconfig tools to have an option for treating all 'select' of user-visible options as dependencies, but the benefit of the people who are the _normal_ users of Kconfig stuff. -- 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 5 Feb 2007, Ingo Oeser wrote: On Monday, 5. February 2007, Linus Torvalds wrote: So thank God for the few selects we have, and we should add a whole lot more! But select is not fine grained enough. I would like to have require, recommend, suggest for feature A. require X does not work without X, but X is way down the tree e.g. ext3 and block device or how select currently is intended recommend X it is usable but uncomfortable without X, enabled per default e.g. firewalling recommends connection tracking support or NAT recommends all NAT helpers suggest X many people use A together with X, so you might be interested in enabling it, but I disabled it per default unless you said featuritis mode before. e.g. highmem and SMP or a network driver and NAPI. That is what the Debian/Ubuntu package management does and maybe other too. And this also gives us new keywords to replace select with, so migration is doable :-) This would also make EMBEDDED superflous, because it would just mean disable anything not required. And this would enable an individual tree for the users current configuration problem instead of a global one. I think package manager is the best possible way to think about this problem. I can't tell you how often I've wished the kernel config process behaved like apt and just prompted me with a list of things it would need to enable to allow me to use the option and ask me if I still want to do it. The reverse when I try and remove something important would be good too just ask me if I really want to remove all those as well. A functional equivelant of deborphan would be cool too. Just run it and have it tell me what is enabled that no devices depend on. The config system is nasty even for power users. There is a fun part of the netfilter code where I find myself having to enable all from one menu, go to the next menu down enable everything and then go back to the first menu. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 5 February 2007 15:09:15 -0800, Linus Torvalds wrote: Why? You could *trivially* have a tool tell you. Make xconfig or something just pop up a window saying sorry, you can't disable SCSI, because you've got ATA enabled, and ATA wants SCSI. That would be useful for both select and depend, as many have pointed out. And ignoring the fairly subjective be nice part, either select or depend can completely get removed once the tools have it. What I disagree with is the *trivially* part. For one, the problem is known for some time and has annoyed enough people, yet we don't have patches yet. Secondly, we'd need patches for most, if not all tools. Not having used xconfig for the last eight years, I doubt that you'd reach a majority of users with any of the plethora of make *config targets. We _need_ this support and I welcome anyone getting his/her hands dirty writing it up. Jörn -- Fantasy is more important than knowledge. Knowledge is limited, while fantasy embraces the whole world. -- Albert Einstein - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
I'm with Linus 100% here. It's really irritating to upgrade to a newer kernel, using the same old .config file, and then discover that my MythTV box no longer auto-boots to record programs. The reason being, that /proc/acpi/alarm no longer exists, and the kernel option to configure it has mysteriously disappeared from the menus. After an hour of hand examining and grep'ing Kconfig files, I eventually find the secret little totally-unrelated option that has to be selected to make the ACPI alarm option visible again. Doh! That interface is driven entirely backwards. The funtionality option should always be visible, and should select (or hey, invent a better mechanism, I'm not fussy), the underlying crap required to let me use it. Cheers - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, Feb 05, 2007 at 11:46:12PM -0600, Matt Mackall wrote: I'd be happy to turn this into CONFIG_NONSTANDARD or CONFIG_EXPERT, which is how I described it in the Kconfig help texts: menuconfig EMBEDDED bool Configure standard kernel features (for small systems) help This option allows certain base kernel options and settings to be disabled or tweaked. This is for specialized environments which can tolerate a non-standard kernel. Only use this if you really know what you are doing. A number of current users are indeed bogus. Stuff like: config SUPERH bool default y select EMBEDDED Just because you're using a SuperH board doesn't mean you want to turn off standard features. The only thing bogus is the CONFIG_EMBEDDED use itself, if it were only limited to turning options off, you'd be correct, but both PCI and IDE use it for other things. We specifically wanted it for IDE in this case. I'd be quite happy to see CONFIG_EMBEDDED separated entirely from the advanced/expert/screwing aunt tillie selection menu, or whatever we're choosing to call it these days. Then we wouldn't have to deal with these confusing defconfigs that expose far more than most users are going to care about. There are a number of other architectures that do this too, so it may be worth separating so we can finally get rid of the confusion. - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
Linus Torvalds wrote: On Mon, 5 Feb 2007, David Woodhouse wrote: Ten years ago, people used 'depends on' to fix the tools, so that then you want to enable something like USB_STORAGE, it can automatically turn SCSI on for you. Isn't that what you wanted? Try it. It's not what it does. If you have a depends on SCSI and you did not say you wanted SCSI, you'll never even *see* the question. It will *not* turn on SCSI automatically for you. Quite the reverse. It will not even show you the option. My favorite example of this is selinux, which you don't see unless you enable other unobvious things first. I say unobvious because until you do it the first few times you don't see the option, you ask menuconfig where it is, and it isn't there. So you go use your favorite tool to search the Kconfig until you find out why. Now that's in part a failure of the menuconfig tool I use, which may not be in xconfig (I'll try that later today when I build a new kernel), but it seem odd that a major feature would not show unless something obscure were selected, and that the crypto features needed for selinux would be good candidates for SELECT. Just because config is something mostly done by advanced user doesn't mean it should be difficult or time-consuming. And why say should have done for the SCSI mess, it's correctable, if everyone agrees that you are right (who would dare disagree ;-) then it can be fixed. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
David Woodhouse wrote: On Mon, 2007-02-05 at 15:32 -0800, Linus Torvalds wrote: On Mon, 5 Feb 2007, David Woodhouse wrote: The netfilter example is totally irrelevant here, since 'select' is neither necessary nor sufficient for that. Russell and I have both pointed that out to you already. No, the example IS relevant. Why? Because you don't seem to be getting the whole be nice part. If you'd come down from your high horse for a moment you might realise that I _agree_ with the 'be nice' part, as long as you don't pessimise things for those who _do_ know what they're doing. The thing you want for netfilter is a _GOOD IDEA_. I agree. I've even implemented something _very_ similar, for JFFS2 compression options. If you want to play about with individual compressors you have to enable the 'Advanced options' first; otherwise you get the sane defaults. Unless you really want to get your hands dirty, you don't have to know which compressors we use by default. One thing which can be solved at the tool level, particularly for netfilter, is to provide options for turn it all of and I'll select, turn it all on (or module), and reset this page to defaults. Because those starting points will cover a majority of the options. Useful for device drivers as well, particularly network cards and disk controllers, where there are a vast number of choices. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
Mark Rustad wrote: On Feb 5, 2007, at 5:32 PM, Linus Torvalds wrote: snip And I told you that you could just improve the tools that track those dependencies ANYWAY! They aren't that bad even now. Using menuconfig (I'm a fossil that just uses curses for most things), hitting ? shows what depends or selects any particular entry. That is good enough for me now. Maybe I am just willing to ask for help, but the help already seems to be there. I think the problem Linus referenced with not even seeing an option is an issue, you can't ? on an option you can't see. An I use menuconfig also, from long habit (accessing a remote compile server with slow dialup). -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
Matt Mackall wrote: On Mon, Feb 05, 2007 at 08:09:58PM -0500, Theodore Tso wrote: On Mon, Feb 05, 2007 at 11:21:34PM +, David Woodhouse wrote: But Alan makes a reasonable suggestion -- we could work around this in the tools too. I wouldn't call it work around this in the tools. It's a useful feature we can add in the tools for developers who aren't men enough to use sed/grep pipelines. :-) But I have to agree with Linus here that we should be optimizing the tools for people who know how to compile the kernel, but who aren't necessarily familiar with all of the hidden dependencies in the literally hundreds of config options in the kernel tree. In reality, you want to make it easy to turn on *or* off any arbitrary config option, and to understand what you need to do so you can turn an arbitrary config option on or off. If that means tools enhancements, so be it. With apt (or presumably with yum), you can happily apt-remove a package that nothing else depends on. If you remove something that other things depend on, you get a list of those things and opportunity to force it (with a -f flag, for instance). If you ask for a package that has other dependencies, it automatically pulls all those things in unless there's a conflict. In which case you can force it again. There's no reason we shouldn't be able to do exactly that with config symbols in Kconfig-land. The only difference is that we've got slightly different semantics for our depend keyword. Things which don't have their depend requirements met aren't offered as options. Whereas select is automatically pull in dependencies apt/yum-style. Perhaps this is because there is a lacking keyword. The depends controls visibility, perhaps a requires could be used to provide advisory information which mean these other things will be turned on if you build this feature. While we're at it, it would also be nice to be able to do: $ kconfig enable ACPI CONFIG_ACPI conflicts with CONFIG_APM $ kconfig enable -F ACPI disabling CONFIG_APM $ kconfig disable SCSI CONFIG_USB_STORAGE depends on CONFIG_SCSI $ kconfig disable -f SCSI disabling USB_STORAGE $ make I think depends and select provide this now, the postulated requires might make building the trees easier. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Feb 6, 2007, at 9:55 AM, Bill Davidsen wrote: Mark Rustad wrote: On Feb 5, 2007, at 5:32 PM, Linus Torvalds wrote: snip And I told you that you could just improve the tools that track those dependencies ANYWAY! They aren't that bad even now. Using menuconfig (I'm a fossil that just uses curses for most things), hitting ? shows what depends or selects any particular entry. That is good enough for me now. Maybe I am just willing to ask for help, but the help already seems to be there. I think the problem Linus referenced with not even seeing an option is an issue, you can't ? on an option you can't see. An I use menuconfig also, from long habit (accessing a remote compile server with slow dialup). Yes, of course. My point was that if you are the embedded guy (like I often am) trying to turn something off, the tools show you what to look at already. They are currently no help if the option does not appear, as you say. So automatically selecting things that are required for something is much better than hiding too much. At least it is easy to find out why something is selected if you really want to turn it off. If more things worked as Linus suggests, I don't think the tools need much in the way of improvement. It really is more about how they are used as they are. That is not to say that tools improvements are not always welcome, but the current tools seem to work pretty well. -- Mark Rustad, [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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 Feb 2007, David Woodhouse wrote: It's a bad example because it's not relevant to the 'select' question, and you're trying to use it as a straw man; assigning to me a belief I just don't have. It *is* relevant. Why are you ignoring the ATA example? Which is exactly the same thing? (And where we do the right thing - we just select SCSI) Why are you ignoring the USB example - which is exactly the same thing (and where we do the *wrong* thing: we depend on SCSI and then we have about 5 lines of warning both around USB and around SCSI and documentation just to say that USB needs it!) Perhaps I haven't spoken carefully enough. I mean to argue that being nice is good -- but that we shouldn't do so in a way which _costs_ those who use the system most. It costs you nothing but arguing. No, you really aren't paying attention. You CAN DO IT WITHOUT SELECT. No, I was paying attention. You seem to just be obtuse on purpose. WE WANT TO BE NICE. - the firewall example was not an example of 'select', but of the we want to be nice. But you simply DID NOT GET IT. - the USB and SATA examples are *also* examples of we want to be nice, and hell yeah, you need 'select' to do them. Claiming anything else is just stupid. So: are you stupid, or do you just refuse to even think about it? My point is not that we shouldn't be helpful. My point is that 'select' is the _wrong_ way to be 'helpful', because that's a PITA for other people. It's a PITA just because you don't listen, and ignore everything I say. In other words, the problem is *you*. The problem is NOT select. People have even pointed out that you don't even have to create new tools. Use menuconfig and ?, which apparently already tells you what the dependencies are, and why you can't turn something off.. And yes, I just tried. I couldn't turn SCSI off in menuconfig, so I pressed '?', and at the end it does actually say: Selected by: ATA BLOCK (!M32R !M68K || BROKEN) (!SUN4 || BROKEN) Not hugely readable, and I'm sure it could be improved a lot. And yes, I certainly think that it would be a good idea if there would be other tools that told you too. The Kconfig engine *internally* already knows all this, of course, so all the hard work has already effectively been done, it's just not *shown*. So you should just face it: the problem *really* isn't 'select'. Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, Feb 06, 2007 at 11:04:31AM -0500, Bill Davidsen wrote: There's no reason we shouldn't be able to do exactly that with config symbols in Kconfig-land. The only difference is that we've got slightly different semantics for our depend keyword. Things which don't have their depend requirements met aren't offered as options. Whereas select is automatically pull in dependencies apt/yum-style. Perhaps this is because there is a lacking keyword. The depends controls visibility, perhaps a requires could be used to provide advisory information which mean these other things will be turned on if you build this feature. require is a bad name as it's a synonym of depend. While we're at it, it would also be nice to be able to do: $ kconfig enable ACPI CONFIG_ACPI conflicts with CONFIG_APM $ kconfig enable -F ACPI disabling CONFIG_APM $ kconfig disable SCSI CONFIG_USB_STORAGE depends on CONFIG_SCSI $ kconfig disable -f SCSI disabling USB_STORAGE $ make I think depends and select provide this now, the postulated requires might make building the trees easier. The above is all about having a scriptable command line interface so that people don't need the broken sed + make oldconfig thing. -- Mathematics is the supreme nostalgia of our time. - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
Matt Mackall wrote: On Tue, Feb 06, 2007 at 11:04:31AM -0500, Bill Davidsen wrote: There's no reason we shouldn't be able to do exactly that with config symbols in Kconfig-land. The only difference is that we've got slightly different semantics for our depend keyword. Things which don't have their depend requirements met aren't offered as options. Whereas select is automatically pull in dependencies apt/yum-style. Perhaps this is because there is a lacking keyword. The depends controls visibility, perhaps a requires could be used to provide advisory information which mean these other things will be turned on if you build this feature. require is a bad name as it's a synonym of depend. While we're at it, it would also be nice to be able to do: $ kconfig enable ACPI CONFIG_ACPI conflicts with CONFIG_APM $ kconfig enable -F ACPI disabling CONFIG_APM $ kconfig disable SCSI CONFIG_USB_STORAGE depends on CONFIG_SCSI $ kconfig disable -f SCSI disabling USB_STORAGE $ make I think depends and select provide this now, the postulated requires might make building the trees easier. The above is all about having a scriptable command line interface so that people don't need the broken sed + make oldconfig thing. I didn't say that clearly, I meant that the information to do this was present, not the functionality. Someone suggested that 'requires' was a synonym of 'depends on' and was a bad choice. I think the requirement is in fasct the same, what I was after was not to prevent visibility of the option as 'depends' does. And we still probably need depends to avoid way too many choices. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 2007-02-06 at 08:53 -0800, Linus Torvalds wrote: WE WANT TO BE NICE. - the firewall example was not an example of 'select', but of the we want to be nice. But you simply DID NOT GET IT. It's a very clever straw man, Linus, but it's still bogus. Not only do I _agree_ about the firewall example, I've even implemented very similar things already, of my own accord. I really do get it. I don't claim that we shouldn't be nice. You keep coming back to that but it bears no relation to what I'm actually saying. - the USB and SATA examples are *also* examples of we want to be nice, and hell yeah, you need 'select' to do them. Claiming anything else is just stupid. So: are you stupid, or do you just refuse to even think about it? I claim that there are _better_ ways to do it than 'select'. I claim that we can 'be nice' without actually screwing over the people who use non-interactive config methods and need to turn stuff off. A number of whom have spoken up already but are perhaps less quixotic than I am so have given up on getting you to listen. 99% of the times I configure a kernel, it's in an RPM package. The answer you can use xconfig and press the question mark isn't wonderfully useful -- although having xconfig be the answer for those who need the extra guidance that 'select' currently offers is perhaps a more reasonable solution. But it doesn't matter. I'll come up with a hack for the tools which make them (optionally) treat 'select' of a user-visible option as if it was just 'depends on'. And that should fix the problem. -- 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On 2/6/07, Matt Mackall [EMAIL PROTECTED] wrote: A number of current users are indeed bogus. Stuff like: config SUPERH bool default y select EMBEDDED Just because you're using a SuperH board doesn't mean you want to turn off standard features. I disagree. I did the exact same thing on AVR32 because !EMBEDDED forces on tons of crap that just isn't useful on many embedded platforms. I trust our users to actually enable for example virtual terminal support if they happen to need it. Far from everyone do, and it's going to end up as dead code unless they also enable the right framebuffer driver. Haavard - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 06 Feb 2007 22:38:04 + David Woodhouse wrote: On Tue, 2007-02-06 at 08:53 -0800, Linus Torvalds wrote: WE WANT TO BE NICE. - the firewall example was not an example of 'select', but of the we want to be nice. But you simply DID NOT GET IT. It's a very clever straw man, Linus, but it's still bogus. Not only do I _agree_ about the firewall example, I've even implemented very similar things already, of my own accord. I really do get it. I don't claim that we shouldn't be nice. You keep coming back to that but it bears no relation to what I'm actually saying. - the USB and SATA examples are *also* examples of we want to be nice, and hell yeah, you need 'select' to do them. Claiming anything else is just stupid. So: are you stupid, or do you just refuse to even think about it? I claim that there are _better_ ways to do it than 'select'. I claim that we can 'be nice' without actually screwing over the people who use non-interactive config methods and need to turn stuff off. A number of whom have spoken up already but are perhaps less quixotic than I am so have given up on getting you to listen. Even with the interactive tools it's difficult to turn symbols off if they are selected in multiple places. But that's the old tools issue. But Andrew has done a great job of trying to minimize 'select' in Kconfig files. 99% of the times I configure a kernel, it's in an RPM package. The answer you can use xconfig and press the question mark isn't wonderfully useful -- although having xconfig be the answer for those who need the extra guidance that 'select' currently offers is perhaps a more reasonable solution. But it doesn't matter. I'll come up with a hack for the tools which make them (optionally) treat 'select' of a user-visible option as if it was just 'depends on'. And that should fix the problem. Yes, that's the solution that I decided on during lunch also: select == depends on --- ~Randy - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 Feb 2007, Haavard Skinnemoen wrote: I disagree. I did the exact same thing on AVR32 because !EMBEDDED forces on tons of crap that just isn't useful on many embedded platforms. I do agree. EMBEDDED largely means non-generic/non-standard these days. It's also true that EMBEDDED does *not* necessarily mean small, since some of the choices that it disables can often be choices that you want on *big* machines. For example, the whole thing where VGA and keyboard/mouse support default to on when EMBEDDED isn't selected is quite possibly a good reason to enable EMBEDDED on big servers that aren't even meant to be general- purpose, but simply optimized for a particular environment. That is, technically, what embedded really means. A lot of the time people talk about it as if it was always small, but it can be a big computer that is just used in a very specific turn-key environment where some of the default kernel choices may not be sensible. Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 Feb 2007, David Woodhouse wrote: I claim that there are _better_ ways to do it than 'select'. I don't think you've ever showed any such example. And if you did, it would all boil down to *exactly* what 'select' does: config options that get set automatically based on other choices. So care to give a real example? Start with USB automatically selecting SCSI support without the user having to even know it uses SCSI. Tell me how it's supposed to work sanely without 'select'. Put up, or shut up. Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 Feb 2007, Randy Dunlap wrote: Yes, that's the solution that I decided on during lunch also: select == depends on I think yuou can certainly enable an expert mode, which just reads select as depends on. You'll probably have to do *more* changes to the tools than my suggestion to just make them let you know why they can't turn something off, though. Why? Some things don't even have questions at all right now, and their only life is as implied options that are turned on by others. And yes, some silly people who hate select have tried to turn them into bool SUBSYSTEM default y depends on X || Y || Z || XY || XZ || YZ or similar, which is a hell of a lot less maintainable than just letting X, Y, Z etc do 'select SUBSYSTEM'. But select SUBSYSTEM still does exist, notably in places like SND_PCM (where it would just be INSANE to list all the different sound drivers that want it as a shitload of depends on) but also for things like NET_CLS and CRYPTO etc. Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 2007-02-06 at 14:53 -0800, Linus Torvalds wrote: I don't think you've ever showed any such example. And if you did, it would all boil down to *exactly* what 'select' does: config options that get set automatically based on other choices. That's one option which I don't think I've seen implemented. The other possibility which comes to mind, and which I _have_ seen implemented, is not to hide the disabled option but to _show_ it, and represent its dependencies right there next to it somehow. Where I saw this done was actually in the Nemesis kernel configuration, which was based on our old tcl xconfig tool. It actually worked quite well. It's a _long_ time ago now, but IIRC it was in a cell below the disabled option. It'd look something like (remember hte old xconfig?): | USB Mass storage support | o Y o M ✓ N| | depends on: o SCSI ✓ USB | I'm sure I had a screenshot of it once. But it doesn't matter; you get the idea -- our current tools would do it differently anyway. But they _could_ do it. So care to give a real example? Start with USB automatically selecting SCSI support without the user having to even know it uses SCSI. Tell me how it's supposed to work sanely without 'select'. Well one option, as you suggest, is just that if you go into the graphical tool and enable USB_STORAGE, you get SCSI turned on automatically. That's simple enough and the xconfig tool can do it quite easily. It just needs to _show_ you the option, which isn't particularly hard. But what I care about is that when you when you explicitly set # CONFIG_SCSI is not set and run 'make oldconfig' it doesn't get turned back on again. But as I said, I'm not entirely averse to having to do 'make oldconfig-noselect' or something like that to preserve the old behaviour. And then you can sprinkle 'select' wherever you like without bothering those of us who object. -- 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 Feb 2007, Linus Torvalds wrote: On Tue, 6 Feb 2007, Randy Dunlap wrote: Yes, that's the solution that I decided on during lunch also: select == depends on I think yuou can certainly enable an expert mode, which just reads select as depends on. Actually, it's probably more useful if you do it for a single symbol only. If you really want to force something off, mark that *single* symbol as having select that-symbol being translated into depends on, and it will probably work fine in practice. Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 2007-02-06 at 15:11 -0800, Linus Torvalds wrote: On Tue, 6 Feb 2007, Randy Dunlap wrote: But it doesn't matter. I'll come up with a hack for the tools which make them (optionally) treat 'select' of a user-visible option as if it was just 'depends on'. And that should fix the problem. Yes, that's the solution that I decided on during lunch also: select == depends on I think yuou can certainly enable an expert mode, which just reads select as depends on. You'll probably have to do *more* changes to the tools than my suggestion to just make them let you know why they can't turn something off, though. Why? Some things don't even have questions at all right now, and their only life is as implied options that are turned on by others. And yes, some silly people who hate select have tried to turn them into Out of interest, which people would this be? Not me, certainly. I _use_ select, for options which don't have questions. There were two such instances in the context of Ingo's mail of $subject, even. And the thing Randy was saying yes to, which you elided but I've restored in the above quotation, was the idea of turning 'select' into 'depends on' for _user-visible_ options. NOT for the ones which don't have a 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 Feb 2007, David Woodhouse wrote: The other possibility which comes to mind, and which I _have_ seen implemented, is not to hide the disabled option but to _show_ it, and represent its dependencies right there next to it somehow. That would probably work, especially if you had some way to warp to the other options (so that if you see depends on SCSI you could say ok, go to SCSI then. However, I have this suspicion that you'd just drown in options that you really don't want to see. Well one option, as you suggest, is just that if you go into the graphical tool and enable USB_STORAGE, you get SCSI turned on automatically. Yes. That basically is what select means, though. The difference is, indeed, largely about visibility. If everything was always visible, there really wouldn't be much of a difference between depends on and select. In both cases, when you click on something that depends on or selects something else, the config tool would obviously select it. So yes, you can make depends on and select mean _exactly_ the same thing. But basically only by always showing everything. Which I don't think you want. If I say I don't want IPv6, I really am not interested in seeing some IPv6-only questions. But on the other hand, maybe there is something that _needs_ IPv6 to work, and then maybe I'd like it enabled.. (Example: I don't want to see IPV6 questions if IPV6 is off, BUT I might still want to be able to see the question about NFSv8.1, which only works on top of IPV6. I might not even *know* I want IPV6, but I know my company uses NFSv8.1, so I say yes). And I realize that was a contrieved example, but there are *real* examples of this in the kernel today. I may well know that I want 802.11 WEP encryption, for example, but I sure as hell had *no* clue that it requires ARC4. See the problem? I may be a well-educated user who doesn't even *know* that I actually want an encrytion algorithm that I've never heard of. For all I knew, the 802.11 WEP stuff was done inside the wireless cards by hardware.. Does that mean that if I don't have CRYPTO_ARC4 enabled (which in turn would need CRYPTO_ALGAPI enabled too) I'd not even get the choice of WEP? Obviously that is broken. And yes, if you *always* get the choice of *everyting*, then it all boils down to the same thing. I just don't think you do.. Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 2007-02-06 at 15:28 -0800, Linus Torvalds wrote: (Example: I don't want to see IPV6 questions if IPV6 is off, BUT I might still want to be able to see the question about NFSv8.1, which only works on top of IPV6. I might not even *know* I want IPV6, but I know my company uses NFSv8.1, so I say yes). (Quoting very sparsely but I think honestly -- I think the above is the essence of what you were saying). Actually it doesn't have to be that much of a problem if the config stuff is laid out sensibly, as Ingo mentioned earlier. Those IPv6 options you don't want to see are likely to be all in an 'IPv6' submenu of the networking stuff which nobody forces you to visit. Yet 'NFSv8.1' (*shudder*) would be elsewhere under networked file systems, or some suboption of NFS, and you'd see it just fine. And I realize that was a contrieved example, but there are *real* examples of this in the kernel today. I may well know that I want 802.11 WEP encryption, for example, but I sure as hell had *no* clue that it requires ARC4. Again, if you don't care about crypto then you're unlikely to be delving in the crypto menus. Nobody forces you to go there. But when you look at the greyed-out WEP option and you click on it and it tells you You need ARC4 for this. Do you want me to turn it on for you? (or whatever), you get what you wanted. Really, if our config is set up in sensible submenus (as in general it _is_), the see everything behaviour really isn't bad. -- 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 06 Feb 2007 23:36:23 + David Woodhouse wrote: On Tue, 2007-02-06 at 15:28 -0800, Linus Torvalds wrote: (Example: I don't want to see IPV6 questions if IPV6 is off, BUT I might still want to be able to see the question about NFSv8.1, which only works on top of IPV6. I might not even *know* I want IPV6, but I know my company uses NFSv8.1, so I say yes). (Quoting very sparsely but I think honestly -- I think the above is the essence of what you were saying). Actually it doesn't have to be that much of a problem if the config stuff is laid out sensibly, as Ingo mentioned earlier. Those IPv6 options you don't want to see are likely to be all in an 'IPv6' submenu of the networking stuff which nobody forces you to visit. Yet 'NFSv8.1' (*shudder*) would be elsewhere under networked file systems, or some suboption of NFS, and you'd see it just fine. And I realize that was a contrieved example, but there are *real* examples of this in the kernel today. I may well know that I want 802.11 WEP encryption, for example, but I sure as hell had *no* clue that it requires ARC4. Again, if you don't care about crypto then you're unlikely to be delving in the crypto menus. Nobody forces you to go there. But when you look at the greyed-out WEP option and you click on it and it tells you You need ARC4 for this. Do you want me to turn it on for you? (or whatever), you get what you wanted. Really, if our config is set up in sensible submenus (as in general it _is_), the see everything behaviour really isn't bad. Well, there's layout and then there's the tool(s). Besides this select business, Bill (or someone :) mentioned a feature that I requested about 8 months ago: the ability to disable or enable groups of drivers at one swoop. And Matt has made some good scripting suggestions. For layout, we may not all agree on that part either. :) It's quite subjective. E.g., I made/submitted a patch maybe 1 year ago that tried to put all video graphics (frame buffer, AGP, DRM/DRI, etc.) into one localized place in the menu structure. OK, perhaps I wasn't persistent enough, but no one was interested in it. (That probably just means that config menus are low priority.) --- ~Randy - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 2007-02-06 at 15:41 -0800, Randy Dunlap wrote: It's quite subjective. E.g., I made/submitted a patch maybe 1 year ago that tried to put all video graphics (frame buffer, AGP, DRM/DRI, etc.) into one localized place in the menu structure. OK, perhaps I wasn't persistent enough, but no one was interested in it. (That probably just means that config menus are low priority.) Compared with making the bloody _code_ actually cooperate, in that particular respect, I think the config options are indeed a fairly low priority :) -- 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 Feb 2007, David Woodhouse wrote: Out of interest, which people would this be? Not me, certainly. I _use_ select, for options which don't have questions. There were two such instances in the context of Ingo's mail of $subject, even. And the thing Randy was saying yes to, which you elided but I've restored in the above quotation, was the idea of turning 'select' into 'depends on' for _user-visible_ options. NOT for the ones which don't have a question. Example: crypto api. SCSI. firewall expert mode. Any number of things. Qutie often, the questions themselves are *conditional*. For example, look at the whole INPUT layer thing. It is a real question, but only for EMBEDDED - normally, we just assume we'll use it (but it's a classic example of where we could have used a select from the keyboard driver instead). For normal people, it's a question that simply shouldn't be asked. You don't ask normal users whether they want to hook up keyboards and mice (and trust me when I say that: we _used_ to ask. It generated tons of totally idiotic noise). Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 Feb 2007, Randy Dunlap wrote: Besides this select business, Bill (or someone :) mentioned a feature that I requested about 8 months ago: the ability to disable or enable groups of drivers at one swoop. i vaguely recall that *i* was pushing that idea, and even submitted a couple patches to start the process, but it never really went anywhere. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 6 Feb 2007, David Woodhouse wrote: Really, if our config is set up in sensible submenus (as in general it _is_), the see everything behaviour really isn't bad. There are two fundamental problems with that statement: - no, it really isn't always Quite often, our Kconfig files have dependencies that are about where the *code* exists, rather than about some nice hierarchical system. Think of it this way: would you use a programming language that didn't allow you anything but totally hierarcical language constructs? No sane person would - because real life isn't hierarchical. Yes, there are many things that are, but not all things are. Example: many cryptographic algorithms are in crypto/. But then a lot of them ARE NOT. They are in arch/so-and-so/crypto/ or similar. Notice? NOT HIERARCHICAL. - I don't use menus at all. I use the good old textual make oldconfig. Trust me, I _want_ those irrelevant questions gone. They aren't grayed out. So you seem to have this *wish* that real life was different than it is. But we aren't hierarchical, and even if we were, it *still* wouldn't work the way you want things to work. Linus reality bites Torvalds - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 2007-02-06 at 15:55 -0800, Linus Torvalds wrote: On Tue, 6 Feb 2007, David Woodhouse wrote: Really, if our config is set up in sensible submenus (as in general it _is_), the see everything behaviour really isn't bad. There are two fundamental problems with that statement: - no, it really isn't always Quite often, our Kconfig files have dependencies that are about where the *code* exists, rather than about some nice hierarchical system. Think of it this way: would you use a programming language that didn't allow you anything but totally hierarcical language constructs? No sane person would - because real life isn't hierarchical. Yes, there are many things that are, but not all things are. Example: many cryptographic algorithms are in crypto/. But then a lot of them ARE NOT. They are in arch/so-and-so/crypto/ or similar. Notice? NOT HIERARCHICAL. It isn't that far off, and we could improve it if we wanted to. In _general_ it's quite good already. - I don't use menus at all. I use the good old textual make oldconfig. Trust me, I _want_ those irrelevant questions gone. They aren't grayed out. So you seem to have this *wish* that real life was different than it is. But we aren't hierarchical, and even if we were, it *still* wouldn't work the way you want things to work. It would work quite nicely in the graphical tools, although you've thrown me a little by wanting it in the hacker's tool 'oldconfig' too. You obviously care more about turning stuff _on_ with 'make oldconfig' while other people who've spoken up seem to care more, as I do, about turning stuff _off_ that way. If I want my hand held, I'm happy enough to use the graphical tools. I think the answer is probably just to go ahead and implement the 'make oldconfig_noselect' so we can all have what we want. -- 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Wed, 7 Feb 2007, David Woodhouse wrote: It isn't that far off, and we could improve it if we wanted to. In _general_ it's quite good already. I agree that it's close to hierarchical. But it's literally the exceptions that get you. Let me mention (again) USB_STORAGE and ATA. They are not under SCSI. Making them do that would be insane. But yes, you can do hierarchies by adding pseudo-variables: as mentioned several times, we could actually split CONFIG_SCSI into two separate ones: CONFIG_SCSI that selects the core infrastructure, and CONFIG_SCSI_DRIVER that actually controls the hierarchical visibility. Then CONFIG_SCSI_DRIVER (and USB_STORAGE, and SATA) would just do a simple 'select SCSI'. It would _not_ be hierarchical, and it would very much use that same old select, but it would possibly be a cleanup at least in the sense that now CONFIG_SCSI wouldn't be used two different ways (one to hide most SCSI drivers, and one to enable the core SCSI infrastructure code). It would work quite nicely in the graphical tools, although you've thrown me a little by wanting it in the hacker's tool 'oldconfig' too. You obviously care more about turning stuff _on_ with 'make oldconfig' while other people who've spoken up seem to care more, as I do, about turning stuff _off_ that way. If I want my hand held, I'm happy enough to use the graphical tools. I tend to just edit the .config file, and run make oldconfig. And I know I'm not the only one, because I've talked to others who do the same. And yes, then it's almost always correct to turn things on as needed to make everything work out right, while turning things off would be actively wrong. Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
Linus Torvalds wrote: On Wed, 7 Feb 2007, David Woodhouse wrote: It isn't that far off, and we could improve it if we wanted to. In _general_ it's quite good already. I agree that it's close to hierarchical. But it's literally the exceptions that get you. Let me mention (again) USB_STORAGE and ATA. They are not under SCSI. Making them do that would be insane. But yes, you can do hierarchies by adding pseudo-variables: as mentioned several times, we could actually split CONFIG_SCSI into two separate ones: CONFIG_SCSI that selects the core infrastructure, and CONFIG_SCSI_DRIVER that actually controls the hierarchical visibility. Then CONFIG_SCSI_DRIVER (and USB_STORAGE, and SATA) would just do a simple 'select SCSI'. It would _not_ be hierarchical, and it would very much use that same old select, but it would possibly be a cleanup at least in the sense that now CONFIG_SCSI wouldn't be used two different ways (one to hide most SCSI drivers, and one to enable the core SCSI infrastructure code). It would work quite nicely in the graphical tools, although you've thrown me a little by wanting it in the hacker's tool 'oldconfig' too. You obviously care more about turning stuff _on_ with 'make oldconfig' while other people who've spoken up seem to care more, as I do, about turning stuff _off_ that way. If I want my hand held, I'm happy enough to use the graphical tools. I tend to just edit the .config file, and run make oldconfig. And I know I'm not the only one, because I've talked to others who do the same. And yes, then it's almost always correct to turn things on as needed to make everything work out right, while turning things off would be actively wrong. That seems odd to me. I usually use edit + oldconfig to disable a symbol. Maybe to enable a symbol occasionally. But the symbols that I want to enable usually aren't listed in .config at all, so I end up using another config tool to enable them. E.g., a sound driver when SOUND is completely disabled. -- ~Randy - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Tue, 2007-02-06 at 16:21 -0800, Linus Torvalds wrote: On Wed, 7 Feb 2007, David Woodhouse wrote: It isn't that far off, and we could improve it if we wanted to. In _general_ it's quite good already. I agree that it's close to hierarchical. But it's literally the exceptions that get you. Let me mention (again) USB_STORAGE and ATA. They are not under SCSI. Making them do that would be insane. But in the graphical tool that's _good_. Because those are the options you _wanted_ to see. You don't want to go digging around under the SCSI menu where all those boring hostadapters are, but you _do_ get to see the USB and ATA stuff elsewhere. But that's only for the graphical tool, which is where I actually expected the handholding to be required. If you want it in 'oldconfig' then I think that's weird, but I don't have a better solution than 'select', unfortunately. It would work quite nicely in the graphical tools, although you've thrown me a little by wanting it in the hacker's tool 'oldconfig' too. You obviously care more about turning stuff _on_ with 'make oldconfig' while other people who've spoken up seem to care more, as I do, about turning stuff _off_ that way. If I want my hand held, I'm happy enough to use the graphical tools. I tend to just edit the .config file, and run make oldconfig. And I know I'm not the only one, because I've talked to others who do the same. That's exactly what I do too. And yes, then it's almost always correct to turn things on as needed to make everything work out right, while turning things off would be actively wrong. My experience is exactly the opposite; perhaps because I spend so much of my time working on the Fedora kernel where almost everything starts off enabled by default, and I only ever want to turn stuff off. I think 'make oldconfig_noselect' is the way forward. We can both have what we want. -- 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Wed, 7 Feb 2007, David Woodhouse wrote: I think 'make oldconfig_noselect' is the way forward. We can both have what we want. Actually, I think there might be an even more interesting schenario. The Kconfig language right not is ternary, which is fine as an arithmetic, but the problem *may* be that we actually want it to be more expressive. If instead of a ternary y/m/n calculus, we would use a Y/y/m/n/N quinary logic, where Y and N are like force on/off, you might have the following: y + depends on = n Y + depends on = Y, and the depends on to Y too n/N + depends on = n y/Y + selected = y n + select = y N + select = N, and the select to N In other words, Y means force to Y, even if it has a dependency (which we'll also have to force, while N means force to N, even if it is getting selected, in which case the selection will also be forced to N). So then you can say things like - edit .config, and set *any* value to Y, and it will force-enable anything that that depends on when you run make oldconfig, even if it was an depends on - edit .config, and set *any* value to N, and it fill force-disable anything that selects that when you you run make oldconfig The problem here is that: - you can get inconsistent situations (but he wanted to both force that on *and* off!) - select actually is much nicer, in that it unambiguously selects one other symbol. But depends on is very hard to force, because you may have something like (totally made up) depends on X86 || (ALPHA PCI) which is impossible to force (*which* one do you force?) on. but something like this would be nice for both the text-based make oldconfig kind of thing *and* for any graphical configuration things (dammit, I want this OFF, when I press the force-off-buffon you turn anything off that needs it!) But the two problems above might make it impractical.. Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, Feb 05, 2007 at 08:09:58PM -0500, Theodore Tso wrote: > On Mon, Feb 05, 2007 at 11:21:34PM +, David Woodhouse wrote: > > But Alan makes a reasonable suggestion -- we could work around this in > > the tools too. > > I wouldn't call it "work around this" in the tools. It's a useful > feature we can add in the tools for developers who aren't men enough > to use "sed/grep" pipelines. :-) > > But I have to agree with Linus here that we should be optimizing the > tools for people who know how to compile the kernel, but who aren't > necessarily familiar with all of the hidden dependencies in the > literally hundreds of config options in the kernel tree. In reality, > you want to make it easy to turn on *or* off any arbitrary config > option, and to understand what you need to do so you can turn an > arbitrary config option on or off. If that means tools enhancements, > so be it. With apt (or presumably with yum), you can happily apt-remove a package that nothing else depends on. If you remove something that other things depend on, you get a list of those things and opportunity to force it (with a -f flag, for instance). If you ask for a package that has other dependencies, it automatically pulls all those things in unless there's a conflict. In which case you can force it again. There's no reason we shouldn't be able to do exactly that with config symbols in Kconfig-land. The only difference is that we've got slightly different semantics for our "depend" keyword. Things which don't have their "depend" requirements met aren't offered as options. Whereas "select" is "automatically pull in dependencies" apt/yum-style. While we're at it, it would also be nice to be able to do: $ kconfig enable ACPI CONFIG_ACPI conflicts with CONFIG_APM $ kconfig enable -F ACPI disabling CONFIG_APM $ kconfig disable SCSI CONFIG_USB_STORAGE depends on CONFIG_SCSI $ kconfig disable -f SCSI disabling USB_STORAGE $ make -- Mathematics is the supreme nostalgia of our time. - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, Feb 05, 2007 at 09:17:52PM +, David Woodhouse wrote: > On Mon, 2007-02-05 at 08:58 -0800, Linus Torvalds wrote: > > More importantly, some things that *are* visible probably shouldn't be, or > > should perhaps only be in expert mode (aka "EMBEDDED"). > > I've heard some fairly stupid abuse of the term 'embedded' in my time, > but rarely have I heard people daft enough to abuse it to mean 'expert'. > But yes, that's what we use CONFIG_EMBEDDED for. I'd be happy to turn this into CONFIG_NONSTANDARD or CONFIG_EXPERT, which is how I described it in the Kconfig help texts: menuconfig EMBEDDED bool "Configure standard kernel features (for small systems)" help This option allows certain base kernel options and settings to be disabled or tweaked. This is for specialized environments which can tolerate a "non-standard" kernel. Only use this if you really know what you are doing. A number of current users are indeed bogus. Stuff like: config SUPERH bool default y select EMBEDDED Just because you're using a SuperH board doesn't mean you want to turn off standard features. -- Mathematics is the supreme nostalgia of our time. - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, Feb 05, 2007 at 11:21:34PM +, David Woodhouse wrote: > But Alan makes a reasonable suggestion -- we could work around this in > the tools too. I wouldn't call it "work around this" in the tools. It's a useful feature we can add in the tools for developers who aren't men enough to use "sed/grep" pipelines. :-) But I have to agree with Linus here that we should be optimizing the tools for people who know how to compile the kernel, but who aren't necessarily familiar with all of the hidden dependencies in the literally hundreds of config options in the kernel tree. In reality, you want to make it easy to turn on *or* off any arbitrary config option, and to understand what you need to do so you can turn an arbitrary config option on or off. If that means tools enhancements, so be it. - Ted - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Feb 5, 2007, at 5:32 PM, Linus Torvalds wrote: And I told you that you could just improve the tools that track those dependencies ANYWAY! They aren't that bad even now. Using menuconfig (I'm a fossil that just uses curses for most things), hitting ? shows what depends or selects any particular entry. That is good enough for me now. Maybe I am just willing to ask for help, but the help already seems to be there. -- Mark Rustad, [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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
Linus Torvalds wrote: I also feel that a lot of people are "advanced" in one area, but not necessarily in another. The Netfilter example I gave was one such personal gripe of mine. I just feel like I shouldn't need to care! Yeah, I have the knowledge, but I *still* want to be baby-fed with just a simple "anybody can understand it". It's a good example. I had a bear of a time with the netfilter kernel config on my firewall (w/ IPv6 goodness) box, when the generic netfilter stuff landed. For the first time in a long time, that firewall booted into a configuration that wouldn't forward+masq packets properly. The same is true of the whole SATA/USB/SCSI thing. I know damn well that the kernel uses the SCSI layer for USB and SATA, yet I feel that the ATA layer does it right, and I just find the USB storage situation to be *offensively* bad in this regard. Why the HELL does it have those big comments and warnings, when it could just damn well enable SCSI support itself? I think maybe ATA is just lucky. I allowed myself to get bullied into avoiding 'select', even though I feel the same way as you. ATA should select scsi-disk but doesn't, for example. And at some point it becomes a matter of taste: should ATA select BLOCK, or depend on BLOCK? There are IMO good arguments either way. Jeff - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 5 Feb 2007, David Woodhouse wrote: > > The netfilter example is totally irrelevant here, since 'select' is > neither necessary nor sufficient for that. Russell and I have both > pointed that out to you already. No, the example IS relevant. Why? Because you don't seem to be getting the whole "be nice" part. You continually argue as if being nice isn't an issue, and shouldn't be even an option. And maybe you can do it without select for netfilter, but you sure as HELL cannot do it for things like SCSI and the USB/ATA question. So you keep on ignoring the real argument, by belittling it. You talk about "Aunt Tillie". Don't talk about Aunt Tillie. Dammit! Talk about ME! And talk about the kinds of people we *want* to compile the kernel: people who may be entirely regular users, but people who want to help us debug things by testing the -rc1 release. Those people are IMPORTANT. You belittling the whole concept just makes you look like an ass. > Not only does that not work like it always did, but it's also _really_ > hard to find out why, on occasion. And I told you that you could just improve the tools that track those dependencies ANYWAY! But what do you do? You just ignore it, talk about sed/grep, and bring up your Aunt Tillie again. Guess what? Maybe Aunt Tillie really *could* compile her own kernel. But even more importantly, you have both the expertise and the knowledge to make _your_ gripes go away, without having to just belittle and ignore everybody elses concerns. In other words, just make xconfig/gconfig/menuconfig/whatever say "Oops, I'm not going to disable i2c because of the following dependency: ..." and what is your problem? And don't tell me about Aunt Tillie or about how you refuse to do anything but grep's and sed's. If THAT is your problem, then you're barking up the wrong tree. Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 2007-02-05 at 15:09 -0800, Linus Torvalds wrote: > I also feel that a lot of people are "advanced" in one area, but not > necessarily in another. The Netfilter example I gave was one such personal > gripe of mine. I just feel like I shouldn't need to care! Yeah, I have the > knowledge, but I *still* want to be baby-fed with just a simple "anybody > can understand it". The netfilter example is totally irrelevant here, since 'select' is neither necessary nor sufficient for that. Russell and I have both pointed that out to you already. > Why? You could *trivially* have a tool tell you. Make "xconfig" or > something just pop up a window saying "sorry, you can't disable SCSI, > because you've got ATA enabled, and ATA wants SCSI". > > What's the big deal, here? Mostly that for the benefit of users who really don't actually configure their own kernels at all, we're screwing over the people who _do_, and who want this to work like it always did: sed -i -e 's/CONFIG_I2C=.*/# CONFIG_I2C is not set/' .config make oldconfig Not only does that not work like it always did, but it's also _really_ hard to find out why, on occasion. You have to grep all over the tree to find the offending 'select' statement. The other reason that a bunch of us are objecting is because we seem to be doing this for very little real benefit -- if we wanted to pander to Aunt Tillie, we could have done it in the tools. As I said, that was working ten years ago. Maybe not merged back into your tree but working nonetheless. It's not rocket science. But Alan makes a reasonable suggestion -- we could work around this in the tools too. I think you're very misguided in optimising for the people who aren't likely to be configuring their own kernels anyway, but despite the fact that others seem to agree with me, I don't hold out much hope of changing your mind. If we can hack up the kconfig library to work around this bogosity by (optionally) treating all 'select' of visible symbols as 'depends on' instead, then I think that should actually work OK. -- 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 5 Feb 2007, Randy Dunlap wrote: > > I think the problem is "who is make *config" for?". Absolutely. > Linus wants it to be for (unadvanced) users, but they tend to just > use distro kernels and distro configs, according to David, and I > agree with that. Well, the thing is, according to that logic, we might as well go back to the pre-Kconfig language entirely. I want people to feel that compiling their own kernel is *simple*. I also feel that a lot of people are "advanced" in one area, but not necessarily in another. The Netfilter example I gave was one such personal gripe of mine. I just feel like I shouldn't need to care! Yeah, I have the knowledge, but I *still* want to be baby-fed with just a simple "anybody can understand it". The same is true of the whole SATA/USB/SCSI thing. I know damn well that the kernel uses the SCSI layer for USB and SATA, yet I feel that the ATA layer does it right, and I just find the USB storage situation to be *offensively* bad in this regard. Why the HELL does it have those big comments and warnings, when it could just damn well enable SCSI support itself? So even advanced users aren't necessarily advanced outside their own area of expertise (I have no clue what I2C crud I'd need for some DVB card or even regular video card - or even *if* I need it). And even when they are advanced, they don't mind simple questions. This is not something where it's "good to be hard to use" (if those things even exist anywhere else either..) > > Claiming that "select" is evil is just totally strange. > > It's a real problem for developers who actually try to modify > configs. Why? You could *trivially* have a tool tell you. Make "xconfig" or something just pop up a window saying "sorry, you can't disable SCSI, because you've got ATA enabled, and ATA wants SCSI". What's the big deal, here? Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 5 Feb 2007 14:21:41 -0800 (PST) Linus Torvalds wrote: > On Mon, 5 Feb 2007, David Woodhouse wrote: > > > > Ten years ago, people used 'depends on' to fix the tools, so that then > > you want to enable something like USB_STORAGE, it can automatically turn > > SCSI on for you. > > > > Isn't that what you wanted? > > Try it. It's not what it does. > > If you have a > > depends on SCSI > > and you did not say you wanted SCSI, you'll never even *see* the question. > > It will *not* turn on SCSI automatically for you. Quite the reverse. It > will not even show you the option. > > In contrast, it you do a > > select SCSI > > you'll see the question, and it will do exactly what you claim "depends > on" does. Which yes, is what we want. > > So what's your problem? You argue as if you didn't understand the > difference between "depends on" and "select". I think the problem is "who is make *config" for?". David wants it to be for developers (ISTM) and "select" is a hassle for us. Linus wants it to be for (unadvanced) users, but they tend to just use distro kernels and distro configs, according to David, and I agree with that. So I think that make *config is more for developers and advanced (not embedded) users. > As an example of this, look at SATA. It does "select SCSI" if you select > CONFIG_ATA, _exactly_ because it actually wants to turn on the SCSI layer > *regardless* of what the user said. Because if the user said "n" to SCSI, > the user simply didn't know that the SATA code uses the SCSI code. > > Which is an example of what I've been saying all along: "select" makes > sense. USB_STORAGE should have done the same. > > Claiming that "select" is evil is just totally strange. It's a real problem for developers who actually try to modify configs. --- ~Randy - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 5 Feb 2007, Alan wrote: > > It works both ways. If I don't need to know that I must select SCSI then > it turns on easily. If I want to turn SCSI off then it causes mayhem. Two > sides of the same coin. They are not really symmetric, though. There's two big issues: - tuning things "on" is more likely to cause a working kernel. This is pretty fundamental. It's almost always simply more correct to add features than remove them. At worst, it won't be used. This argues that you should have to "work less" to turn something on, and in particular, you should need to _know_ less. To turn something off, you not only need to know how to turn it off, you fundamentally need to know something much bigger: you need to know that you really don't need it in the first place. The interaction of CONFIG_ATA/CONFIG_SCSI is an example of the latter. You really *do* need to know more to turn off SCSI - because you need to know that the ATA layer depends on it. So in the absense of knowledge, turning things on is better. - A developer who really wants to turn things off, and knows enough that that is actually safe, can really just do a "grep" for it. If you're _extremely_ knowledgeable, you can do something like git grep 'select.*\' -- '*onfig*' and that easily finds you the (currently single) place that turns on SCSI (and yes, you can try it with I2C too, and try to recursively figure out what it is that turns on I2C even though you *tried* to turn it off. I2C - the option that just wouldn't die! ;) So I agree that they are two facets of the same coin, but I claim that there's a huge reason why they are not mirror-images - there are often reasons to prefer one over the other. That said: I really don't think "depends on" should just always be "select" either. There's a balance: - you use "depends on" when you can ask a simple question like "what kind of machine do you have" or "do you want to support USB" or "do you have SCSI devices". But even then, you might end up having some devices that are *technically* USB, but people don't think of them that way (for example, some laptop add-ons are literally USB devices that are "built into" the laptop - you might well decide to show those choices even if somebody said "no USB", and if he then says "yeah, I have one of those things", you just know he wasn't clueful enough, and you enable USB behind his back _anyway_. Exact same thing as with SATA support) - you use "select" when the question more naturally went the other way (because the infrastructure isn't obvious) So they are two similar things, and which one to choose mainly depends on how you want to phrase the question - not on technical issues per se. So neither is "wrong". They both have their downsides. Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 5 Feb 2007, David Woodhouse wrote: > > Ten years ago, people used 'depends on' to fix the tools, so that then > you want to enable something like USB_STORAGE, it can automatically turn > SCSI on for you. > > Isn't that what you wanted? Try it. It's not what it does. If you have a depends on SCSI and you did not say you wanted SCSI, you'll never even *see* the question. It will *not* turn on SCSI automatically for you. Quite the reverse. It will not even show you the option. In contrast, it you do a select SCSI you'll see the question, and it will do exactly what you claim "depends on" does. Which yes, is what we want. So what's your problem? You argue as if you didn't understand the difference between "depends on" and "select". As an example of this, look at SATA. It does "select SCSI" if you select CONFIG_ATA, _exactly_ because it actually wants to turn on the SCSI layer *regardless* of what the user said. Because if the user said "n" to SCSI, the user simply didn't know that the SATA code uses the SCSI code. Which is an example of what I've been saying all along: "select" makes sense. USB_STORAGE should have done the same. Claiming that "select" is evil is just totally strange. Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
> > Really? Including the 'Scanner driver' card which arrived with my > > scanner? > > Can you read? Can you UNDERSTAND? > > This is exactly my point. > > If it's not obviously a SCSI card, then it shouldn't be "depends on SCSI". > It should be on its own and "select SCSI". It works both ways. If I don't need to know that I must select SCSI then it turns on easily. If I want to turn SCSI off then it causes mayhem. Two sides of the same coin. What is missing from the current config tools is that when you try and turn SCSI off you can't. If there is a "really turn it off" button, then you get told Disabling SCSI will disable USB scanner Foo Bar Disable Y/N it fixes Dave's problem. There are great examples of this - trying to kill off the I2C bus in a small build is one of the most painful. Yes users shouldn't need to know to turn it on, but it does need a way to turn it back off sanely. Alan - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 2007-02-05 at 13:49 -0800, Linus Torvalds wrote: > Can you read? Can you UNDERSTAND? > > This is exactly my point. > > If it's not obviously a SCSI card, then it shouldn't be "depends on SCSI". > It should be on its own and "select SCSI". > > The whole AND ALMOST ONLY point of "depends on" is really to allow people > to do a shorthand or know that "ok, he gave us some information that makes > this choice pointless". You're asking _me_ if I can read? Ten years ago, people used 'depends on' to fix the tools, so that then you want to enable something like USB_STORAGE, it can automatically turn SCSI on for you. Isn't that what you wanted? You don't need to screw over the technical users -- the _common_ case -- in order to achieve that. We had it. TEN YEARS AGO. In the tools. -- 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 5 Feb 2007, David Woodhouse wrote: > On Mon, 2007-02-05 at 13:28 -0800, Linus Torvalds wrote: > > Right. Because for MOST scsi drivers, it's obvious that they are SCSI to > > the user. > > Really? Including the 'Scanner driver' card which arrived with my > scanner? Can you read? Can you UNDERSTAND? This is exactly my point. If it's not obviously a SCSI card, then it shouldn't be "depends on SCSI". It should be on its own and "select SCSI". The whole AND ALMOST ONLY point of "depends on" is really to allow people to do a shorthand or know that "ok, he gave us some information that makes this choice pointless". And yes, we've messed that up. But you're apparently arguing that the mess-up is something "good". "select" is _good_. Because it's the thing that avoids us having to ask totally inane questions THAT DO NOT MAKE SENSE to a user. It's totally idiotic that we should ask people for SCSI support. That's not a user question, unless we're talking "odd-ball obviously SCSI devices", and then the question actually makes sense as a way to allow 99% of all users to say "nope" and not have to see another million questions that aren't relevant to them. Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 2007-02-05 at 21:50 +, Alan wrote: > > No, you're thinking of something else. The use of 'select' just turns > > the problem backwards -- if _every_ SCSI hostadapter were to 'select > > SCSI' instead of depending on it, then I'd have to say 'n' to every damn > > one of them instead of being able to just say 'n' to SCSI as I can at > > the moment. > > Tools issue. You want a "really de-select right now" button That's a useful suggestion actually -- one answer to this bogus proliferation of 'select' is to hack the tools so that they treat occurrences of 'select' referring to a _visible_ option as the dependencies which they _should_ have been, rather than this silly new behaviour. -- 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 2007-02-05 at 13:28 -0800, Linus Torvalds wrote: > Right. Because for MOST scsi drivers, it's obvious that they are SCSI to > the user. Really? Including the 'Scanner driver' card which arrived with my scanner? Is that like the 'RAID' card which is obviously RAID to the user, and not at all IDE? > But if you cannot see that this is something TOTALLY DIFFERENT from USB > storage, you're either being obtuse on purpose, or just incapable of > understanding humans. > > We should NEVER have had "USB_STORAGE" depending on SCSI. It'sa BUG. It's > a _stupid_ bug. > > We should have done what is sane: > - make CONFIG_SCSI (as a "support the SCSI layer" be invisible to users, >because it's not a user decision. > - have a CONFIG_SCSI_DRIVER question for "do you want to be asked about >SCSI drivers" (and which also does "select SCSI" for you) > - make USB_STORAGE _also_ do the "select SCSI" thing. Crap. What we should have done is fix the tools so that when you go to enable USB_STORAGE, it either prompts you or automatically turns on SCSI. I saw versions of our tcl xconfig a _decade_ ago which were capable of this, but we never cared enough to merge it -- although I _thought_ our new xconfig could do it these days. > In other words, you seem to be totally unable to grasp my argument. You > are arguing on TOTALLY IRRELEVANT TECHNICAL GROUNDS. That's not what the > Kconfig language is about. The Kconfig language and rules are about HUMAN > interaction. Well that's a shame, because any sane person would realise that most humans interact with kernel configuration only through a distribution. > So next time you say something about Kconfig, ask yourself: "What question > would a user want to see". > > Any other question is pretty much totally irrelevant, and your "don't use > select" rule comes from your confusion that thinks that it's somehow about > machines and technical issues. It's not. No, really. Eric's Aunt Tillie can go screw herself backwards with a chainsaw. I care about _my_ use of configuration, and mostly my requirement is that I want to turn something _off_ either because it doesn't work, or I want it modular so I can hack on it, or because I'm trying to cut down kernel size and I don't want it. The proliferation of 'select' has made that a _complete_ pain in the wossname, apparently for the benefit of some hypothetical relative of a gun nut, who doesn't actually care because in general she doesn't configure her own kernel anyway. Russell is right -- using 'select' just turns the problem backwards, pessimising it for the _common_ case. -- 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
> No, you're thinking of something else. The use of 'select' just turns > the problem backwards -- if _every_ SCSI hostadapter were to 'select > SCSI' instead of depending on it, then I'd have to say 'n' to every damn > one of them instead of being able to just say 'n' to SCSI as I can at > the moment. Tools issue. You want a "really de-select right now" button Alan - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 5 Feb 2007, David Woodhouse wrote: > > No, you're thinking of something else. The use of 'select' just turns > the problem backwards -- if _every_ SCSI hostadapter were to 'select > SCSI' instead of depending on it, then I'd have to say 'n' to every damn > one of them instead of being able to just say 'n' to SCSI as I can at > the moment. Right. Because for MOST scsi drivers, it's obvious that they are SCSI to the user. So we ask "do you want SCSI" in order to not ask a million questions that a lot of people know a-priori that they don't want. But if you cannot see that this is something TOTALLY DIFFERENT from USB storage, you're either being obtuse on purpose, or just incapable of understanding humans. We should NEVER have had "USB_STORAGE" depending on SCSI. It'sa BUG. It's a _stupid_ bug. We should have done what is sane: - make CONFIG_SCSI (as a "support the SCSI layer" be invisible to users, because it's not a user decision. - have a CONFIG_SCSI_DRIVER question for "do you want to be asked about SCSI drivers" (and which also does "select SCSI" for you) - make USB_STORAGE _also_ do the "select SCSI" thing. In other words, you seem to be totally unable to grasp my argument. You are arguing on TOTALLY IRRELEVANT TECHNICAL GROUNDS. That's not what the Kconfig language is about. The Kconfig language and rules are about HUMAN interaction. So next time you say something about Kconfig, ask yourself: "What question would a user want to see". Any other question is pretty much totally irrelevant, and your "don't use select" rule comes from your confusion that thinks that it's somehow about machines and technical issues. It's not. Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 2007-02-05 at 08:58 -0800, Linus Torvalds wrote: > More importantly, some things that *are* visible probably shouldn't be, or > should perhaps only be in expert mode (aka "EMBEDDED"). I've heard some fairly stupid abuse of the term 'embedded' in my time, but rarely have I heard people daft enough to abuse it to mean 'expert'. But yes, that's what we use CONFIG_EMBEDDED for. > A prime example of this is all the firewall settings. I'd personally > prefer to just select a "default firewall setup" which would be enough > for all the normal crud, instead of seeing 50 different choices. No, that's a really poor example. That's not what 'select' is for. We can handle that kind of thing perfectly well without select -- just with sensible _defaults_, much as we do for block device partitions and a few other things. > Me, I'd like to say I want "default firewall built in", and not have to > see *any* of the crap. And that's exactly why "select" is a good thing. > > Not using select, and have people having to say "y" to the basic feature > and then y/m/n to each sub-feature is really damn annoying. No, you're thinking of something else. The use of 'select' just turns the problem backwards -- if _every_ SCSI hostadapter were to 'select SCSI' instead of depending on it, then I'd have to say 'n' to every damn one of them instead of being able to just say 'n' to SCSI as I can at the moment. Well, I say 'just turns it backwards', but in fact it also makes it much worse, because it's now much _harder_ to turn SCSI off, because there might be random stuff else elsewhere in the tree which selects it rather than having all the dependencies right on the option I'm interested in, where I can see them and turn them on/off as required. The dependency thing for Aunt Tillie is easily fixed in the tools, and the firewall example you're thinking of is _far_ from being an example of why 'select' is useful. -- 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Monday, 5. February 2007, Linus Torvalds wrote: > So thank God for the few selects we have, and we should add a whole lot > more! But "select" is not fine grained enough. I would like to have "require", "recommend", "suggest" for feature A. require X does not work without X, but X is way down the tree e.g. ext3 and block device or how select currently is intended recommend X it is usable but uncomfortable without X, enabled per default e.g. firewalling recommends connection tracking support or NAT recommends all NAT helpers suggest X many people use A together with X, so you might be interested in enabling it, but I disabled it per default unless you said "featuritis mode" before. e.g. highmem and SMP or a network driver and NAPI. That is what the Debian/Ubuntu package management does and maybe other too. And this also gives us new keywords to replace select with, so migration is doable :-) This would also make "EMBEDDED" superflous, because it would just mean "disable anything not required". And this would enable an individual tree for the users current configuration problem instead of a global one. Regards Ingo "and tomorrow we change the world" Oeser :-) - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
* Linus Torvalds <[EMAIL PROTECTED]> wrote: > Me, I'd like to say I want "default firewall built in", and not have > to see *any* of the crap. And that's exactly why "select" is a good > thing. yeah. For a long time i wanted to do something like that for all the kernel debugging options, to by default only offer a simple menu of: ( ) Debug Disabled (*) Transparent Low-Overhead Debugging ( ) Transparent Medium-Overhead Debugging ( ) Transparent High-Overhead Debugging ( ) Custom Debugging so say softlockup-detect or spinlock-sleep checks would be enabled by Low-Overhead Debugging, but slab-debug or lockdep would only be enabled by the High-Overhead Debugging option. and all the zillions of debug options would only show up if "Custom Debugging" is selected. Plus this would have the advantage that if we add a new debug option, and the tester already has a .config with say "Transparent Low-Overhead Debugging" enabled - Kconfig would pick the right value for that new debug option. This would remove the need and desire to 'default y' certain debugging features to get them tested ... Ingo - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, Feb 05, 2007 at 08:58:10AM -0800, Linus Torvalds wrote: > On Mon, 5 Feb 2007, Ingo Molnar wrote: > > > > but this is /only/ practical if all (even disabled) features are visible > > (and selectable) in the tools. They are not at the moment, so selects > > are quite useful. > > More importantly, some things that *are* visible probably shouldn't be, or > should perhaps only be in expert mode (aka "EMBEDDED"). > > A prime example of this is all the firewall settings. I'd personally > prefer to just select a "default firewall setup" which would be enough > for all the normal crud, instead of seeing 50 different choices. That also falls within my rule of "user visible symbols should not be selected". But... we already do something like this already and it doesn't take a scattering of "select" to achieve. Look at fs/partitions/Kconfig as a good example. You get offered "Advanced partition support" as the first question. If you say "N", you get something reasonable for your platform. If you say "Y" you're free to choose whatever silly combination you want, but with reasonable defaults offered. That's something that a sprinking of select just can't do. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, Feb 05, 2007 at 05:52:33PM +0100, Ingo Molnar wrote: > > * Russell King <[EMAIL PROTECTED]> wrote: > > > and the rest (ie, except integrator, versatile and ixp4xx) has: > > > > config ARCH_SHARK > > bool "Shark" > > select PCI > > > > IOW, the "PCI support" question isn't offered for platforms which > > require PCI to be present, but is offered on platforms where it's > > optional. > > yeah. I think this also fits into the special-case i mentioned: it isnt > connected to something user-selectable, it's a side-effect of the first > 'feature selection' the user does: 'what platform do you compile your > kernel on'. As such it is a convenience group-selection. > > i.e. what we have behind this is still a clean tree of dependencies. I agree 100% with that - since when that happens it's possible to traverse the tree to tell the user what's going on. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 5 Feb 2007, Ingo Molnar wrote: > > but this is /only/ practical if all (even disabled) features are visible > (and selectable) in the tools. They are not at the moment, so selects > are quite useful. More importantly, some things that *are* visible probably shouldn't be, or should perhaps only be in expert mode (aka "EMBEDDED"). A prime example of this is all the firewall settings. I'd personally prefer to just select a "default firewall setup" which would be enough for all the normal crud, instead of seeing 50 different choices. And dammit, I'm supposed to be "technical". So if _I_ find it irritating to have to select all those NF_MATCH_xxx/NF_TARGET_xxx crud things, imagine what most people must feel like? Me, I'd like to say I want "default firewall built in", and not have to see *any* of the crap. And that's exactly why "select" is a good thing. Not using select, and have people having to say "y" to the basic feature and then y/m/n to each sub-feature is really damn annoying. So thank God for the few selects we have, and we should add a whole lot more! Linus - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
* Russell King <[EMAIL PROTECTED]> wrote: > and the rest (ie, except integrator, versatile and ixp4xx) has: > > config ARCH_SHARK > bool "Shark" > select PCI > > IOW, the "PCI support" question isn't offered for platforms which > require PCI to be present, but is offered on platforms where it's > optional. yeah. I think this also fits into the special-case i mentioned: it isnt connected to something user-selectable, it's a side-effect of the first 'feature selection' the user does: 'what platform do you compile your kernel on'. As such it is a convenience group-selection. i.e. what we have behind this is still a clean tree of dependencies. The mess begins i think when options with real code behind them start to grow back and forth dependencies in form of criss-crossing 'depends on' and 'select' instances. Ingo - 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: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 2007-02-05 at 08:32 -0800, Linus Torvalds wrote: > > On Mon, 5 Feb 2007, David Woodhouse wrote: > > > > Secondly, please don't _ever_ use 'select'. > > No, David. > > I don't know why you keep repeating this mantra, when it's WRONG. It may not shock you to find that I repeat it because I disagree. > Using "select" is a lot more sane and intelligent than assuming that users > know what dependencies they want. > > The Kconfig files should ask about *end-user* visible features. They > should say "do you want to support X". For the benefit of some, that's useful. Others still want to be able to turn off entire subsystems when they don't compile or when they want to quickly build a minimal kernel. It's become very hard to do that though. > If "X" then needs Y, Z and something else to actually compile, then that > Kconfig file should DAMN WELL use "select". Stop claiming anything else! I agree that the tools should let them do that easily. It doesn't necessarily follow that we should use 'select' for that purpose. > The user shouldn't know that they should say that they need some library Y > in order to even see the question for "X". It's not a sane thing to ask > them to know and care about. They care about the devices or capabilities > they want to support, not about the fact that a USB storage device needs > the SCSI core layer, for example. This I agree with. And it's something which the _tools_ have been capable of for a long time. You don't need 'select'. The problem is that the widespread and inconsistent use of 'select' for Aunt Tillie's benefit causes problems for a _different_ set of people. To use Ingo's example -- if I want to turn off CONFIG_I2C because it doesn't build or I want it modular to hack on it, I want to be able to just _do_ that. I don't want to find that it's forced to 'Y' because I also happen to be building support for some esoteric peripheral that I've never heard of. I want that that peripheral to be turned _off_ when I turn I2C off. I don't want to have to spend hours grepping _all_ over the tree to find out what's forcing I2C on again. When it was just dependencies, it was easy enough to find -- it was right there in the Kconfig file in one place. Now it's a lot harder. And I'm sure you aren't seriously suggesting that we should take it all the way and that, for example, all SCSI host drivers should 'select SCSI' rather than merely depending on SCSI? If I configure a kernel I don't _want_ to be asked individually about every leaf option -- I want to be able to turn stuff off in an orderly fashion; in a tree as Ingo suggests. -- 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/
