Re: [RFC PATCH] SCSI: split Kconfig menu into two
Maciej W. Rozycki wrote: SCSI is a generic peripheral bus No, not anymore. http://www.t10.org/scsi-3.htm (recall the expansion of the acronym). The expansion of the acronym doesn't fit anymore to what SCSI is today, or even to what it became already circa 10 years ago. Even though probably the most common, storage is one of its applications only (think scanners for an immediately obvious other one). I find describing CONFIG_SCSI as storage support misleading and inappropriate. Right. I wrote that in lack of better words, but at least I added SCSI commands in parentheses. Something like SCSI I/O - core and command sets would much better describe what it is, but it would put SCSI first again and thus wouldn't reflect that Linux' SCSI core and highlevel is in broader use than just for actual SCSI hardware... Of course there is no way around the issue that Linux' SCSI core's and highlevel's role cannot be characterized in 3...6 words only, but there should be a way to point out its general importance. Referring to your example it is like calling generic networking (i.e. CONFIG_NET) Ethernet support. Wrong comparison. -- Stefan Richter -=-=-=== =--= =---= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] SCSI: split Kconfig menu into two
On Sat, Sep 15, 2007 at 06:23:13PM +0200, Adrian Bunk wrote: @Greg: Do you have any numbers regarding how your Linux Kernel in a Nutshell is selling? It is selling reasonably well for an O'Reilly book from what I have been told. But I have not seen any real numbers yet. Even download numbers? The downloads are spread around all of the kernel.org mirrors so I have absolutely no idea what they are. Nor do I really want to, as it doesn't matter to me. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] SCSI: split Kconfig menu into two
On Fri, Sep 14, 2007 at 10:01:18PM +0200, Stefan Richter wrote: On 14 Sep, Adrian Bunk wrote: On Fri, Sep 14, 2007 at 09:00:33PM +0200, Sam Ravnborg wrote: Hi Stefan. Such a patch really calls for some minimal unifacation among the architectures. arch/alpha/Kconfig|2 arch/arm/Kconfig |2 arch/avr32/Kconfig|2 arch/blackfin/Kconfig |2 arch/cris/Kconfig |2 arch/frv/Kconfig |2 arch/i386/Kconfig |2 arch/ia64/Kconfig |2 arch/m32r/Kconfig |2 arch/m68k/Kconfig |2 arch/m68knommu/Kconfig|2 arch/mips/Kconfig |2 arch/parisc/Kconfig |2 arch/powerpc/Kconfig |2 arch/ppc/Kconfig |2 arch/s390/Kconfig |2 arch/sh/Kconfig |2 arch/sh64/Kconfig |2 arch/sparc/Kconfig|2 arch/sparc64/Kconfig |2 arch/um/Kconfig |2 arch/v850/Kconfig |2 arch/x86_64/Kconfig |4 arch/xtensa/Kconfig |2 Exactly the same change for all architectures. IT would be good to introduce a common file that contains some of the shared stuff from the different architectures. We could start out simple with: arch/Kconfig.arch: ... Yes, that would be good. But Adrian has a point too. Stefan simply shouldn't move it out of drivers/Kconfig. ... drivers/Kconfig |4 drivers/scsi/Kconfig | 1589 -- drivers/scsi/Kconfig.lowlevel | 1578 + 3 files changed, 1588 insertions(+), 1583 deletions(-) Nearly right. ;-) There are a few architectures not (yet) using drivers/Kconfig. Index: linux-2.6.23-rc6/drivers/Kconfig === --- linux-2.6.23-rc6.orig/drivers/Kconfig +++ linux-2.6.23-rc6/drivers/Kconfig @@ -1,5 +1,7 @@ # drivers/Kconfig +source drivers/scsi/Kconfig + menu Device Drivers source drivers/base/Kconfig @@ -22,7 +24,7 @@ source drivers/misc/Kconfig source drivers/ide/Kconfig -source drivers/scsi/Kconfig +source drivers/scsi/Kconfig.lowlevel source drivers/ata/Kconfig ... This way the order is wrong: There should first be the lowlevel SCSI, SATA, USB etc. drivers, these drivers should select CONFIG_SCSI, and then the menu offering support for disk, CD,... Index: linux-2.6.23-rc6/drivers/scsi/Kconfig === --- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig +++ linux-2.6.23-rc6/drivers/scsi/Kconfig @@ -1,14 +1,7 @@ -menu SCSI device support - -config RAID_ATTRS - tristate RAID Transport Class - default n - depends on BLOCK - ---help--- - Provides RAID +menu Storage (core and SCSI commands) config SCSI - tristate SCSI device support + tristate Storage support (core and SCSI commands) depends on BLOCK select SCSI_DMA if HAS_DMA ---help--- ... What is storage support? SATA? PATA? USB mass storage? MMC? MTD? Whether or not a driver uses the SCSI layer is an implementation detail (it even differs for the two USB mass storage implementations and the two PATA implementations in the kernel) the user shouldn't have to know about. I don't see any reason why CONFIG_SCSI should have to stay user-visible at all after your patch. 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-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] SCSI: split Kconfig menu into two
Adrian Bunk wrote: On Fri, Sep 14, 2007 at 10:01:18PM +0200, Stefan Richter wrote: drivers/Kconfig |4 drivers/scsi/Kconfig | 1589 -- drivers/scsi/Kconfig.lowlevel | 1578 + 3 files changed, 1588 insertions(+), 1583 deletions(-) Nearly right. ;-) There are a few architectures not (yet) using drivers/Kconfig. Right, the patch is wrong for those architectures which include drivers/scsi/Kconfig directly, rather than indirectly via drivers/Kconfig. [...] # drivers/Kconfig +source drivers/scsi/Kconfig + menu Device Drivers source drivers/base/Kconfig @@ -22,7 +24,7 @@ source drivers/misc/Kconfig source drivers/ide/Kconfig -source drivers/scsi/Kconfig +source drivers/scsi/Kconfig.lowlevel source drivers/ata/Kconfig ... This way the order is wrong: There should first be the lowlevel SCSI, SATA, USB etc. drivers, these drivers should select CONFIG_SCSI, and then the menu offering support for disk, CD,... The order was inspired by # the protocols etc. Networking # the interconnects Device Drivers/ Network device support So that order is wrong too? However, there is also precedence for the order which you suggest: The partition and filesystems options come after device driver options. [...] +menu Storage (core and SCSI commands) config SCSI -tristate SCSI device support +tristate Storage support (core and SCSI commands) depends on BLOCK select SCSI_DMA if HAS_DMA ---help--- ... What is storage support? SATA? PATA? USB mass storage? MMC? MTD? What is Networking? Ethernet? Infiniband? ...? Whether or not a driver uses the SCSI layer is an implementation detail (it even differs for the two USB mass storage implementations and the two PATA implementations in the kernel) the user shouldn't have to know about. I don't see any reason why CONFIG_SCSI should have to stay user-visible at all after your patch. Vice versa, I don't see any reason for select SCSI anywhere after my patch. -- Stefan Richter -=-=-=== =--= - http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] SCSI: split Kconfig menu into two
On Sat, Sep 15, 2007 at 02:24:17PM +0200, Stefan Richter wrote: Adrian Bunk wrote: ... # drivers/Kconfig +source drivers/scsi/Kconfig + menu Device Drivers source drivers/base/Kconfig @@ -22,7 +24,7 @@ source drivers/misc/Kconfig source drivers/ide/Kconfig -source drivers/scsi/Kconfig +source drivers/scsi/Kconfig.lowlevel source drivers/ata/Kconfig ... This way the order is wrong: There should first be the lowlevel SCSI, SATA, USB etc. drivers, these drivers should select CONFIG_SCSI, and then the menu offering support for disk, CD,... The order was inspired by # the protocols etc. Networking # the interconnects Device Drivers/ Network device support So that order is wrong too? It's different since _all_ network device drivers require networking support. However, there is also precedence for the order which you suggest: The partition and filesystems options come after device driver options. [...] +menu Storage (core and SCSI commands) config SCSI - tristate SCSI device support + tristate Storage support (core and SCSI commands) depends on BLOCK select SCSI_DMA if HAS_DMA ---help--- ... What is storage support? SATA? PATA? USB mass storage? MMC? MTD? What is Networking? Ethernet? Infiniband? ...? Different to CONFIG_SCSI, CONFIG_NET=n is so exotic that we should change it to no longer show users the question unless CONFIG_EMBEDDED=y. Whether or not a driver uses the SCSI layer is an implementation detail (it even differs for the two USB mass storage implementations and the two PATA implementations in the kernel) the user shouldn't have to know about. I don't see any reason why CONFIG_SCSI should have to stay user-visible at all after your patch. Vice versa, I don't see any reason for select SCSI anywhere after my patch. If users who don't need it now enable CONFIG_SCSI (and drivers/ide/ usage is not that uncommon) that's a regression in the user interface. If the lowlevel SCSI drivers move into a separate menu as your patch does, we simply no longer have any good reason for bothering the user with the CONFIG_SCSI. 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-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] SCSI: split Kconfig menu into two
Adrian Bunk wrote: There should first be the lowlevel SCSI, SATA, USB etc. drivers, these drivers should select CONFIG_SCSI, and then the menu offering support for disk, CD,... ... If users who don't need it now enable CONFIG_SCSI (and drivers/ide/ usage is not that uncommon) that's a regression in the user interface. Aha, first all interconnects/transports are configured. If none of them 'select'ed SCSI, the menu for sd, sr, st stays invisible. Otherwise it is exposed. It still doesn't entirely clarify whether users need sd, sr, st, and whether thy need sd for the disk with root filesystem. -- Stefan Richter -=-=-=== =--= - http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] SCSI: split Kconfig menu into two
On Sat, Sep 15, 2007 at 03:20:06PM +0200, Stefan Richter wrote: Adrian Bunk wrote: There should first be the lowlevel SCSI, SATA, USB etc. drivers, these drivers should select CONFIG_SCSI, and then the menu offering support for disk, CD,... ... If users who don't need it now enable CONFIG_SCSI (and drivers/ide/ usage is not that uncommon) that's a regression in the user interface. Aha, first all interconnects/transports are configured. If none of them 'select'ed SCSI, the menu for sd, sr, st stays invisible. Otherwise it is exposed. It still doesn't entirely clarify whether users need sd, sr, st, and whether thy need sd for the disk with root filesystem. If you want to do it in a really perfect way, help texts aren't the solution. You'll have to make the options like CONFIG_BLK_DEV_SR no longer be user visible and select'ed through dummy options like e.g.: config USB_STORAGE tristate USB Mass Storage support depends on USB select SCSI help ... config USB_STORAGE_SD tristate USB Mass Storage hard disk support depends on USB_STORAGE select BLK_DEV_SD help ... config USB_STORAGE_SR tristate USB Mass Storage CD/DVD support depends on USB_STORAGE select BLK_DEV_SR help ... 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-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] SCSI: split Kconfig menu into two
Adrian Bunk wrote: On Sat, Sep 15, 2007 at 03:20:06PM +0200, Stefan Richter wrote: It still doesn't entirely clarify whether users need sd, sr, st, and whether thy need sd for the disk with root filesystem. If you want to do it in a really perfect way, help texts aren't the solution. You'll have to make the options like CONFIG_BLK_DEV_SR no longer be user visible and select'ed through dummy options like e.g.: ... tristate USB Mass Storage hard disk support depends on USB_STORAGE select BLK_DEV_SD ... tristate USB Mass Storage CD/DVD support depends on USB_STORAGE select BLK_DEV_SR ... Perfect is in the eye of the beholder. You would consequently have to add such options into all menus which contain scsi low-level providers. Also, one more question on whether CONFIG_SCSI ought to be 'select'ed: Where do scsi-core options like CONFIG_SCSI_CONSTANTS go? -- Stefan Richter -=-=-=== =--= - http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] SCSI: split Kconfig menu into two
On Sat, Sep 15, 2007 at 04:11:45PM +0200, Stefan Richter wrote: Adrian Bunk wrote: On Sat, Sep 15, 2007 at 03:20:06PM +0200, Stefan Richter wrote: It still doesn't entirely clarify whether users need sd, sr, st, and whether thy need sd for the disk with root filesystem. If you want to do it in a really perfect way, help texts aren't the solution. You'll have to make the options like CONFIG_BLK_DEV_SR no longer be user visible and select'ed through dummy options like e.g.: ... tristate USB Mass Storage hard disk support depends on USB_STORAGE select BLK_DEV_SD ... tristate USB Mass Storage CD/DVD support depends on USB_STORAGE select BLK_DEV_SR ... Perfect is in the eye of the beholder. You would consequently have to add such options into all menus which contain scsi low-level providers. Kconfig is a user interface, so perfect is what is best for the kconfig users. Also, one more question on whether CONFIG_SCSI ought to be 'select'ed: Where do scsi-core options like CONFIG_SCSI_CONSTANTS go? The first question is whether it's for actual SCSI hardware [1] or for the block layer functionality which the SCSI subsystem has become. The mixture of these two is the root of much user confusion. With the help text The error messages regarding your SCSI hardware will be easier to understand if you say Y here a user wouldn't have expected to see you using it in a firewire driver. But unless I miss anything, the setting of SCSI_SCAN_ASYNC does only affect real SCSI hardware. If you check each option and place it either in the generic storage menu or the SCSI lowlevel menu this would fix much possible user confusion. But these are relatively unimportant options compared to e.g. USB_STORAGE=y, BLK_DEV_SD=n, which is a misconfiguration many users run into, so having one menu somewhere with these advanced options should be enough. Stefan Richter cu Adrian [1] SCSI as in sold as SCSI -- 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-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] SCSI: split Kconfig menu into two
Adrian Bunk wrote: On Sat, Sep 15, 2007 at 04:11:45PM +0200, Stefan Richter wrote: Perfect is in the eye of the beholder. You would consequently have to add such options into all menus which contain scsi low-level providers. Kconfig is a user interface, so perfect is what is best for the kconfig users. Duplicate options with different names in different menus, but which all do the same, --- is this the best for users? Also, one more question on whether CONFIG_SCSI ought to be 'select'ed: Where do scsi-core options like CONFIG_SCSI_CONSTANTS go? The first question is whether it's for actual SCSI hardware [1] or for the block layer functionality which the SCSI subsystem has become. The mixture of these two is the root of much user confusion. With the help text The error messages regarding your SCSI hardware will be easier to understand if you say Y here a user wouldn't have expected to see you using it in a firewire driver. FireWire hardware which implements SBP-2 is SCSI hardware... But this detail aside --- yes, of course this help text is old and misleading. But unless I miss anything, the setting of SCSI_SCAN_ASYNC does only affect real SCSI hardware. It affects every hardware which is driven by scsi low-level providers which have been integrated with the SCSI_SCAN_ASYNC facility. If you check each option and place it either in the generic storage menu or the SCSI lowlevel menu this would fix much possible user confusion. But these are relatively unimportant options compared to e.g. USB_STORAGE=y, BLK_DEV_SD=n, which is a misconfiguration many users run into, so having one menu somewhere with these advanced options should be enough. True. So, config SCSI_CONSTANTS Kernel log messages from the SCSI subsystem will be easier to understand if you say Y here... would say what this option really does. But to some degree the need to explain what the SCSI subsystem or SCSI core is and which other subsystems make use of it remains. Maybe it's OK to provide documentation of this kind outside of Kconfig help though. [1] SCSI as in sold as SCSI Difficult. Does e.g. hardware sold as SAS count as sold as SCSI? How about SBP-2 then? ;-) -- Stefan Richter -=-=-=== =--= - http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] SCSI: split Kconfig menu into two
Stefan Richter wrote: Adrian Bunk wrote: On Sat, Sep 15, 2007 at 04:11:45PM +0200, Stefan Richter wrote: Perfect is in the eye of the beholder. You would consequently have to add such options into all menus which contain scsi low-level providers. Kconfig is a user interface, so perfect is what is best for the kconfig users. Duplicate options with different names in different menus, but which all do the same, --- is this the best for users? I recognize it's a rhetorical question :) The answer is of course no. I hope the other participants of this thread register the severe disinclination of the maintainers to change this stuff, as this is a classic case of making a mountain out of a molehill[1]. For the -vast majority- of people configuring the kernel, this is not a problem. Kernel people are -expected- to know what they're doing, especially when switching from one major subsystem to another. Therefore, all this is IMO wasted effort and hot air. There are far more important issues to deal with. Jeff [1] http://www.bartleby.com/59/4/makeamountai.html - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] SCSI: split Kconfig menu into two
On Sat, Sep 15, 2007 at 11:44:59AM -0400, Jeff Garzik wrote: Stefan Richter wrote: Adrian Bunk wrote: On Sat, Sep 15, 2007 at 04:11:45PM +0200, Stefan Richter wrote: Perfect is in the eye of the beholder. You would consequently have to add such options into all menus which contain scsi low-level providers. Kconfig is a user interface, so perfect is what is best for the kconfig users. Duplicate options with different names in different menus, but which all do the same, --- is this the best for users? I recognize it's a rhetorical question :) The answer is of course no. I hope the other participants of this thread register the severe disinclination of the maintainers to change this stuff, as this is a classic case of making a mountain out of a molehill[1]. For the -vast majority- of people configuring the kernel, this is not a problem. Kernel people are -expected- to know what they're doing, I doubt your claim is true since the vast majority of kconfig users are most likely not kernel developers. @Greg: Do you have any numbers regarding how your Linux Kernel in a Nutshell is selling? Even download numbers? especially when switching from one major subsystem to another. It's not only about switching, the same problems awaits people when configuring a kernel for their hardware the first time. Therefore, all this is IMO wasted effort and hot air. There are far more important issues to deal with. Why don't we dump kconfig and write the .config by hand? ;-) More seriously: Yes, there are many other important issues in the kernel. But not fixing kconfig UI problems doesn't fix these issues faster. I have seen people running into problems because some required option wasn't set - in the simplest cases things like IDE without DMA because a help text wasn't updated when more hardware support was added to a driver. You might not care about the kconfig users. But other people do. 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-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] SCSI: split Kconfig menu into two
On Saturday 15 September 2007, Adrian Bunk wrote: On Sat, Sep 15, 2007 at 11:44:59AM -0400, Jeff Garzik wrote: Stefan Richter wrote: Adrian Bunk wrote: On Sat, Sep 15, 2007 at 04:11:45PM +0200, Stefan Richter wrote: Perfect is in the eye of the beholder. You would consequently have to add such options into all menus which contain scsi low-level providers. Kconfig is a user interface, so perfect is what is best for the kconfig users. Duplicate options with different names in different menus, but which all do the same, --- is this the best for users? I recognize it's a rhetorical question :) The answer is of course no. I hope the other participants of this thread register the severe disinclination of the maintainers to change this stuff, as this is a classic case of making a mountain out of a molehill[1]. For the -vast majority- of people configuring the kernel, this is not a problem. Kernel people are -expected- to know what they're doing, I doubt your claim is true since the vast majority of kconfig users are most likely not kernel developers. Yes, we shouldn't be needlessly raising the bar for power users. @Greg: Do you have any numbers regarding how your Linux Kernel in a Nutshell is selling? Even download numbers? especially when switching from one major subsystem to another. It's not only about switching, the same problems awaits people when configuring a kernel for their hardware the first time. *nods* Therefore, all this is IMO wasted effort and hot air. There are far more important issues to deal with. Why don't we dump kconfig and write the .config by hand? ;-) More seriously: Yes, there are many other important issues in the kernel. But not fixing kconfig UI problems doesn't fix these issues faster. Agreed, and actually not fixing Kconfig UI problems will make the other issues being fixed *slower* (because they result in *increased* workload on developers' side). I have seen people running into problems because some required option wasn't set - in the simplest cases things like IDE without DMA because a help text wasn't updated when more hardware support was added to a driver. This is why nowadays IDE DMA support is automatically selected by IDE host drivers that need it - a big relief for everybody. You might not care about the kconfig users. But other people do. ...and even if their attempts/solutions may not be proper yet they should not be discouraged to work on these problems... Thanks, Bart - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] SCSI: split Kconfig menu into two
Bartlomiej Zolnierkiewicz wrote: On Saturday 15 September 2007, Adrian Bunk wrote: On Sat, Sep 15, 2007 at 11:44:59AM -0400, Jeff Garzik wrote: Stefan Richter wrote: Adrian Bunk wrote: On Sat, Sep 15, 2007 at 04:11:45PM +0200, Stefan Richter wrote: Perfect is in the eye of the beholder. You would consequently have to add such options into all menus which contain scsi low-level providers. Kconfig is a user interface, so perfect is what is best for the kconfig users. Duplicate options with different names in different menus, but which all do the same, --- is this the best for users? I recognize it's a rhetorical question :) The answer is of course no. I hope the other participants of this thread register the severe disinclination of the maintainers to change this stuff, as this is a classic case of making a mountain out of a molehill[1]. For the -vast majority- of people configuring the kernel, this is not a problem. Kernel people are -expected- to know what they're doing, I doubt your claim is true since the vast majority of kconfig users are most likely not kernel developers. Yes, we shouldn't be needlessly raising the bar for power users. In this case, no bar is being raised, for any user. @Greg: Do you have any numbers regarding how your Linux Kernel in a Nutshell is selling? Even download numbers? especially when switching from one major subsystem to another. It's not only about switching, the same problems awaits people when configuring a kernel for their hardware the first time. *nods* Therefore, all this is IMO wasted effort and hot air. There are far more important issues to deal with. Why don't we dump kconfig and write the .config by hand? ;-) More seriously: Yes, there are many other important issues in the kernel. But not fixing kconfig UI problems doesn't fix these issues faster. Agreed, and actually not fixing Kconfig UI problems will make the other issues being fixed *slower* (because they result in *increased* workload on developers' side). Irrelevant in this case, because there is no increased workload on the developer's side. I have seen people running into problems because some required option wasn't set - in the simplest cases things like IDE without DMA because a help text wasn't updated when more hardware support was added to a driver. This is why nowadays IDE DMA support is automatically selected by IDE host drivers that need it - a big relief for everybody. Please don't take this any more off-topic than it already is. IDE DMA option was vastly different. The options in question here affect whether or not you have a block device to use -- something that is immediately obviously and corrected quickly. You might not care about the kconfig users. But other people do. ...and even if their attempts/solutions may not be proper yet they should not be discouraged to work on these problems... There is no problem, in this case. Otherwise, there would be more than a complaint or two per year. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] SCSI: split Kconfig menu into two
On Saturday 15 September 2007, Jeff Garzik wrote: Bartlomiej Zolnierkiewicz wrote: On Saturday 15 September 2007, Adrian Bunk wrote: On Sat, Sep 15, 2007 at 11:44:59AM -0400, Jeff Garzik wrote: Stefan Richter wrote: Adrian Bunk wrote: On Sat, Sep 15, 2007 at 04:11:45PM +0200, Stefan Richter wrote: Perfect is in the eye of the beholder. You would consequently have to add such options into all menus which contain scsi low-level providers. Kconfig is a user interface, so perfect is what is best for the kconfig users. Duplicate options with different names in different menus, but which all do the same, --- is this the best for users? I recognize it's a rhetorical question :) The answer is of course no. I hope the other participants of this thread register the severe disinclination of the maintainers to change this stuff, as this is a classic case of making a mountain out of a molehill[1]. For the -vast majority- of people configuring the kernel, this is not a problem. Kernel people are -expected- to know what they're doing, I doubt your claim is true since the vast majority of kconfig users are most likely not kernel developers. Yes, we shouldn't be needlessly raising the bar for power users. In this case, no bar is being raised, for any user. It has already been raised by making SATA configuration counterintuitive (SATA has a separate Kconfig menu but depends on SCSI device drivers). @Greg: Do you have any numbers regarding how your Linux Kernel in a Nutshell is selling? Even download numbers? especially when switching from one major subsystem to another. It's not only about switching, the same problems awaits people when configuring a kernel for their hardware the first time. *nods* Therefore, all this is IMO wasted effort and hot air. There are far more important issues to deal with. Why don't we dump kconfig and write the .config by hand? ;-) More seriously: Yes, there are many other important issues in the kernel. But not fixing kconfig UI problems doesn't fix these issues faster. Agreed, and actually not fixing Kconfig UI problems will make the other issues being fixed *slower* (because they result in *increased* workload on developers' side). Irrelevant in this case, because there is no increased workload on the developer's side. This thread alone serves as a perfect counter-example. ;) I have seen people running into problems because some required option wasn't set - in the simplest cases things like IDE without DMA because a help text wasn't updated when more hardware support was added to a driver. This is why nowadays IDE DMA support is automatically selected by IDE host drivers that need it - a big relief for everybody. Please don't take this any more off-topic than it already is. OK, I'll stop here and I'll just patiently wait till the SATA Kconfig issue comes up again on LKML (then I'll just smile and move on to the next post 8). IDE DMA option was vastly different. The options in question here affect whether or not you have a block device to use -- something that is immediately obviously and corrected quickly. Indeed -- completely different situation. You might not care about the kconfig users. But other people do. ...and even if their attempts/solutions may not be proper yet they should not be discouraged to work on these problems... There is no problem, in this case. Fine with me then. The above was the most important part for me. Otherwise, there would be more than a complaint or two per year. Thanks, Bart - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] SCSI: split Kconfig menu into two
Hi Stefan. Such a patch really calls for some minimal unifacation among the architectures. arch/alpha/Kconfig|2 arch/arm/Kconfig |2 arch/avr32/Kconfig|2 arch/blackfin/Kconfig |2 arch/cris/Kconfig |2 arch/frv/Kconfig |2 arch/i386/Kconfig |2 arch/ia64/Kconfig |2 arch/m32r/Kconfig |2 arch/m68k/Kconfig |2 arch/m68knommu/Kconfig|2 arch/mips/Kconfig |2 arch/parisc/Kconfig |2 arch/powerpc/Kconfig |2 arch/ppc/Kconfig |2 arch/s390/Kconfig |2 arch/sh/Kconfig |2 arch/sh64/Kconfig |2 arch/sparc/Kconfig|2 arch/sparc64/Kconfig |2 arch/um/Kconfig |2 arch/v850/Kconfig |2 arch/x86_64/Kconfig |4 arch/xtensa/Kconfig |2 Exactly the same change for all architectures. IT would be good to introduce a common file that contains some of the shared stuff from the different architectures. We could start out simple with: arch/Kconfig.arch: source net/Kconfig source drivers/Kconfig source fs/Kconfig source security/Kconfig source crypto/Kconfig source lib/Kconfig And then source it in all relevant arch Kconfig files. It is not all that can use it but most do. A trivial task but one small step towards unification between the architectures on the Kconfig level. Sam - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] SCSI: split Kconfig menu into two
On Fri, Sep 14, 2007 at 09:00:33PM +0200, Sam Ravnborg wrote: Hi Stefan. Such a patch really calls for some minimal unifacation among the architectures. arch/alpha/Kconfig|2 arch/arm/Kconfig |2 arch/avr32/Kconfig|2 arch/blackfin/Kconfig |2 arch/cris/Kconfig |2 arch/frv/Kconfig |2 arch/i386/Kconfig |2 arch/ia64/Kconfig |2 arch/m32r/Kconfig |2 arch/m68k/Kconfig |2 arch/m68knommu/Kconfig|2 arch/mips/Kconfig |2 arch/parisc/Kconfig |2 arch/powerpc/Kconfig |2 arch/ppc/Kconfig |2 arch/s390/Kconfig |2 arch/sh/Kconfig |2 arch/sh64/Kconfig |2 arch/sparc/Kconfig|2 arch/sparc64/Kconfig |2 arch/um/Kconfig |2 arch/v850/Kconfig |2 arch/x86_64/Kconfig |4 arch/xtensa/Kconfig |2 Exactly the same change for all architectures. IT would be good to introduce a common file that contains some of the shared stuff from the different architectures. We could start out simple with: arch/Kconfig.arch: ... Stefan simply shouldn't move it out of drivers/Kconfig. Sam 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-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] SCSI: split Kconfig menu into two
I wrote: Applies after patch SCSI: update Kconfig help text to indicate SCSI core's widespread usage, Actually the addition This menu also presents options for specific SCSI controllers... from that patch is then no longer true. These two patches could very well be collapsed into one. (I'll gladly do that, or only send an update of the 'split Kconfig menu' patch with that sentence backed out, if desired.) -- Stefan Richter -=-=-=== =--= -===- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
