Re: [RFC PATCH] SCSI: split Kconfig menu into two

Adrian Bunk
2007-09-15T12:51:03Z

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