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

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

[Al Boldi]

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

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

[David Brownell]

On Saturday 05 January 2008, Al Boldi wrote:
> +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

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

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

[Randy Dunlap]

On Sat, 5 Jan 2008 18:41:39 +0300 Al Boldi wrote:

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

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.

NAK as far as I am concerned.

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



---
~Randy
desserts:  http://www.xenotime.net/linux/recipes/

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

[Stefan Richter]

Al Boldi wrote:
> -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

Your patch description fails to mention what is wrong with the existing
solution.
-- 
Stefan Richter
-=====-==--- ---= --=-=
http://arcgraph.de/sr/

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

[Adrian Bunk]

On Sat, Jan 05, 2008 at 11:30:24AM -0800, Randy Dunlap wrote:
> On Sat, 5 Jan 2008 18:41:39 +0300 Al Boldi wrote:
> 
> > 
> > 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
> 
> 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.
>...

_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

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

[Sam Ravnborg]

On Sat, Jan 05, 2008 at 11:03:30PM +0200, Adrian Bunk wrote:
> On Sat, Jan 05, 2008 at 11:30:24AM -0800, Randy Dunlap wrote:
> > On Sat, 5 Jan 2008 18:41:39 +0300 Al Boldi wrote:
> > 
> > > 
> > > 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
> > 
> > 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.
> >...
> 
> _You_ are trying to do this.
> 
> For kconfig users, "select" is _much_ better than sending them through 
> different menus.
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

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

[Randy Dunlap]

Sam Ravnborg wrote:
> On Sat, Jan 05, 2008 at 11:03:30PM +0200, Adrian Bunk wrote:
>> On Sat, Jan 05, 2008 at 11:30:24AM -0800, Randy Dunlap wrote:
>>> On Sat, 5 Jan 2008 18:41:39 +0300 Al Boldi wrote:
>>>
>>>> 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
>>> 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.
>>> ...
>> _You_ are trying to do this.

I'd say that sometimes Andrew helps also.

>> For kconfig users, "select" is _much_ better than sending them through 
>> different menus.
> Only if used within the current limitations of Kconfig.
> And that requires you to use select only to select symbols with
> no dependencies.

Right.  One of the main (or maybe even the only) problem(s) is
that select does not follow dependency chains.
and that no one works on that problem.

> In this case we do not know if BLOCK is enabled or not.

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/

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

[Adrian Bunk]

On Sat, Jan 05, 2008 at 03:22:14PM -0800, Randy Dunlap wrote:
>...
> 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).

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

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

[Stefan Richter]

Adrian Bunk wrote:
> 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.

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/

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

[Adrian Bunk]

On Sun, Jan 06, 2008 at 01:35:21AM +0100, Stefan Richter wrote:
> Adrian Bunk wrote:
> > 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.
> 
> What is an implementation detail and what is not?  In the end,
> everything that we configure in Kconfig is implementation details.

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 
require the Sonics Silicon Backplane support.

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

Duplicating the structure in each UI should be an improvement?

Hardly.

> 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

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

[Randy Dunlap]

Stefan Richter wrote:
> Adrian Bunk wrote:
>> 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.
> 
> 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

I do read linux-usb.  I don't think that USB storage configuration
is a big issue (currently, without using "select").
But that's just my take on it.

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


-- 
~Randy
desserts:  http://www.xenotime.net/linux/recipes/

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

[Al Boldi]

Sam Ravnborg wrote:
> On Sat, Jan 05, 2008 at 11:03:30PM +0200, Adrian Bunk wrote:
> > For kconfig users, "select" is _much_ better than sending them through
> > different menus.
>
> 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.

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

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

[Stefan Richter]

Adrian Bunk wrote:
> On Sun, Jan 06, 2008 at 01:35:21AM +0100, Stefan Richter wrote:
>> 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.
>> ...
> 
> Duplicating the structure in each UI should be an improvement?
> 
> Hardly.

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/

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

[Stefan Richter]

Randy Dunlap wrote:
> Sam Ravnborg wrote:
>> On Sat, Jan 05, 2008 at 11:03:30PM +0200, Adrian Bunk wrote:
>>> For kconfig users, "select" is _much_ better than sending them
>>> through different menus.
>> Only if used within the current limitations of Kconfig.
>> And that requires you to use select only to select symbols with
>> no dependencies.
> 
> Right.  One of the main (or maybe even the only) problem(s) is
> that select does not follow dependency chains.
> and that no one works on that problem.
> 
>> In this case we do not know if BLOCK is enabled or not.
> 
> 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).

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/

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

[Adrian Bunk]

On Sun, Jan 06, 2008 at 12:29:46PM +0100, Stefan Richter wrote:
> Adrian Bunk wrote:
> > On Sun, Jan 06, 2008 at 01:35:21AM +0100, Stefan Richter wrote:
> >> 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.
> >> ...
> > 
> > Duplicating the structure in each UI should be an improvement?
> > 
> > Hardly.
> 
> 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...)
>...

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 
simply not true.

> 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

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

[Adrian Bunk]

On Sun, Jan 06, 2008 at 12:54:04PM +0100, Stefan Richter wrote:
> Randy Dunlap wrote:
> > Sam Ravnborg wrote:
> >> On Sat, Jan 05, 2008 at 11:03:30PM +0200, Adrian Bunk wrote:
> >>> For kconfig users, "select" is _much_ better than sending them
> >>> through different menus.
> >> Only if used within the current limitations of Kconfig.
> >> And that requires you to use select only to select symbols with
> >> no dependencies.
> > 
> > Right.  One of the main (or maybe even the only) problem(s) is
> > that select does not follow dependency chains.
> > and that no one works on that problem.
> > 
> >> In this case we do not know if BLOCK is enabled or not.
> > 
> > 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).
> 
> 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...

That's a different UI problem that has to be fixed.

The "SCSI support type" menu has to move out of the SCSI menu.

> 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

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

[Stefan Richter]

Adrian Bunk wrote:
> On Sun, Jan 06, 2008 at 01:35:21AM +0100, Stefan Richter wrote:
>> Adrian Bunk wrote:
>>> 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.
>> What is an implementation detail and what is not?  In the end,
>> everything that we configure in Kconfig is implementation details.
> 
> 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 
> require the Sonics Silicon Backplane support.

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/

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

[Stefan Richter]

Adrian Bunk wrote:
> On Sun, Jan 06, 2008 at 12:29:46PM +0100, Stefan Richter wrote:
>> Adrian Bunk wrote:
>>> Duplicating the structure in each UI should be an improvement?
>>>
>>> Hardly.
>> What do you mean?
...
> 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.

All correct.

> 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 
> simply not true.

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/

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

[Adrian Bunk]

On Sun, Jan 06, 2008 at 01:18:48PM +0100, Stefan Richter wrote:
> Adrian Bunk wrote:
> > On Sun, Jan 06, 2008 at 01:35:21AM +0100, Stefan Richter wrote:
> >> Adrian Bunk wrote:
> >>> 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.
> >> What is an implementation detail and what is not?  In the end,
> >> everything that we configure in Kconfig is implementation details.
> > 
> > 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 
> > require the Sonics Silicon Backplane support.
> 
> 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.

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.

> 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

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

[Stefan Richter]

Adrian Bunk wrote:
> On Sun, Jan 06, 2008 at 12:54:04PM +0100, Stefan Richter wrote:
>> 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...
> 
> That's a different UI problem that has to be fixed.
> 
> The "SCSI support type" menu has to move out of the SCSI menu.

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/

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

[Adrian Bunk]

On Sun, Jan 06, 2008 at 01:32:35PM +0100, Stefan Richter wrote:
> Adrian Bunk wrote:
> > On Sun, Jan 06, 2008 at 12:29:46PM +0100, Stefan Richter wrote:
> >> Adrian Bunk wrote:
> >>> Duplicating the structure in each UI should be an improvement?
> >>>
> >>> Hardly.
> >> What do you mean?
> ...
> > 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.
> 
> All correct.
> 
> > 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 
> > simply not true.
> 
> 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.

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 
didn't like often turn out to be good, so feel free to prove me wrong.

> 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

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

[Stefan Richter]

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/

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

[Stefan Richter]

Adrian Bunk wrote:
> On Sun, Jan 06, 2008 at 01:32:35PM +0100, Stefan Richter wrote:
>> No, the dependency relationships alone do not carry enough information.
>>   I am aware of that.
>>
>> For example, we certainly want [...]
> 
> I don't think your implementation would result in a better UI.

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/

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

[Adrian Bunk]

On Sun, Jan 06, 2008 at 02:13:09PM +0100, Stefan Richter wrote:
> 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.

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

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 
use for the users, and that's a bad deal.

> 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

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

[Stefan Richter]

David Lang wrote:
> On Sun, 6 Jan 2008, Stefan Richter wrote:
>> Module autoloading is quite different.
> 
> 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?

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/

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

[Sam Ravnborg]

> 
> You miss the fundamental point:

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

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

[Stefan Richter]

Adrian Bunk wrote:
> On Sun, Jan 06, 2008 at 02:13:09PM +0100, Stefan Richter wrote:
>> Module autoloading is quite different.
> 
> 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 
> any questions.

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

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

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
points I listed.

> You want to make an UI easier to use for the developers but harder to 
> use for the users, and that's a bad deal.

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/

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

[Stefan Richter]

david@lang.hm wrote:
> On Sun, 6 Jan 2008, Stefan Richter wrote:
>> build-time configuration has to deal with different, more
>> complex questions than run-time configuration.
...
> 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.
...

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/

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

[Stefan Richter]

Al Boldi wrote:
> Sam Ravnborg wrote:
>> 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.
> 
> 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

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/

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

[david]

On Sun, 6 Jan 2008, Stefan Richter wrote:

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

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

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

[david]

On Sun, 6 Jan 2008, Stefan Richter wrote:

> David Lang wrote:
>> On Sun, 6 Jan 2008, Stefan Richter wrote:
>>> Module autoloading is quite different.
>>
>> 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?
>
> 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.

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

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

[Al Boldi]

Stefan Richter wrote:
> Al Boldi wrote:
> > Sam Ravnborg wrote:
> >> 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.
> >
> > 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
>
> Still wrong. SCSI also needs HAS_DMA and SCSI_DMA.

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

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

[Alan Stern]

On Sun, 6 Jan 2008 david@lang.hm wrote:

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

One thing is worth pointing out here.  If you do remove some drivers 
(like usb-storage), you may end up with a bloated configuration because 
the things they selected (like SCSI) won't get removed automatically.  
That's a disadvantage of using select.

Another disadvantage appears when somebody tries by hand to remove a 
component (like SCSI) and finds that it magically reappears.  Evidently 
something is selecting it, but there's no way to find out what.

Alan Stern

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

[Stefan Richter]

Al Boldi wrote:
> Stefan Richter wrote:
>> Al Boldi wrote:
>>>   	menuconfig USB_STORAGE
>>>   	tristate "USB Mass Storage support"
>>> -	depends on USB && SCSI
>>> +	depends on USB && BLOCK
>>> +	select SCSI
>> Still wrong. SCSI also needs HAS_DMA and SCSI_DMA.
> 
> I don't think so.  SCSI selects SCSI_DMA, it doesn't depend on it.

"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
it whenever HAS_DMA != n.

> So it's safe to select SCSI here, as libata does it the same way.

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/

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

[Stefan Richter]

Stefan Richter wrote:
> Al Boldi wrote:
>> Stefan Richter wrote:
>>> Still wrong. SCSI also needs HAS_DMA and SCSI_DMA.
>> I don't think so.  SCSI selects SCSI_DMA, it doesn't depend on it.
> 
> "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
> it whenever HAS_DMA != n.

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/

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

[Stefan Richter]

Alan Stern wrote:
> Another disadvantage appears when somebody tries by hand to remove a 
> component (like SCSI) and finds that it magically reappears.  Evidently 
> something is selecting it, but there's no way to find out what.

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/

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

[Sam Ravnborg]

On Sun, Jan 06, 2008 at 06:50:43PM +0100, Stefan Richter wrote:
> Al Boldi wrote:
> > Stefan Richter wrote:
> >> Al Boldi wrote:
> >>>   	menuconfig USB_STORAGE
> >>>   	tristate "USB Mass Storage support"
> >>> -	depends on USB && SCSI
> >>> +	depends on USB && BLOCK
> >>> +	select SCSI
> >> Still wrong. SCSI also needs HAS_DMA and SCSI_DMA.
> > 
> > I don't think so.  SCSI selects SCSI_DMA, it doesn't depend on it.
> 
> "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
> it whenever HAS_DMA != n.
> 
> > So it's safe to select SCSI here, as libata does it the same way.
> 
> Sam, does kconfig recursively follow select statements and switch on
> options which are select'ed by select'ed options?  I suppose it doesn't.

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
you will see all symbols saved.


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

This should be semantic equivalent and much easier to understand.

	Sam