Re: [PATCH 2/5] USB Kconfig: Select SCSI for USB Mass Storage support

From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Adrian Bunk <bunk@kernel.org>
Cc: Randy Dunlap <randy.dunlap@oracle.com>,
	Sam Ravnborg <sam@ravnborg.org>, Al Boldi <a1426z@gawab.com>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Brownell <david-b@pacbell.net>, Greg KH <greg@kroah.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 2/5] USB Kconfig: Select SCSI for USB Mass Storage	support
Date: Sun, 06 Jan 2008 14:13:09 +0100	[thread overview]
Message-ID: <4780D3E5.20908@s5r6.in-berlin.de> (raw)
In-Reply-To: <20080106123728.GD2082@does.not.exist>

Adrian Bunk wrote:
> On Sun, Jan 06, 2008 at 01:18:48PM +0100, Stefan Richter wrote:
>> I'm afraid this can't be put into practice.  (User says which hardware
>> and protocols he needs to be supported, scripts magically assemble a
>> suitable configuration.)
> 
> Distribution installers and live CDs like Knoppix even manage to 
> magically assemble a suitable configuration (e.g. autodetecting which 
> modules they should load) without asking the user any questions.

Module autoloading is quite different.

> The information the user has to give when configuring his kernel is 
> whether he wants to connects USB disks - whether or not the 
> implementation of the kernel driver uses the in-kernel SCSI layer we can 
> easily handle automatically without bothering the user.
> 
>> I think
>>   - sensibly modularize our software,
>>   - tell the user which software components there are,
>>   - what they are for,
>>   - how they depend on each other,
>>   - make it easy enough for the user to navigate in the dependency
>>     graph,
>>   - provide fundamental safeguards and checks for a proper software
>>     configuration
>> is the best we can do.
> 
> It sounds strange that what you call the "the best we can do" would be 
> much worse than what we are currently doing...
> 
> The current status quo is that a user e.g. only has to know that his 
> ethernet controller is a "Broadcom 440x/47xx", the fact that a Sonics 
> Silicon Backplane bus is used on the card is handled automatically by 
> kconfig.

if NET_ETHERNET
...
config B44
	tristate "Broadcom 440x/47xx ethernet support"
	depends on SSB_POSSIBLE
	select SSB
	select MII
...
endif # NET_ETHERNET

There is a B44 option.  The prompt string (in other cases the help text)
tells what it is for.  Furthermore, four dependencies are encoded; one
in the direct form, one by if/endif, two in reverse form.  There are no
further hints how to satisfy SSB_POSSIBLE, NET_ETHERNET, SSB, MII.  The
kconfig system is told to enable SSB and MII no matter what, as long as
SSB_POSSIBLE, NET_ETHERNET, and B44 are != n.

This /is/ what we are currently doing, not "worse than what we are
currently doing".  We
  - sensibly modularize our software,
  - tell the user which software components there are,
  - what they are for,
  - how they depend on each other,
  - make it easy enough for the user to navigate in the dependency
    graph,
  - provide fundamental safeguards and checks for a proper software
    configuration.  (Well, we actually walk on thin ice whenever we
    use the 'select' keyword.)

(Now, after the b44.ko has been built and installed, the object file
should contain aliases which let modern userland automatically load this
kernel object if respective hardware has been detected and the module
wasn't blacklisted.  So, run-time configuration is more comfortable than
build-time configuration, except that help texts aren't as easily
accessible at run-time as they are at build-time.)
-- 
Stefan Richter
-=====-==--- ---= --==-
http://arcgraph.de/sr/