Messages in this thread | | | Date | Tue, 29 Aug 2006 15:50:49 +0200 | From | Stefan Richter <> | Subject | Re: [PATCH 17/17] BLOCK: Make it possible to disable the block layer [try #2] |
| |
Christoph Hellwig wrote: > On Tue, Aug 29, 2006 at 01:23:18PM +0100, David Howells wrote: >> Christoph Hellwig <hch@infradead.org> wrote: >> >>> Same as above. USB_STORAGE already selects scsi so it shouldn't need >>> to depend on block. >> Ah, you've got it the wrong way round. >> >> Because USB_STORAGE _selects_ SCSI rather than depending on it, even if SCSI >> is disabled, USB_STORAGE can be enabled, and that turns on CONFIG_SCSI, even >> if not all of its dependencies are available. >> >> Run "make allyesconfig" and then try to turn off CONFIG_SCSI without this... > > Eeek. The easy fix is to change USB_STORAGE to depend on SCSI (*), but in > addition to that we should probably fix Kconfig aswell to adhere to > such constraints. > > > (*) that selects is really wrong to start with, the other scsi drivers don't > select scsi either.
It is not wrong per se.
If SCSI is set to "N", then any menu items which depend on SCSI are not visible anymore. This is not a problem with any of the items in the SCSI configuration section.
But it is a problem for any items that live _in other configuration sections_, such as USB_STORAGE (currently not affected because it selects SCSI) and IEEE1394_SBP2 (does select SCSI now too in -mm).
If "select" cannot be fixed or is not en vogue for any other reason, the configuration tools need to be improved otherwise, so that users are guided to options like USB_STORAGE and IEEE1394_SBP2 when SCSI or other "foreign" options were disabled.
The kernel configuration is currently presented as a tree, although the dependencies of config options are not a tree. That's were "select" helps. -- Stefan Richter -=====-=-==- =--- ===-= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |