Select SCSI for USB Mass Storage support.
Cc: David Brownell <david-b@pacbell.net>

Cc: Greg KH <greg@kroah.com>

Cc: Andrew Morton <akpm@linux-foundation.org>

Signed-off-by: Al Boldi <a1426z@gawab.com>
---
--- 23.a/drivers/usb/storage/Kconfig

+++ 23.b/drivers/usb/storage/Kconfig

@@ -2,14 +2,10 @@

 # USB Storage driver configuration

 #
-comment "NOTE: USB_STORAGE needs SCSI, and 'SCSI disk support' may"

-	depends on USB

-comment "also be needed; see USB_STORAGE Help for more information"

-	depends on USB

-

 menuconfig USB_STORAGE

 	tristate "USB Mass Storage support"

-	depends on USB && SCSI

+	depends on USB

+	select SCSI

 	---help---

 	  Say Y here if you want to connect USB mass storage devices to your

 	  computer's USB port. This is the driver you need for USB

@@ -18,13 +14,17 @@ menuconfig USB_STORAGE

 	  similar devices. This driver may also be used for some cameras

 	  and card readers.
-	  This option depends on 'SCSI' support being enabled, but you

-	  probably also need 'SCSI device support: SCSI disk support'

+	  This option selects 'SCSI' support , but you probably

+	  also need 'SCSI device support: SCSI disk support'

 	  (BLK_DEV_SD) for most USB storage devices.
 	  To compile this driver as a module, choose M here: the

 	  module will be called usb-storage.
+if USB_STORAGE

+comment "NOTE: USB_STORAGE selects SCSI, but 'SCSI disk support' may"

+comment "also be needed; see USB_STORAGE Help for more information"

+

 config USB_STORAGE_DEBUG

 	bool "USB Mass Storage verbose debug"

 	depends on USB_STORAGE

@@ -147,6 +147,8 @@ config USB_STORAGE_KARMA

 	  on the resulting scsi device node returns the Karma to normal

 	  operation.
+endif # USB_STORAGE

+

 config USB_LIBUSUAL

 	bool "The shared table of common (or usual) storage devices"

 	depends on USB
--

Your patch description fails to mention what is wrong with the existing

solution.

--

Stefan Richter

-=====-==--- ---= --=-=

http://arcgraph.de/sr/

--

Better ... but wouldn't something like
	comment "You probably also need to enable 'SCSI disk support'"

		depends on !BLK_DEV_SD
be better?  No point in telling people stuff they don't need to know...

--

We try not to use 'select' on subsystems and try to limit its use

to library-like code that is relatively small.  Selecting SCSI

breaks both of those efforts.

Furthermore, we try to give the user help here in both the

comments and help text.
---

~Randy

desserts:  http://www.xenotime.net/linux/recipes/

--

_You_ are trying to do this.
For kconfig users, "select" is _much_ better than sending them through

different menus.
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
--

Only if used within the current limitations of Kconfig.

And that requires you to use select only to select symbols with

no dependencies.
In this case we do not know if BLOCK is enabled or not.
	Sam

--

Good point!  How about we solve it like this:
  	menuconfig USB_STORAGE

  	tristate "USB Mass Storage support"

-	depends on USB && SCSI

+	depends on USB && BLOCK

+	select SCSI
Thanks!
--

Al
--

Still wrong.  SCSI also needs HAS_DMA and SCSI_DMA.  HAS_DMA furthermore

depends on !NO_DMA.  So that would mean
menuconfig USB_STORAGE

	tristate "USB Mass Storage support"

	depends on USB && BLOCK && HAS_DMA

	select SCSI

	select SCSI_DMA
But copying all (currently existing) dependencies of SCSI to USB_STORAGE

is arguably a bad solution.  There are four other potential solutions:
  - Let kconfig look up the dependencies of SCSI.  If they are

    fulfilled, present the option USB_STORAGE and switch on SCSI if

    the user chooses USB_STORAGE.
  - Let kconfig recursively look up all dependencies of SCSI and their

    subsequent dependencies.  Try to switch them all on if the user

    chooses USB_STORAGE.  If that fails for whatever reason, say to

    the user:  I'm sorry Dave, I'm afraid I can't do that.
  - Don't use 'select' on options which have further dependencies.
  - Design and implement UIs which don't need 'select' in the first

    place.

--

Stefan Richter

-=====-==--- ---= --==-

http://arcgraph.de/sr/

--

I don't think so.  SCSI selects SCSI_DMA, it doesn't depend on it.  So it's

safe to select SCSI here, as libata does it the same way.
Thanks!
--

Al
--

"A selects B" == "A depends on B, but please don't hide A when B is off

and silently switch B on when A is switched on".
config SCSI

	tristate "SCSI device support"

	depends on BLOCK

	select SCSI_DMA if HAS_DMA
So, SCSI doesn't actually need SCSI_DMA per se, but it apparently needs
Sam, does kconfig recursively follow select statements and switch on

options which are select'ed by select'ed options?  I suppose it doesn't.
Maybe this would be better:
 config SCSI

 	tristate "SCSI device support"

 	depends on BLOCK

-	select SCSI_DMA if HAS_DMA
 config SCSI_DMA

 	bool

-	default n

+	default y if SCSI && HAS_DMA
--

Stefan Richter

-=====-==--- ---= --==-

http://arcgraph.de/sr/

--

Let's try...

menu "Level 1"
config FOO1

        bool "Want to have FOO1?"

        select FOO2
config FOO2

        bool "Want to have FOO2?"

        select FOO3
config FOO3

        bool "Want to have FOO3?"
endmenu
With the above example it is obvious when running mconf

that it does so.

If you choose FOO1 in mconf and then save the configuration
This should be semantic equivalent and much easier to understand.
	Sam

--

In fact, only a number of SCSI low-level drivers need SCSI_DMA.  But

libata and usb-storage are currently not among those drivers.  For them

it's currently harmless if SCSI_DMA is off.
SCSI_DMA only includes the symbols scsi_dma_map() and scsi_dma_unmap()

into the scsi core.  libata and usb-storage don't call these.

--

Stefan Richter

-=====-==--- ---= --==-

http://arcgraph.de/sr/

--

Right.  One of the main (or maybe even the only) problem(s) is

that select does not follow dependency chains.
For Aunt Tillie cases, "select" makes sense.  For other cases,

I'd argue that it makes sense for config users to know when they

do something that causes an entire subsystem to be added to their

kernel (like SCSI or NET).
--

~Randy

desserts:  http://www.xenotime.net/linux/recipes/

--

Besides the issue of additional potentially unsatisfied dependencies and

the issue of things being enabled behind the user's back --- there is

another issue which Adrian and Al ignore:
The user who wants to enable usb-storage /has/ to go into the SCSI menu

anyway to answer whether he needs sd, sr, st, sg, command logging...

--

Stefan Richter

-=====-==--- ---= --==-

http://arcgraph.de/sr/

--

That's a different UI problem that has to be fixed.
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
--

That's right, maybe create a "SCSI related I/O protocols" menu or

something like that.  I seem to remember previous attempts to do this. :-)

--

Stefan Richter

-=====-==--- ---= --==-

http://arcgraph.de/sr/

--

We are not talking about Aunt Tillie [1] since she anyway does not build

her own kernel.
The vast majority of kconfig users should be covered by the

"system administrator" use case. And for them it's a lot easier if they

simply find the options for their hardware in the logical places without

additional hassle.
Whether or not an option requires an additional subsystem like e.g. SCSI

or SSB are hardware and implementation details we shouldn't bother

kconfig users with.
cu

Adrian
[1] kconfig version of Godwin's law
-- 
       "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
--

What is an implementation detail and what is not?  In the end,

everything that we configure in Kconfig is implementation details.
PS:

Kill 'select' already, and instead work on better UIs if you have got

trouble with the complexities of the dependencies graph.  The graphic

UIs including menuconfig currently work best for tree-like dependencies,

but the graph isn't a tree.  Think about how to present this properly in

an UI.  The Kconfig files are the wrong place to attack this problem.
PPS:

Really, it's *not* hard *at all* to configure a 2.6.24-rc6 kernel with

USB storage support.  I don't read linux-usb --- has there been repeated

questions how to enable usb-storage in the kernel configuration?  I can

tell you that there has been no such question about sbp2 (FireWire

storage support) in years.  Don't fix what ain't broken.  In fact, don't

/break/ what ain't broken by adding more of the (as yet) broken 'select'

everywhere.

--

Stefan Richter

-=====-==--- ---= --==-

http://arcgraph.de/sr/

--

I do read linux-usb.  I don't think that USB storage configuration

is a big issue (currently, without using "select").
--

~Randy

desserts:  http://www.xenotime.net/linux/recipes/

--

With the use case "system administrator" we can expect people to know

the name of their ethernet card and which filesystems they use, but we

should not bother them with the fact that their network card might 
Duplicating the structure in each UI should be an improvement?
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
--

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.)
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.

--

Stefan Richter

-=====-==--- ---= --==-

http://arcgraph.de/sr/

--

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.
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 
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 
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
--

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/

--

Both are "hardware -> required kernel support" mappings.
I know that people don't like this idea since the CML2 discussions, but

there even don't seem to be any big problems if anyone wants to put all

the pieces together and assemble a suitable .config only based on the

autodetection tools of some distribution and without asking the user 
You miss the fundamental point:
The vast majority of kconfig users are _not_ kernel hackers, and they

neither know nor want to know anything about kernel internals - they

just want to build a kernel suitable for their system.
You want to make an UI easier to use for the developers but harder to 
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
--

How to autodetect that the user is going to buy gadget xyz next week?

(OK, he can re-run autodetection then, although that's not a

particularly economic strategy.)
How to autodetect POSIX_MQUEUE, HZ_250, HOTPLUG_PCI, ...?
I don't miss the point.  I just say what we realistically can do.  And I

might add, we should try hard to achieve good results in each of the
No, I don't.
(I have "worked" long enough in enduser support, and still am doing

support, to not have completely lost an eye for enduser needs.  Or so I

believe.)

--

Stefan Richter

-=====-==--- ---= --==-

http://arcgraph.de/sr/

--

Adrian - it is you that miss the important piont in this discussion.
We have two simple options:

1) Allow the user to define non-valid configurations

2) And the opposite
And we want to define only valid configurations which is why we

with the present select behavious cannot just do "select USB",

becasue we may end up with USB selected but not what USB depends on.
And duplicating the dependencies of USB in all places where we

select USB is not a scalable solution.
So until we have select fixed - do not misue it.
	Sam

--

but if boot scripts can figure out what modules to autoload, why can't

scripts be written to figure out what drives to build into a system?
David Lang

--

Because build-time configuration has to deal with different, more

complex questions than run-time configuration.  For starters, build-time

configuration narrows down the options for run-time configuration.

--

Stefan Richter

-=====-==--- ---= --==-

http://arcgraph.de/sr/

--

Ok, I'll bite.
what config options must be selected by the user at build time? (i.e. no

sane default can possibly be deduced from the hardware)
there are a lot of options that, if selected, will affect the final result

significantly. but I can't think of any that can't have a reasonable

default.
what sysadmins like me would really like is a set of scripts that could

generate a .config from an existing system. After we have one that covers

the hardware for the system we will then have a much better starting point

to work from. We may disable some drivers (sound drivers on a server for

example). We may enable other drivers (or combine the results of runs on

seperate hardware to make a slightly more general kernel config). And we

will make many other selections that are not hardware dependant (SLAB vs

SLUB vs SLOB, IO schedulers, etc) but just figuring out what drivers are

needed to support a particular piece of hardware would be a huge help.

It's frequently hard to figure out which drivers are needed for a Vendor X

model 12345 motherboard (major things are easy, it gets hard when you want

to do power monitoring and things like that) it is even harder when you

have to figure out what needs to be enabled so that you can see the help

text of other options to see if they are the right ones.
I started toying with Linux (on my home systems) in the 0.99 days and have

been makeing my living with it starting in the 1.3 days, so it's not that

I am a newcomer to kernel configuration, but even with my experiance it's

sometimes hard to figure out what I need to enable when I start needing a

new set of functionality on a system.
David Lang

--

xconfig's "Show Debug Info" and menuconfig's help screen show you

whether an option was selected and by which option.  xconfig calls it

"reverse dep:", menuconfig says "Selected by:".
Of course these features are merely there because 'select' creates this

problem in the first place.

--

Stefan Richter

-=====-==--- ---= --==-

http://arcgraph.de/sr/

--

...
I agree that sets of defaults, e.g. based on usage profiles, help a lot.
Alas the 'select' keyword enforces one particular profile.  (And it is

currently broken and generally dangerous and inefficient for

dependencies deeper than one level.)

--

Stefan Richter

-=====-==--- ---= --==-

http://arcgraph.de/sr/

--

What do you mean?
We have dependency data in the Kconfig files.  We have a few different

UIs to them.  Why there are different UIs is easy (oldconfig vs.

xconfig) or not so easy (gconfig vs. xconfig) to explain.  Anyway; IMO

we should keep data and presentation separate for at least two reasons:

  - to allow us to have specialized task-oriented UIs (oldconfig,

    randconfig et cetera)

  - because different people have different approaches to kernel

    configuration (the guy who sets up a new box vs. the guy who bought

    a new gadget vs. the guy who updates his kernel vs. the control

    freak vs. the kernel tester vs...)
If the UIs worked properly, then you won't need separate keywords for

dependency and reverse dependency (depends on vs. select) in the Kconfig

files.
Besides, as Sam has reminded us, the make xyzconfig programs handle the

reverse dependency (select) not correctly yet.  They switch on the

selected symbols without caring whether these symbols have dependencies

themselves.  Friends of 'select', why don't you fix this bug before you

continue to post patches which select symbols which themselves have

dependencies?

--

Stefan Richter

-=====-==--- ---= --==-

http://arcgraph.de/sr/

--

You said:

"The graphic UIs including menuconfig currently work best for tree-like

 dependencies"
That's true.
And the dependency graph can't be a tree.
Currently, defining the ordered tree the UIs present to the user is done

_once_ in kconfig.
Our UIs either show this tree as a tree or go through the tree

depth-first and present the options in this order to the user.
And I think your main misunderstanding is that you think the

dependencies alone would carry enough information for allowing an UI to

present the options in a way not worse than it's currently done - that's 
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
--

No, the dependency relationships alone do not carry enough information.

  I am aware of that.
For example, we certainly want groupings or tags such as "option is

(directly) related to USB hardware", "filesystems related option",

"option is for debugging purposes" etc..  We currently provide hints

like this via the 'menu' keyword.  We also want help texts per option

and per group of options.
However, there is ultimately not a single most logical way to group

options.  There could be groups which would overlap.  The grouping per

'menu' provides only one fixed non-overlapping grouping.

--

Stefan Richter

-=====-==--- ---= --==-

http://arcgraph.de/sr/

--

I don't think your implementation would result in a better UI.
But I know that have a tendency of being overly pessimistic and ideas I 
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
--

I'm afraid I am still very far from an implementation which we could

test.  And I will remain so for a while because I an inexperienced in

userspace UI design and programming and because there are lots and lots

of other more urgent tasks.  http://lwn.net/Articles/262741/

--

Stefan Richter

-=====-==--- ---= --==-

http://arcgraph.de/sr/

--