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

[Adrian Bunk]

On Sat, Sep 15, 2007 at 05:27:24PM +0200, Stefan Richter wrote:
> Adrian Bunk wrote:
> > On Sat, Sep 15, 2007 at 04:11:45PM +0200, Stefan Richter wrote:
> >> Perfect is in the eye of the beholder.  You would consequently have to
> >> add such options into all menus which contain scsi low-level providers.
> > 
> > Kconfig is a user interface, so perfect is what is best for the
> > kconfig users.
> 
> Duplicate options with different names in different menus, but which all
> do the same, --- is this the best for users?

Different to your approach of trying to achieve the same with one huge 
help text I see a realistic chance of it working.

What's other alternatives do we have?

Automatically select BLK_DEV_SD and BLK_DEV_SR if one driver that uses 
the SCSI layer gets enabled by the user?

> >> Also, one more question on whether CONFIG_SCSI ought to be 'select'ed:
> >> Where do scsi-core options like CONFIG_SCSI_CONSTANTS go?
> > 
> > The first question is whether it's for actual SCSI hardware [1] or for 
> > the block layer functionality which the SCSI subsystem has become.
> > The mixture of these two is the root of much user confusion.
> > 
> > With the help text "The error messages regarding your SCSI hardware will 
> > be easier to understand if you say Y here" a user wouldn't have expected 
> > to see you using it in a firewire driver.
> 
> FireWire hardware which implements SBP-2 is SCSI hardware...  But this
> detail aside --- yes, of course this help text is old and misleading.
> 
> > But unless I miss anything, 
> > the setting of SCSI_SCAN_ASYNC does only affect "real" SCSI hardware.
> 
> It affects every hardware which is driven by scsi low-level providers
> which have been integrated with the SCSI_SCAN_ASYNC facility.
> 
> > If you check each option and place it either in the generic storage menu 
> > or the SCSI lowlevel menu this would fix much possible user confusion.
> > 
> > But these are relatively unimportant options compared to e.g.
> > USB_STORAGE=y, BLK_DEV_SD=n, which is a misconfiguration many
> > users run into, so having one menu somewhere with these advanced 
> > options should be enough.
> 
> True.
> 
> So,
>     config SCSI_CONSTANTS
>         "Kernel log messages from the SCSI subsystem will be easier to
>         understand if you say Y here..."
> would say what this option really does.  But to some degree the need to
> explain what the SCSI subsystem or SCSI core is and which other
> subsystems make use of it remains.  Maybe it's OK to provide
> documentation of this kind outside of Kconfig help though.

This is a debug option and it's unlikely that users will need it unless 
someone explicitely requested them to do so, so it's not such an 
important issue.

> > [1] SCSI as in "sold as SCSI"
> 
> Difficult.  Does e.g. hardware sold as SAS count as "sold as SCSI"?  How
> about SBP-2 then?  ;-)

If SBP-2 is what you get in a shop when asking for an external
Firewire disk enclosure then it's not sold as 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/