Re: sata & scsi suggestion for make menuconfig
On Sat, 15 Sep 2007, Paul Rolland wrote: On Fri, 14 Sep 2007 17:15:22 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote: On Fri, Sep 14, 2007 at 04:54:07PM +0200, Stefan Richter wrote: Adrian Bunk wrote: On Sun, Sep 09, 2007 at 05:11:44PM -0400, Jeff Garzik wrote: Let's step back a moment and consider the actual scale and impact of the problem at hand. Do "make menuconfig" with the .config you are normally using, count the number of options that are visible, and ask yourself whether we can really expect users to read the help texts for every single option shown. People mostly read help texts for options where they don't understand what this option is about - and "Serial ATA" therefore is an option that is likely to get enabled without the user looking at the help text. As a "make menuconfig" user, let me say that I agree. Of course, I'm used to rebuild kernel, but sometimes, some options are not clear, and the help text is searched for. But, getting too much of "No help text available" usually results in people no more reading the help text. What about splitting the screen to have the top half with the menu, and the bottom half with the help ? I useually have more screen space available to the side then above and below the list of options. 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: x86_64 usability bug: Kconfig prompt without help text (was Re: sata & scsi suggestion for make menuconfig)
> - So, which criteria influence whether HPET_EMULATE_RTC should be > enabled on x86_64 or not? If there is one it needs to be a runtime switch anyways. > > - In case that there is no compelling reason to disable it if its > dependencies are satisfied, shouldn't it rather be invisible and > automatic like on i386? It should be automatic. Please send a patch. -Andi - 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/
x86_64 usability bug: Kconfig prompt without help text (was Re: sata & scsi suggestion for make menuconfig)
I take the liberty to modify the CC list. Paul Rolland wrote: > Stefan Richter <[EMAIL PROTECTED]> wrote: >> I assert that a Kconfig prompt (a visible Kconfig variable) _without_ >> help text is a bug. > > Here is an example from 2.6.34-rc6 : > .config - Linux Kernel v2.6.23-rc6 Configuration > -- > +- Provide RTC interrupt -+ > | There is no help available for this kernel option. | > | Symbol: HPET_EMULATE_RTC [=y] | > | Prompt: Provide RTC interrupt | > | Defined at arch/x86_64/Kconfig:471| > | Depends on: HPET_TIMER && RTC=y | > | Location: | > | -> Processor type and features | The same prompt existed in arch/i386/Kconfig without help text too but it was later made invisible and automatic by pre-2.6.13 patch "remove special HPET_EMULATE_RTC config option", commit c91096d85c95c6b7fe8d7065e2aa6825e0bdaca9: "We had a user whose apps weren't working correctly because his "rtc" wasn't working fully. For the sake of simplicity, it seems sensible to always enable HPET RTC emulation." - So, which criteria influence whether HPET_EMULATE_RTC should be enabled on x86_64 or not? - In case that there is no compelling reason to disable it if its dependencies are satisfied, shouldn't it rather be invisible and automatic like on i386? -- Stefan Richter -=-=-=== =--= - http://arcgraph.de/sr/ - 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: sata & scsi suggestion for make menuconfig
Hello Stefan, On Sat, 15 Sep 2007 10:25:39 +0200 Stefan Richter <[EMAIL PROTECTED]> wrote: > Paul Rolland wrote: > > getting too much of "No help text available" > > usually results in people no more reading the help text. > > I assert that a Kconfig prompt (a visible Kconfig variable) _without_ > help text is a bug. Here is an example from 2.6.34-rc6 : .config - Linux Kernel v2.6.23-rc6 Configuration -- +- Provide RTC interrupt -+ | There is no help available for this kernel option. | | Symbol: HPET_EMULATE_RTC [=y] | | Prompt: Provide RTC interrupt | | Defined at arch/x86_64/Kconfig:471| | Depends on: HPET_TIMER && RTC=y | | Location: | | -> Processor type and features | Regards, Paul - 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: sata & scsi suggestion for make menuconfig
Paul Rolland wrote: > getting too much of "No help text available" > usually results in people no more reading the help text. I assert that a Kconfig prompt (a visible Kconfig variable) _without_ help text is a bug. -- Stefan Richter -=-=-=== =--= - http://arcgraph.de/sr/ - 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: sata & scsi suggestion for make menuconfig
Hello, On Fri, 14 Sep 2007 17:15:22 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Fri, Sep 14, 2007 at 04:54:07PM +0200, Stefan Richter wrote: > > Adrian Bunk wrote: > > > On Sun, Sep 09, 2007 at 05:11:44PM -0400, Jeff Garzik wrote: > > >> Let's step back a moment and consider the actual scale and impact of > > >> the problem at hand. > Do "make menuconfig" with the .config you are normally using, count the > number of options that are visible, and ask yourself whether we can > really expect users to read the help texts for every single option shown. > > People mostly read help texts for options where they don't understand > what this option is about - and "Serial ATA" therefore is an option that > is likely to get enabled without the user looking at the help text. > As a "make menuconfig" user, let me say that I agree. Of course, I'm used to rebuild kernel, but sometimes, some options are not clear, and the help text is searched for. But, getting too much of "No help text available" usually results in people no more reading the help text. What about splitting the screen to have the top half with the menu, and the bottom half with the help ? Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin, Electronic Frontier Foundation - 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: sata & scsi suggestion for make menuconfig
Goswin von Brederlow wrote: > Helge Hafting <[EMAIL PROTECTED]> writes: >> Randy Dunlap wrote: >>> NOTE: ATA enables basic SCSI support; *however*, >>> 'SCSI disk support', 'SCSI tape support', or >>> 'SCSI CDROM support' may also be needed, >>> depending on your hardware configuration. > > Could one duplicate the configure options for scsi disk/tape/cdrom at > that place? Yes, e.g. like in http://lkml.org/lkml/2007/9/8/9. > The text should then probably read SCSI/SATA disk support in both places. Or rather than duplicating the menu items for the same options, split the SCSI high-level options out into a top-level menu and adjust the wording of the prompts. http://lkml.org/lkml/2007/9/14/217 (top level) menu "Storage (core and SCSI commands)" config SCSI tristate "Storage support (core and SCSI commands)" config BLK_DEV_SD tristate "Harddisks and other Direct access devices" config CHR_DEV_ST tristate "Tape drives" config CHR_DEV_OSST tristate "SCSI OnStream SC-x0 tape support" config BLK_DEV_SR tristate "CD-ROMs, DVD-ROMs" ... menu "Device Drivers" ... menu "SCSI device support" config RAID_ATTRS config SCSI_TGT menu "SCSI Transports" ... menuconfig SCSI_LOWLEVEL bool "SCSI low-level drivers" ... -- Stefan Richter -=-=-=== =--= -===- http://arcgraph.de/sr/ - 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: sata & scsi suggestion for make menuconfig
Adrian Bunk wrote: > On Fri, Sep 14, 2007 at 05:37:37PM +0200, Stefan Richter wrote: >> In >> practice, this takes too much time, hence you take an existing .config >> (yours or somebody else's) and go from there. > > Kconfig let's you start with the defconfig when doing "make menuconfig" > without any .config present, [...] This is one of those "somebody else's .config". >> Whenever one enables an option for the first time, it would IMO be >> foolish to ignore its help text. > > Then the number of non-foolish users is quite near to 0... Perhaps. Although I meant only options which one enables oneself, not options which are taken over from somebody else's .config. > If you expect people to read several hundreds or thousands of help texts > only for configuring a kernel then you are expecting something that is > simply not realistic. > > It is intuitive for a user to enable the "Serial ATA" menu and he might > not expect to have to read the help text when he has SATA drivers, while > having to enable anything in the "SCSI device support" menu is highly > unintuitively when the user does not have SCSI hardware. It surely is unintuitive, and it is one of the worse cases where the current menu layout is unintuitive. We have to improve that, even though it is ultimately impossible to serve everyone's needs equally well or, generally, make kernel configuration a piece of cake. Note though, some suggestions which came up here don't actually make the menus more intuitive. Notably the patch "Select BLK_DEV_SD for all SCSI/libata drivers" is counterintuitive in a different color: It follows the philosophy of "I know what's good for you and I act on your behalf behind your back --- trust me, it's for your best". I too am guilty of proposing the usage of 'select' (http://lkml.org/lkml/2007/9/8/9) but I suggested a variant which lets the user stay informed and in control (as far as this is possible with 'select' which always increases complexity, never reduces it). But rather than adding multiple menu items which enable the same option, a reorganization of the menus which better reflect the role of SCSI core and SCSI highlevel might be more effective --- similar to "Networking" which is separate from "Network device support" (http://lkml.org/lkml/2007/9/10/5, http://lkml.org/lkml/2007/9/10/115). -- Stefan Richter -=-=-=== =--= -===- http://arcgraph.de/sr/ - 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: sata & scsi suggestion for make menuconfig
Helge Hafting <[EMAIL PROTECTED]> writes: > Randy Dunlap wrote: >> On Fri, 7 Sep 2007 14:48:00 +0200 Folkert van Heusden wrote: >> >> >>> Hi, >>> >>> Maybe it is a nice enhancement for make menuconfig to more explicitly >>> give a pop-up or so when someone selects for example a sata controller >>> while no 'scsi-disk' support was selected? >>> >> >> I know that it's difficult to get people to read docs & help text, >> and maybe it is needed in more places, but CONFIG_ATA (SATA/PATA) >> help text says: >> >> NOTE: ATA enables basic SCSI support; *however*, >> 'SCSI disk support', 'SCSI tape support', or >> 'SCSI CDROM support' may also be needed, >> depending on your hardware configuration. Could one duplicate the configure options for scsi disk/tape/cdrom at that place? The text should then probably read SCSI/SATA disk support in both places. MfG Goswin - 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: sata & scsi suggestion for make menuconfig
On Fri, Sep 14, 2007 at 05:37:37PM +0200, Stefan Richter wrote: > Adrian Bunk wrote: > > On Fri, Sep 14, 2007 at 04:54:07PM +0200, Stefan Richter wrote: > >> The patch which is discussed here is specifically targeted towards users > >> who are convinced that they can migrate to different drivers without > >> reading Kconfig help texts. > > > > Nothing about the patch is only about migration. > > > > The same applies if you configure a kernel from scratch. > > > > Do "make menuconfig" with the .config you are normally using, count the > > number of options that are visible, and ask yourself whether we can > > really expect users to read the help texts for every single option shown. > > > > People mostly read help texts for options where they don't understand > > what this option is about - and "Serial ATA" therefore is an option that > > is likely to get enabled without the user looking at the help text. > > If you create .config from scratch, then you can get away without > reading help texts if you have a target with minimal hardware and > protocols requirements and you know all the subsystems involved. > > In all other cases, you theoretically need to read all help texts (minus > the ones that don't appear because you deselect entire subsystems). In > practice, this takes too much time, hence you take an existing .config > (yours or somebody else's) and go from there. Kconfig let's you start with the defconfig when doing "make menuconfig" without any .config present, so in practice users start from the defconfig and then go through all menus at once enabling and disabling options to adapt the configurations to their needs. Or they start from the "includes everything" .config of their distribution and remove everything they don't need. > Whenever one enables an option for the first time, it would IMO be > foolish to ignore its help text. Then the number of non-foolish users is quite near to 0... If you expect people to read several hundreds or thousands of help texts only for configuring a kernel then you are expecting something that is simply not realistic. It is intuitive for a user to enable the "Serial ATA" menu and he might not expect to have to read the help text when he has SATA drivers, while having to enable anything in the "SCSI device support" menu is highly unintuitively when the user does not have SCSI hardware. > Stefan Richter cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: sata & scsi suggestion for make menuconfig
Adrian Bunk wrote: > On Fri, Sep 14, 2007 at 04:54:07PM +0200, Stefan Richter wrote: >> The patch which is discussed here is specifically targeted towards users >> who are convinced that they can migrate to different drivers without >> reading Kconfig help texts. > > Nothing about the patch is only about migration. > > The same applies if you configure a kernel from scratch. > > Do "make menuconfig" with the .config you are normally using, count the > number of options that are visible, and ask yourself whether we can > really expect users to read the help texts for every single option shown. > > People mostly read help texts for options where they don't understand > what this option is about - and "Serial ATA" therefore is an option that > is likely to get enabled without the user looking at the help text. If you create .config from scratch, then you can get away without reading help texts if you have a target with minimal hardware and protocols requirements and you know all the subsystems involved. In all other cases, you theoretically need to read all help texts (minus the ones that don't appear because you deselect entire subsystems). In practice, this takes too much time, hence you take an existing .config (yours or somebody else's) and go from there. Whenever one enables an option for the first time, it would IMO be foolish to ignore its help text. -- Stefan Richter -=-=-=== =--= -===- http://arcgraph.de/sr/ - 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: sata & scsi suggestion for make menuconfig
On Fri, Sep 14, 2007 at 04:54:07PM +0200, Stefan Richter wrote: > Adrian Bunk wrote: > > On Sun, Sep 09, 2007 at 05:11:44PM -0400, Jeff Garzik wrote: > >> Let's step back a moment and consider the actual scale and impact of the > >> problem at hand. > >> > >> The vast majority of users are consumers of pre-compiled kernels, built by > >> People With Clue(tm), who figured this stuff out as soon as it was > >> introduced. > [...] > > In my experience, the vast majority of kconfig users are not the few > > people working on distribution kernels, most of the kconfig userbase > > could be better described by the use case "sysadmin who knows about the > > hardware in his machine and which filesystems he uses". > > The patch which is discussed here is specifically targeted towards users > who are convinced that they can migrate to different drivers without > reading Kconfig help texts. Nothing about the patch is only about migration. The same applies if you configure a kernel from scratch. Do "make menuconfig" with the .config you are normally using, count the number of options that are visible, and ask yourself whether we can really expect users to read the help texts for every single option shown. People mostly read help texts for options where they don't understand what this option is about - and "Serial ATA" therefore is an option that is likely to get enabled without the user looking at the help text. > Stefan Richter cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: sata & scsi suggestion for make menuconfig
Adrian Bunk wrote: > On Sun, Sep 09, 2007 at 05:11:44PM -0400, Jeff Garzik wrote: >> Let's step back a moment and consider the actual scale and impact of the >> problem at hand. >> >> The vast majority of users are consumers of pre-compiled kernels, built by >> People With Clue(tm), who figured this stuff out as soon as it was >> introduced. [...] > In my experience, the vast majority of kconfig users are not the few > people working on distribution kernels, most of the kconfig userbase > could be better described by the use case "sysadmin who knows about the > hardware in his machine and which filesystems he uses". The patch which is discussed here is specifically targeted towards users who are convinced that they can migrate to different drivers without reading Kconfig help texts. -- Stefan Richter -=-=-=== =--= -===- http://arcgraph.de/sr/ - 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: sata & scsi suggestion for make menuconfig
Randy Dunlap wrote: On Fri, 7 Sep 2007 14:48:00 +0200 Folkert van Heusden wrote: Hi, Maybe it is a nice enhancement for make menuconfig to more explicitly give a pop-up or so when someone selects for example a sata controller while no 'scsi-disk' support was selected? I know that it's difficult to get people to read docs & help text, and maybe it is needed in more places, but CONFIG_ATA (SATA/PATA) help text says: NOTE: ATA enables basic SCSI support; *however*, 'SCSI disk support', 'SCSI tape support', or 'SCSI CDROM support' may also be needed, depending on your hardware configuration. A popup makes some sense, but I don't know if menuconfig knows how to do popup warnings... and it needs to be done for all *configs, not just menuconfig. A popup hardly ever makes sense - popups generally are a bad user interface. The user will have to dismiss the popup - every time - whether he needs the warning or not. But feel free to print a warning somewhere, such as a status line. The warning itself is useful, but not something we will have to dismiss in order to go on with the job. Helge Hafting - 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: sata & scsi suggestion for make menuconfig
On Sun, Sep 09, 2007 at 05:11:44PM -0400, Jeff Garzik wrote: > Andi Kleen wrote: >>> I can see where you're coming from, but logically, this is wrong. >>> There's a huge slew of enterprise machines that only have DVD on SATA. >> ... and enterprise systems don't really care about a few KB more of code. >> In fact you definitely want to have SATA compiled in in case you need >> to recover the machine later when the SAN is down. >>> On the other hand, all of these machines will have SCSI disk devices on >>> various other transports, so no harm is done, it's just an inelegant >>> solution. >> Do you know of a better one? > > Let's step back a moment and consider the actual scale and impact of the > problem at hand. > > The vast majority of users are consumers of pre-compiled kernels, built by > People With Clue(tm), who figured this stuff out as soon as it was > introduced. We are talking about a patch to kconfig, and the users using pre-compiled kernels are not kconfig users. > The current setup expresses the dependencies as they exist -- OPTIONAL > extras, and that is a problem once a year or so, when someone builds their > own kernel but must learn this fact anew. > > There is simply no compelling need at all to change things from the current > setup. > > Our Kconfig system is for people who already know the kernel, not Aunt > Tillie. Couldn't we just remove kconfig and assume that all "people who already know the kernel" anyway prefer to edit their .config using vi? ;-) In my experience, the vast majority of kconfig users are not the few people working on distribution kernels, most of the kconfig userbase could be better described by the use case "sysadmin who knows about the hardware in his machine and which filesystems he uses". And there must have been a reason why a leading kernel developer has written a complete book covering only configuration and building of the kernel - the target audience of this book are most likely not "people who already know the kernel". > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: sata & scsi suggestion for make menuconfig
Andi Kleen wrote on 09-09-07 23:22: When it costs 1 people half an hour to learn and correct this it wasted 5000 hours of previous livetime. ^^ ^ Poor me. Here I am -- still waiting for my 15 minutes of fame in /this/ life... ;-) bjd - 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: sata & scsi suggestion for make menuconfig
On 09/10/2007 08:38 AM, Stefan Richter wrote: Nevertheless we should try to arrange the menus in a way that makes sense to as many people as possible. The difficulty is, different environments call for different menu layouts, as your previous example of SATA DVD-only boxes demonstrates. However, liberal usage of 'select' is not the ultimate solution to create menus that work for more people. Just one problem with select is that it works behind the back of the people configuring kernels (unless they use an UI with debug options turned on) --- they have less control, they are less informed. ATA already 'select's SCSI. What do we gain from hiding the fact that Linux' SCSI option is not just for those 50-wire ribbons (which people still think SCSI stands for) but is a very central Linux subsystem for even more than what complies to the SCSI family of standards? 'select' should really be limited to switch on small library-like code without further dependencies or requirements. SCSI, together with its upper layer options, is not of this kind of library. We should think about order and grouping of prompts and the labels of prompts (there were already suggestions in this discussion) before we resort to 'select' --- or even worse, select options unconditionally which are not always necessary to be enabled. A pro pos grouping of options --- consider how options for another central subsystem are laid out: Networking Networking options ... TCP/IP networking ... ... Device Drivers ... Network device support ... Ethernet (10 or 100MBit) ... ... This also happens to reflect the layout of sources in directories, and the current SCSI menu layout is close to source layout too --- but it doesn't have to be that way. If someone's keen on really restructuring these things -- in this analogy: Storage Storage Options ... Disk Optical ... ... Device Drivers ... Storage Support ... IDE PATA SATA SCSI USB FW ... ... (sound is an example where both in the menus and the tree everything is kept under one top-level sound/ directory, not sound/ and drivers/sound/ as for networking -- opinions may vary which one's better I guess). This is just config menus -- on a source code level, it would also make sense at least at some point to introduce "storage/" alongside net/ and sound/ and move things around I guess. Rene. - 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: sata & scsi suggestion for make menuconfig
James Bottomley wrote: > On Sun, 2007-09-09 at 23:22 +0200, Andi Kleen wrote: >> When it costs 1 people half an hour to learn and correct this it >> wasted 5000 hours of previous livetime. >> >> Besides there is no good reason to have ever learned this imho. > > The process of becoming an expert in the kernel build system naturally > involves making mistakes and learning from them, so this is probably > time reasonably well spent. Nevertheless we should try to arrange the menus in a way that makes sense to as many people as possible. The difficulty is, different environments call for different menu layouts, as your previous example of SATA DVD-only boxes demonstrates. However, liberal usage of 'select' is not the ultimate solution to create menus that work for more people. Just one problem with select is that it works behind the back of the people configuring kernels (unless they use an UI with debug options turned on) --- they have less control, they are less informed. ATA already 'select's SCSI. What do we gain from hiding the fact that Linux' SCSI option is not just for those 50-wire ribbons (which people still think SCSI stands for) but is a very central Linux subsystem for even more than what complies to the SCSI family of standards? 'select' should really be limited to switch on small library-like code without further dependencies or requirements. SCSI, together with its upper layer options, is not of this kind of library. We should think about order and grouping of prompts and the labels of prompts (there were already suggestions in this discussion) before we resort to 'select' --- or even worse, select options unconditionally which are not always necessary to be enabled. A pro pos grouping of options --- consider how options for another central subsystem are laid out: Networking Networking options ... TCP/IP networking ... ... Device Drivers ... Network device support ... Ethernet (10 or 100MBit) ... ... This also happens to reflect the layout of sources in directories, and the current SCSI menu layout is close to source layout too --- but it doesn't have to be that way. -- Stefan Richter -=-=-=== =--= -=-=- http://arcgraph.de/sr/ - 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: sata & scsi suggestion for make menuconfig
On Sun, 2007-09-09 at 23:22 +0200, Andi Kleen wrote: > > The current setup expresses the dependencies as they exist -- OPTIONAL > > extras, and that is a problem once a year or so, when someone builds > > Disk support over SCSI/SATA is hardly an "optional extra". It's more the 99+% > case. Using that argument, there's an equal case for always requiring SCSI to be built for every kernel, since very few people can boot a system without a disk. However, the 1% case is the embedded flash booting community plus a few others, so we allow SCSI to be optional for our 1% who don't want it. At base, the Kconfig system is designed to give the greatest flexibility with the fewest foot shooting opportunities. However, we do tend to err on the side of flexibility if there's a conflict between the two design goals. > > their own kernel but must learn this fact anew. > > When it costs 1 people half an hour to learn and correct this it > wasted 5000 hours of previous livetime. > > Besides there is no good reason to have ever learned this imho. The process of becoming an expert in the kernel build system naturally involves making mistakes and learning from them, so this is probably time reasonably well spent. James - 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: sata & scsi suggestion for make menuconfig
> The current setup expresses the dependencies as they exist -- OPTIONAL > extras, and that is a problem once a year or so, when someone builds Disk support over SCSI/SATA is hardly an "optional extra". It's more the 99+% case. > their own kernel but must learn this fact anew. When it costs 1 people half an hour to learn and correct this it wasted 5000 hours of previous livetime. Besides there is no good reason to have ever learned this imho. -Andi - 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: sata & scsi suggestion for make menuconfig
Andi Kleen wrote: I can see where you're coming from, but logically, this is wrong. There's a huge slew of enterprise machines that only have DVD on SATA. ... and enterprise systems don't really care about a few KB more of code. In fact you definitely want to have SATA compiled in in case you need to recover the machine later when the SAN is down. On the other hand, all of these machines will have SCSI disk devices on various other transports, so no harm is done, it's just an inelegant solution. Do you know of a better one? Let's step back a moment and consider the actual scale and impact of the problem at hand. The vast majority of users are consumers of pre-compiled kernels, built by People With Clue(tm), who figured this stuff out as soon as it was introduced. The current setup expresses the dependencies as they exist -- OPTIONAL extras, and that is a problem once a year or so, when someone builds their own kernel but must learn this fact anew. There is simply no compelling need at all to change things from the current setup. Our Kconfig system is for people who already know the kernel, not Aunt Tillie. 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: sata & scsi suggestion for make menuconfig
> I can see where you're coming from, but logically, this is wrong. > There's a huge slew of enterprise machines that only have DVD on SATA. ... and enterprise systems don't really care about a few KB more of code. In fact you definitely want to have SATA compiled in in case you need to recover the machine later when the SAN is down. > On the other hand, all of these machines will have SCSI disk devices on > various other transports, so no harm is done, it's just an inelegant > solution. Do you know of a better one? -Andi - 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: sata & scsi suggestion for make menuconfig
On Sat, 2007-09-08 at 18:07 +0200, Andi Kleen wrote: > Folkert van Heusden <[EMAIL PROTECTED]> writes: > > > Hi, > > > > Maybe it is a nice enhancement for make menuconfig to more explicitly > > give a pop-up or so when someone selects for example a sata controller > > while no 'scsi-disk' support was selected? > > This has also bitten me one or two times. A reasonable way would > be to just select SD automatically for !EMBEDDED > > Here's a patch: > > -Andi > > Select BLK_DEV_SD for all SCSI/libata drivers > > This avoid a common user mistake. I can see where you're coming from, but logically, this is wrong. There's a huge slew of enterprise machines that only have DVD on SATA. On the other hand, all of these machines will have SCSI disk devices on various other transports, so no harm is done, it's just an inelegant solution. James - 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: sata & scsi suggestion for make menuconfig
Al Boldi wrote: > Alan Cox wrote: > > > I once sent a patch to make libata a submenu of scsi. > > > > Which is wrong > > > > Nakked-by: Alan Cox <[EMAIL PROTECTED]> > > > > The general comments about moving this stuff around and making it > > clearer what sd/sr etc are nowdays are good but hiding libata under SCSI > > will cause even more confusion than it cures > > That's easy to fix: just change the SCSI heading to include a libata > hint. > > Something like this: > > [PATCH] libata Kconfig: Allow libata to be selected from within the SCSI > submenu > > Move libata Kconfig sourcing from the drivers Kconfig into the SCSI > Kconfig, and change the SCSI menu heading to indicate libata submenu > inclusion. > > This allows the user to quickly select additional disk/tape/cdrom support > from within the same menu. > > Signed-off-by: Al Boldi <[EMAIL PROTECTED]> > Cc: Alan Cox <[EMAIL PROTECTED]> > --- > --- a/drivers/Kconfig 2007-05-02 17:25:30.0 +0300 > +++ b/drivers/Kconfig 2007-08-01 06:33:13.0 +0300 > @@ -22,8 +22,6 @@ source "drivers/ide/Kconfig" > > source "drivers/scsi/Kconfig" > > -source "drivers/ata/Kconfig" > - > source "drivers/cdrom/Kconfig" > > source "drivers/md/Kconfig" > --- a/drivers/scsi/Kconfig 2007-07-09 06:38:37.0 +0300 > +++ b/drivers/scsi/Kconfig 2007-08-01 06:46:42.0 +0300 > @@ -7,6 +7,8 @@ config RAID_ATTRS > ---help--- > Provides RAID > > +source "drivers/ata/Kconfig" > + > config SCSI > - tristate "SCSI device support" > + tristate "SCSI and Libata device support" > depends on BLOCK Actually, this should have read: --- a/drivers/scsi/Kconfig 2007-07-09 06:38:37.0 +0300 +++ a/drivers/scsi/Kconfig 2007-09-09 06:48:11.0 +0300 @@ -1,4 +1,4 @@ -menu "SCSI device support" +menu "SCSI and Libata (SATA/PATA/new IDE) device support" config RAID_ATTRS tristate "RAID Transport Class" @@ -7,6 +7,8 @@ config RAID_ATTRS ---help--- Provides RAID +source "drivers/ata/Kconfig" + config SCSI tristate "SCSI device support" depends on BLOCK I would think that with this minimal change it would make it crystal clear, to anybody who can read, where to enable libata support, and at the same time not to forget/overlook sd/sr selection. Thanks! -- Al - 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: sata & scsi suggestion for make menuconfig
Randy Dunlap wrote: > On Sat, 08 Sep 2007 18:44:46 +0200 Stefan Richter wrote: >> Randy Dunlap wrote: >>> The problem with 'select' here is that it will enable BLK_DEV_SD, >>> but if SCSI is not enabled, it will not become enabled -- i.e., >>> select does not follow the dependency chain. So usually the >>> kernel will not build unless SCSI is enabled by the user. ... >> I checked the dependencies. ATA depends on SCSI (actually, selects >> SCSI), so all is well. Otherwise I would have added more dependencies >> to ATA_SD. > > Ah, that's good, then. Not completely though. Whenever a 'select' is inserted into the dependency graph, the whole thing becomes more fragile WRT future changes. -- Stefan Richter -=-=-=== =--= -=--- http://arcgraph.de/sr/ - 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: sata & scsi suggestion for make menuconfig
Andi Kleen wrote: > On Sat, Sep 08, 2007 at 08:30:06PM +0200, Stefan Richter wrote: >> Andi Kleen wrote: >>> when you've been using CONFIG_IDE before it is not completely >>> obvious you need BLK_SD for your hard disk. >> Switching to different drivers without reading the help text? >> Tough. > > The individual driver descriptions don't say BLK_SD needs to be selected. At least the help to CONFIG_ATA says so. > Besides if all descriptions said that We certainly don't want (too much) redundancy in help texts. > the computer could as well > do it for the user automatically. After all it's a stupid repetive > task and computers are much better at those than humans. In your patch, it is not the computer who finds out that the user wants BLK_SD. It is you who predetermined that the user wants it. -- Stefan Richter -=-=-=== =--= -=--- http://arcgraph.de/sr/ - 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: sata & scsi suggestion for make menuconfig
On Sat, Sep 08, 2007 at 08:30:06PM +0200, Stefan Richter wrote: > Andi Kleen wrote: > > when you've been using CONFIG_IDE before it is not completely > > obvious you need BLK_SD for your hard disk. > > Switching to different drivers without reading the help text? > Tough. The individual driver descriptions don't say BLK_SD needs to be selected. Besides if all descriptions said that the computer could as well do it for the user automatically. After all it's a stupid repetive task and computers are much better at those than humans. -Andi - 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: sata & scsi suggestion for make menuconfig
On Sat, 08 Sep 2007 18:52:35 +0200 Bodo Eggert wrote: > BTW2: I think that menu needs very much reordering. "Block devices" should > be renamed to "Other block devices", AGP support should belong into graphics > support, and many other things I don't even know need to be pushed around. > Even ordering by name would be better than the current situation! But it > should be done by someone knowing these devices, I could only do a part. how's this? for 2.6.16-rc4: consolidated graphics config: http://marc.info/?l=linux-kernel&m=114101236918589&w=2 --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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: sata & scsi suggestion for make menuconfig
Andi Kleen wrote: > when you've been using CONFIG_IDE before it is not completely > obvious you need BLK_SD for your hard disk. Switching to different drivers without reading the help text? Tough. -- Stefan Richter -=-=-=== =--= -=--- http://arcgraph.de/sr/ - 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: sata & scsi suggestion for make menuconfig
Bodo Eggert wrote: > The real problem is hiding devices attached to some controlers between > one kind of the controllers. This has been correct whern they were bus- > specific, but since they are now shared by three busses, they should get > their own menu called "(S)ATA/USB/SCSI attached devices" - or whatever a > native speaker would suggest. A side note: SCSI is not a bus. It is an architecture and a set of implementation standards; including command set standards, transport protocol standards and interconnect standards for a whole lot of different applications, transports, and interconnects, and not all of the latter are actual buses. The oldest of SCSI interconnects, SCSI Parallel Interconnect alias SPI, is often mistaken for all of SCSI even though its role is diminishing. There is much more: http://www.t10.org/scsi-3.htm You are right though that Linux' SCSI command set drivers and SCSI core are used for non-SCSI transports too, and this is not very well reflected by the configuration menu layout. (But is there an ideal menu layout? I'm sure there isn't.) -- Stefan Richter -=-=-=== =--= -=--- http://arcgraph.de/sr/ - 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: sata & scsi suggestion for make menuconfig
> I'd say that someone needs to use a vendor kernel, or at least > begin with a vendor .config file... Vendor kernels tend to compile forever and require initrds. For just testing a kernel quickly compiling only a few drivers in is much more convenient. Also when you've been using CONFIG_IDE before it is not completely obvious you need BLK_SD for your hard disk. -Andi - 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: sata & scsi suggestion for make menuconfig
On Sat, Sep 08, 2007 at 09:50:08AM -0700, Randy Dunlap wrote: > On 08 Sep 2007 18:07:00 +0200 Andi Kleen wrote: > > This has also bitten me one or two times. A reasonable way would > > be to just select SD automatically for !EMBEDDED > > I'd say that someone needs to use a vendor kernel, or at least > begin with a vendor .config file... That's not entirely fair ... if you're switching over from a config you've been dragging around for years which uses IDE rather than ATA, it's far from obvious which config options you need to change. I think Andi's patch is a good one. It might also be good to select SR (at least my wife's laptop has the cd-rom on SATA). -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - 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: sata & scsi suggestion for make menuconfig
Al Boldi <[EMAIL PROTECTED]> wrote: > Alan Cox wrote: >> > I once sent a patch to make libata a submenu of scsi. >> >> Which is wrong >> >> Nakked-by: Alan Cox <[EMAIL PROTECTED]> >> >> The general comments about moving this stuff around and making it clearer >> what sd/sr etc are nowdays are good but hiding libata under SCSI will >> cause even more confusion than it cures > > That's easy to fix: just change the SCSI heading to include a libata hint. I think you're fixing the wrong problem. The real problem is hiding devices attached to some controlers between one kind of the controllers. This has been correct whern they were bus- specific, but since they are now shared by three busses, they should get their own menu called "(S)ATA/USB/SCSI attached devices" - or whatever a native speaker would suggest. Besides that, if I imagine being a semi-novice and searching for IDE support, I would have a hard time finding the IDE menu, and asuming PATA to be non-experimental one day, I'd have a hard time deciding which of the drivers to use. Maybe the SATA-drivers should be put above the old PATA menu, amd maybe both of the titles should include "(E)IDE"? BTW: For CONFIG_ATA, you can replace "(!M32R && !M68K || BROKEN) && (!SUN4 || BROKEN)" with "(!M32R && !M68K && !SUN4 || BROKEN)" BTW2: I think that menu needs very much reordering. "Block devices" should be renamed to "Other block devices", AGP support should belong into graphics support, and many other things I don't even know need to be pushed around. Even ordering by name would be better than the current situation! But it should be done by someone knowing these devices, I could only do a part. -- Top 100 things you don't want the sysadmin to say: 14. Any more trouble from you and your account gets moved to the 750 Friß, Spammer: [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: sata & scsi suggestion for make menuconfig
On Sat, 08 Sep 2007 18:44:46 +0200 Stefan Richter wrote: > Randy Dunlap wrote: > > Stefan Richter wrote: > >> I am not a friend of 'select', but maybe the following actually helps. > ... > > The problem with 'select' here is that it will enable BLK_DEV_SD, > > but if SCSI is not enabled, it will not become enabled -- i.e., > > select does not follow the dependency chain. So usually the > > kernel will not build unless SCSI is enabled by the user. > ... > >> config ATA_SD > >> tristate "SATA/PATA HDD support (via SCSI disk support)" > >> depends on ATA > >> select BLK_DEV_SD > >> help > >> 'SCSI disk support' is required to access SATA HDDs. It is > ... > > I checked the dependencies. ATA depends on SCSI (actually, selects > SCSI), so all is well. Otherwise I would have added more dependencies > to ATA_SD. Ah, that's good, then. Thanks. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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: sata & scsi suggestion for make menuconfig
On 08 Sep 2007 18:07:00 +0200 Andi Kleen wrote: > Folkert van Heusden <[EMAIL PROTECTED]> writes: > > > Hi, > > > > Maybe it is a nice enhancement for make menuconfig to more explicitly > > give a pop-up or so when someone selects for example a sata controller > > while no 'scsi-disk' support was selected? > > This has also bitten me one or two times. A reasonable way would > be to just select SD automatically for !EMBEDDED > > Here's a patch: > > -Andi > > Select BLK_DEV_SD for all SCSI/libata drivers > > This avoid a common user mistake. I'd say that someone needs to use a vendor kernel, or at least begin with a vendor .config file... > Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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: sata & scsi suggestion for make menuconfig
Randy Dunlap wrote: > Stefan Richter wrote: >> I am not a friend of 'select', but maybe the following actually helps. ... > The problem with 'select' here is that it will enable BLK_DEV_SD, > but if SCSI is not enabled, it will not become enabled -- i.e., > select does not follow the dependency chain. So usually the > kernel will not build unless SCSI is enabled by the user. ... >> config ATA_SD >> tristate "SATA/PATA HDD support (via SCSI disk support)" >> depends on ATA >> select BLK_DEV_SD >> help >> 'SCSI disk support' is required to access SATA HDDs. It is ... I checked the dependencies. ATA depends on SCSI (actually, selects SCSI), so all is well. Otherwise I would have added more dependencies to ATA_SD. -- Stefan Richter -=-=-=== =--= -=--- http://arcgraph.de/sr/ - 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: sata & scsi suggestion for make menuconfig
Stefan Richter wrote:
(added Cc linux-ide)
Folkert van Heusden wrote:
A popup makes some sense, but I don't know if menuconfig knows how to
do popup warnings... and it needs to be done for all *configs,
not just menuconfig.
Maybe add a new type?
How about
comment "Note: 'SCSI disk support' is required for SATA/PATA HDDs!"
depends on ATA && !BLK_DEV_SD
Yes! Maybe create some status-line at the bottom of the screen in which
these hints scrollby. Like powertop does.
'comment' is already supported by make {menu,x,g}config and AFAIK by
make oldconfig too. It is not effective in make oldconfig though
because it will scroll off the screen quickly.
I am not a friend of 'select', but maybe the following actually helps.
I didn't follow all of this and previous related discussions, so I guess
somebody else suggested something like this before:
The problem with 'select' here is that it will enable BLK_DEV_SD,
but if SCSI is not enabled, it will not become enabled -- i.e.,
select does not follow the dependency chain. So usually the
kernel will not build unless SCSI is enabled by the user.
# drivers/ata/Kconfig
config ATA
[...]
comment "Controller drivers"
[...low-level drivers go here...]
comment "Storage device drivers"
config ATA_SD
tristate "SATA/PATA HDD support (via SCSI disk support)"
depends on ATA
select BLK_DEV_SD
help
'SCSI disk support' is required to access SATA HDDs. It is
also necessary for parallel ATA (IDE) HDDs if you use the
experimental parallel ATA option.
You can say Y or M here to select SCSI disk support, or you
can do so in the 'SCSI device support' section.
[...ditto for CD/DVD-ROMs, tapes, and generic support...]
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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: sata & scsi suggestion for make menuconfig
On Sep 8 2007 17:03, Al Boldi wrote: >Alan Cox wrote: >> > I once sent a patch to make libata a submenu of scsi. >> >> Which is wrong >> >> Nakked-by: Alan Cox <[EMAIL PROTECTED]> >> >> The general comments about moving this stuff around and making it clearer >> what sd/sr etc are nowdays are good but hiding libata under SCSI will >> cause even more confusion than it cures > >That's easy to fix: just change the SCSI heading to include a libata hint. Let's not. I am perfectly fine with how things currently are, plus optionally Stefan Richter's suggestion. Jan -- - 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: sata & scsi suggestion for make menuconfig
Folkert van Heusden <[EMAIL PROTECTED]> writes: > Hi, > > Maybe it is a nice enhancement for make menuconfig to more explicitly > give a pop-up or so when someone selects for example a sata controller > while no 'scsi-disk' support was selected? This has also bitten me one or two times. A reasonable way would be to just select SD automatically for !EMBEDDED Here's a patch: -Andi Select BLK_DEV_SD for all SCSI/libata drivers This avoid a common user mistake. Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> Index: linux-2.6.23-rc1-misc/drivers/ata/Kconfig === --- linux-2.6.23-rc1-misc.orig/drivers/ata/Kconfig +++ linux-2.6.23-rc1-misc/drivers/ata/Kconfig @@ -42,6 +42,7 @@ config ATA_ACPI config SATA_AHCI tristate "AHCI SATA support" + select BLK_DEV_SD if !EMBEDDED depends on PCI help This option enables support for AHCI Serial ATA. @@ -50,6 +51,7 @@ config SATA_AHCI config SATA_SVW tristate "ServerWorks Frodo / Apple K2 SATA support" + select BLK_DEV_SD if !EMBEDDED depends on PCI help This option enables support for Broadcom/Serverworks/Apple K2 @@ -59,6 +61,7 @@ config SATA_SVW config ATA_PIIX tristate "Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support" + select BLK_DEV_SD if !EMBEDDED depends on PCI help This option enables support for ICH5/6/7/8 Serial ATA @@ -69,6 +72,7 @@ config ATA_PIIX config SATA_MV tristate "Marvell SATA support (HIGHLY EXPERIMENTAL)" + select BLK_DEV_SD if !EMBEDDED depends on PCI && EXPERIMENTAL help This option enables support for the Marvell Serial ATA family. @@ -78,6 +82,7 @@ config SATA_MV config SATA_NV tristate "NVIDIA SATA support" + select BLK_DEV_SD if !EMBEDDED depends on PCI help This option enables support for NVIDIA Serial ATA. @@ -86,6 +91,7 @@ config SATA_NV config PDC_ADMA tristate "Pacific Digital ADMA support" + select BLK_DEV_SD if !EMBEDDED depends on PCI help This option enables support for Pacific Digital ADMA controllers @@ -94,6 +100,7 @@ config PDC_ADMA config SATA_QSTOR tristate "Pacific Digital SATA QStor support" + select BLK_DEV_SD if !EMBEDDED depends on PCI help This option enables support for Pacific Digital Serial ATA QStor. @@ -102,6 +109,7 @@ config SATA_QSTOR config SATA_PROMISE tristate "Promise SATA TX2/TX4 support" + select BLK_DEV_SD if !EMBEDDED depends on PCI help This option enables support for Promise Serial ATA TX2/TX4. @@ -110,6 +118,7 @@ config SATA_PROMISE config SATA_SX4 tristate "Promise SATA SX4 support" + select BLK_DEV_SD if !EMBEDDED depends on PCI && EXPERIMENTAL help This option enables support for Promise Serial ATA SX4. @@ -118,6 +127,7 @@ config SATA_SX4 config SATA_SIL tristate "Silicon Image SATA support" + select BLK_DEV_SD if !EMBEDDED depends on PCI help This option enables support for Silicon Image Serial ATA. @@ -126,6 +136,7 @@ config SATA_SIL config SATA_SIL24 tristate "Silicon Image 3124/3132 SATA support" + select BLK_DEV_SD if !EMBEDDED depends on PCI help This option enables support for Silicon Image 3124/3132 Serial ATA. @@ -134,6 +145,7 @@ config SATA_SIL24 config SATA_SIS tristate "SiS 964/965/966/180 SATA support" + select BLK_DEV_SD if !EMBEDDED depends on PCI select PATA_SIS help @@ -145,6 +157,7 @@ config SATA_SIS config SATA_ULI tristate "ULi Electronics SATA support" + select BLK_DEV_SD if !EMBEDDED depends on PCI help This option enables support for ULi Electronics SATA. @@ -153,6 +166,7 @@ config SATA_ULI config SATA_VIA tristate "VIA SATA support" + select BLK_DEV_SD if !EMBEDDED depends on PCI help This option enables support for VIA Serial ATA. @@ -161,6 +175,7 @@ config SATA_VIA config SATA_VITESSE tristate "VITESSE VSC-7174 / INTEL 31244 SATA support" + select BLK_DEV_SD if !EMBEDDED depends on PCI help This option enables support for Vitesse VSC7174 and Intel 31244 Serial ATA. @@ -169,12 +184,14 @@ config SATA_VITESSE config SATA_INIC162X tristate "Initio 162x SATA support (HIGHLY EXPERIMENTAL)" + select BLK_DEV_SD if !EMBEDDED depends on PCI && EXPERIMENTAL help This option enables support for Initio 162x Serial ATA. config PATA_ALI tristate "ALi PATA support (Experimental)" + select BLK_DEV_SD if !EMBEDDED depends on PCI && EXPERIMENTAL help This option enables support for the ALi ATA interfaces @@ -184,6
Re: sata & scsi suggestion for make menuconfig
Alan Cox wrote: > > I once sent a patch to make libata a submenu of scsi. > > Which is wrong > > Nakked-by: Alan Cox <[EMAIL PROTECTED]> > > The general comments about moving this stuff around and making it clearer > what sd/sr etc are nowdays are good but hiding libata under SCSI will > cause even more confusion than it cures That's easy to fix: just change the SCSI heading to include a libata hint. Something like this: [PATCH] libata Kconfig: Allow libata to be selected from within the SCSI submenu Move libata Kconfig sourcing from the drivers Kconfig into the SCSI Kconfig, and change the SCSI menu heading to indicate libata submenu inclusion. This allows the user to quickly select additional disk/tape/cdrom support from within the same menu. Signed-off-by: Al Boldi <[EMAIL PROTECTED]> Cc: Alan Cox <[EMAIL PROTECTED]> --- --- a/drivers/Kconfig 2007-05-02 17:25:30.0 +0300 +++ b/drivers/Kconfig 2007-08-01 06:33:13.0 +0300 @@ -22,8 +22,6 @@ source "drivers/ide/Kconfig" source "drivers/scsi/Kconfig" -source "drivers/ata/Kconfig" - source "drivers/cdrom/Kconfig" source "drivers/md/Kconfig" --- a/drivers/scsi/Kconfig 2007-07-09 06:38:37.0 +0300 +++ b/drivers/scsi/Kconfig 2007-08-01 06:46:42.0 +0300 @@ -7,6 +7,8 @@ config RAID_ATTRS ---help--- Provides RAID +source "drivers/ata/Kconfig" + config SCSI - tristate "SCSI device support" + tristate "SCSI and Libata device support" depends on BLOCK Thanks! -- Al - 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: sata & scsi suggestion for make menuconfig
> I once sent a patch to make libata a submenu of scsi. Which is wrong Nakked-by: Alan Cox <[EMAIL PROTECTED]> The general comments about moving this stuff around and making it clearer what sd/sr etc are nowdays are good but hiding libata under SCSI will cause even more confusion than it cures - 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: sata & scsi suggestion for make menuconfig
On Fri, Sep 07, 2007 at 08:35:22AM -0700, Randy Dunlap wrote: > On Fri, 7 Sep 2007 14:48:00 +0200 Folkert van Heusden wrote: > > > Hi, > > > > Maybe it is a nice enhancement for make menuconfig to more explicitly > > give a pop-up or so when someone selects for example a sata controller > > while no 'scsi-disk' support was selected? > > I know that it's difficult to get people to read docs & help text, > and maybe it is needed in more places, but CONFIG_ATA (SATA/PATA) > help text says: > > NOTE: ATA enables basic SCSI support; *however*, > 'SCSI disk support', 'SCSI tape support', or > 'SCSI CDROM support' may also be needed, > depending on your hardware configuration. > > > A popup makes some sense, but I don't know if menuconfig knows how to > do popup warnings... and it needs to be done for all *configs, > not just menuconfig. For menuconfig I would much rather see that it had an additional window at the bottom displaying the help text for the active menu line. Implementing support for a pop-up in the kconfig language seems to be a bit off the purpose of the kconfig language. Sam - 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: sata & scsi suggestion for make menuconfig
Jan Engelhardt wrote: > On Sep 8 2007 09:05, Stefan Richter wrote: >> config ATA_SD >> tristate "SATA/PATA HDD support (via SCSI disk support)" >> depends on ATA >> select BLK_DEV_SD >> help >>'SCSI disk support' is required to access SATA HDDs. It is [...] >>You can say Y or M here to select SCSI disk support, or you >>can do so in the 'SCSI device support' section. [...] > And what uses ATA_SD, or is the user supposed to manually enable it? It is merely there to produce the prompt which people asked for. CONFIG_ATA_SD (or CONFIG_ATA_BLK_DEV_SD or whatever) won't turn up in any Makefile or source code. Note, I'm not fond of 'select' nor of dummy Kconfig variables. Plus I can personally live very well with the current solution (sd_mod et al are mentioned in the help text at CONFIG_ATA). That's why I posted only the example instead of a complete patch. -- Stefan Richter -=-=-=== =--= -=--- http://arcgraph.de/sr/ - 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: sata & scsi suggestion for make menuconfig
On Sep 8 2007 09:05, Stefan Richter wrote: >config ATA > [...] > >comment "Controller drivers" > >[...low-level drivers go here...] > >comment "Storage device drivers" > >config ATA_SD > tristate "SATA/PATA HDD support (via SCSI disk support)" > depends on ATA > select BLK_DEV_SD > help > 'SCSI disk support' is required to access SATA HDDs. It is > also necessary for parallel ATA (IDE) HDDs if you use the > experimental parallel ATA option. > > You can say Y or M here to select SCSI disk support, or you > can do so in the 'SCSI device support' section. > >[...ditto for CD/DVD-ROMs, tapes, and generic support...] And what uses ATA_SD, or is the user supposed to manually enable it? Jan -- - 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: sata & scsi suggestion for make menuconfig
On Sep 8 2007 01:02, Jan Engelhardt wrote: >On Sep 7 2007 21:38, Krzysztof Halasa wrote: >>> Ok, but that's not the most common situaties. What I'm suggesting is a >>> warning or a please note popup. Not neccessarily an error or refusing to >>> continue thing. >> >>What IMHO makes sense is changing all references to SCSI CDROM, >>SCSI DISK etc. to just CDROM, DISK, and changing SCSI (menu) to >>something like MASS STORAGE. > >There is still too much SCSI in it IMO :-) And to explain that point: SCSI device name inquiry is limited to 16 bytes. That may be a limitation of SCSI (as in: the protocol), but the SCSI *subsystem* should not impose such a tight limit. Jan -- - 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: sata & scsi suggestion for make menuconfig
(added Cc linux-ide)
Folkert van Heusden wrote:
A popup makes some sense, but I don't know if menuconfig knows how to
do popup warnings... and it needs to be done for all *configs,
not just menuconfig.
>>> Maybe add a new type?
>> How about
>> comment "Note: 'SCSI disk support' is required for SATA/PATA HDDs!"
>> depends on ATA && !BLK_DEV_SD
>
> Yes! Maybe create some status-line at the bottom of the screen in which
> these hints scrollby. Like powertop does.
'comment' is already supported by make {menu,x,g}config and AFAIK by
make oldconfig too. It is not effective in make oldconfig though
because it will scroll off the screen quickly.
I am not a friend of 'select', but maybe the following actually helps.
I didn't follow all of this and previous related discussions, so I guess
somebody else suggested something like this before:
# drivers/ata/Kconfig
config ATA
[...]
comment "Controller drivers"
[...low-level drivers go here...]
comment "Storage device drivers"
config ATA_SD
tristate "SATA/PATA HDD support (via SCSI disk support)"
depends on ATA
select BLK_DEV_SD
help
'SCSI disk support' is required to access SATA HDDs. It is
also necessary for parallel ATA (IDE) HDDs if you use the
experimental parallel ATA option.
You can say Y or M here to select SCSI disk support, or you
can do so in the 'SCSI device support' section.
[...ditto for CD/DVD-ROMs, tapes, and generic support...]
--
Stefan Richter
-=-=-=== =--= -=---
http://arcgraph.de/sr/
-
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: sata & scsi suggestion for make menuconfig
Krzysztof Halasa wrote: >> Ok, but that's not the most common situaties. What I'm suggesting is a >> warning or a please note popup. Not neccessarily an error or refusing to >> continue thing. > >What IMHO makes sense is changing all references to SCSI CDROM, >SCSI DISK etc. to just CDROM, DISK, and changing SCSI (menu) to >something like MASS STORAGE. I once sent a patch to make libata a submenu of scsi. [PATCH] libata Kconfig: Allow libata to be selected from within the SCSI submenu From: Al Boldi <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: Alan Cox <[EMAIL PROTECTED]>, linux-kernel@vger.kernel.org Date: 08/01/07 07:22 am Move libata Kconfig sourcing from the drivers Kconfig into the SCSI Kconfig. This allows the user to quickly select additional disk/tape/cdrom support from within the same menu. Signed-off-by: Al Boldi <[EMAIL PROTECTED]> Cc: Alan Cox <[EMAIL PROTECTED]> --- --- a/drivers/Kconfig 2007-05-02 17:25:30.0 +0300 +++ b/drivers/Kconfig 2007-08-01 06:33:13.0 +0300 @@ -22,8 +22,6 @@ source "drivers/ide/Kconfig" source "drivers/scsi/Kconfig" -source "drivers/ata/Kconfig" - source "drivers/cdrom/Kconfig" source "drivers/md/Kconfig" --- a/drivers/scsi/Kconfig 2007-07-09 06:38:37.0 +0300 +++ b/drivers/scsi/Kconfig 2007-08-01 06:46:42.0 +0300 @@ -7,6 +7,8 @@ config RAID_ATTRS ---help--- Provides RAID +source "drivers/ata/Kconfig" + config SCSI tristate "SCSI device support" depends on BLOCK Thanks! -- Al - 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: sata & scsi suggestion for make menuconfig
> >> I know that it's difficult to get people to read docs & help text, > >> and maybe it is needed in more places, but CONFIG_ATA (SATA/PATA) > >> help text says: > >> NOTE: ATA enables basic SCSI support; *however*, > >> 'SCSI disk support', 'SCSI tape support', or > >> 'SCSI CDROM support' may also be needed, > >> depending on your hardware configuration. > > > > Yes but that would mean that you have to open the help for each item > > that you add. > > > >> A popup makes some sense, but I don't know if menuconfig knows how to > >> do popup warnings... and it needs to be done for all *configs, > >> not just menuconfig. > > > > Maybe add a new type? > > How about > comment "Note: 'SCSI disk support' is required for SATA/PATA HDDs!" > depends on ATA && !BLK_DEV_SD Yes! Maybe create some status-line at the bottom of the screen in which these hints scrollby. Like powertop does. Folkert van Heusden -- MultiTail är en flexibel redskap för att fälja logfilar, utför av commandoer, filtrera, ge färg, sammanfoga, o.s.v. följa. http://www.vanheusden.com/multitail/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.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: sata & scsi suggestion for make menuconfig
On Sep 7 2007 21:38, Krzysztof Halasa wrote: >> Ok, but that's not the most common situaties. What I'm suggesting is a >> warning or a please note popup. Not neccessarily an error or refusing to >> continue thing. > >What IMHO makes sense is changing all references to SCSI CDROM, >SCSI DISK etc. to just CDROM, DISK, and changing SCSI (menu) to >something like MASS STORAGE. There is still too much SCSI in it IMO :-) - 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: sata & scsi suggestion for make menuconfig
Folkert van Heusden <[EMAIL PROTECTED]> writes: > Ok, but that's not the most common situaties. What I'm suggesting is a > warning or a please note popup. Not neccessarily an error or refusing to > continue thing. What IMHO makes sense is changing all references to SCSI CDROM, SCSI DISK etc. to just CDROM, DISK, and changing SCSI (menu) to something like MASS STORAGE. -- Krzysztof Halasa - 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: sata & scsi suggestion for make menuconfig
Folkert van Heusden wrote: >> I know that it's difficult to get people to read docs & help text, >> and maybe it is needed in more places, but CONFIG_ATA (SATA/PATA) >> help text says: >> NOTE: ATA enables basic SCSI support; *however*, >> 'SCSI disk support', 'SCSI tape support', or >> 'SCSI CDROM support' may also be needed, >> depending on your hardware configuration. > > Yes but that would mean that you have to open the help for each item > that you add. > >> A popup makes some sense, but I don't know if menuconfig knows how to >> do popup warnings... and it needs to be done for all *configs, >> not just menuconfig. > > Maybe add a new type? How about comment "Note: 'SCSI disk support' is required for SATA/PATA HDDs!" depends on ATA && !BLK_DEV_SD -- Stefan Richter -=-=-=== =--= --=== http://arcgraph.de/sr/ - 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: sata & scsi suggestion for make menuconfig
> > Maybe it is a nice enhancement for make menuconfig to more explicitly > > give a pop-up or so when someone selects for example a sata controller > > while no 'scsi-disk' support was selected? > > I know that it's difficult to get people to read docs & help text, > and maybe it is needed in more places, but CONFIG_ATA (SATA/PATA) > help text says: > NOTE: ATA enables basic SCSI support; *however*, > 'SCSI disk support', 'SCSI tape support', or > 'SCSI CDROM support' may also be needed, > depending on your hardware configuration. Yes but that would mean that you have to open the help for each item that you add. > A popup makes some sense, but I don't know if menuconfig knows how to > do popup warnings... and it needs to be done for all *configs, > not just menuconfig. Maybe add a new type? Folkert van Heusden -- MultiTail na wan makriki wrokosani fu tan luku den logfile nanga san den commando spiti puru. Piki puru spesrutu sani, wroko nanga difreti kroru, tja kon makandra, nanga wan lo moro. http://www.vanheusden.com/multitail/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.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: sata & scsi suggestion for make menuconfig
On Fri, 7 Sep 2007 14:48:00 +0200 Folkert van Heusden wrote: > Hi, > > Maybe it is a nice enhancement for make menuconfig to more explicitly > give a pop-up or so when someone selects for example a sata controller > while no 'scsi-disk' support was selected? I know that it's difficult to get people to read docs & help text, and maybe it is needed in more places, but CONFIG_ATA (SATA/PATA) help text says: NOTE: ATA enables basic SCSI support; *however*, 'SCSI disk support', 'SCSI tape support', or 'SCSI CDROM support' may also be needed, depending on your hardware configuration. A popup makes some sense, but I don't know if menuconfig knows how to do popup warnings... and it needs to be done for all *configs, not just menuconfig. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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: sata & scsi suggestion for make menuconfig
> >Maybe it is a nice enhancement for make menuconfig to more explicitly > >give a pop-up or so when someone selects for example a sata controller > >while no 'scsi-disk' support was selected? > > Having no sd support is perfectly valid. Imagine a diskless boot > with only sr support. Ok, but that's not the most common situaties. What I'm suggesting is a warning or a please note popup. Not neccessarily an error or refusing to continue thing. Folkert van Heusden -- www.vanheusden.com/multitail - win een vlaai van multivlaai! zorg ervoor dat multitail opgenomen wordt in Fedora Core, AIX, Solaris of HP/UX en win een vlaai naar keuze -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.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: sata & scsi suggestion for make menuconfig
On Sep 7 2007 14:48, Folkert van Heusden wrote: > >Maybe it is a nice enhancement for make menuconfig to more explicitly >give a pop-up or so when someone selects for example a sata controller >while no 'scsi-disk' support was selected? Having no sd support is perfectly valid. Imagine a diskless boot with only sr support. - 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/
sata & scsi suggestion for make menuconfig
Hi, Maybe it is a nice enhancement for make menuconfig to more explicitly give a pop-up or so when someone selects for example a sata controller while no 'scsi-disk' support was selected? Folkert van Heusden -- Multi tail barnamaj mowahib li mora9abat attasjilat wa nataij awamir al 7asoub. damj, talwin, mora9abat attarchi7 wa ila akhirih. http://www.vanheusden.com/multitail/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.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/
