[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4780E814.4050405@s5r6.in-berlin.de>
Date:	Sun, 06 Jan 2008 15:39:16 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Al Boldi <a1426z@...ab.com>
CC:	Sam Ravnborg <sam@...nborg.org>, Adrian Bunk <bunk@...nel.org>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	David Brownell <david-b@...bell.net>, Greg KH <greg@...ah.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 2/5] USB Kconfig: Select SCSI for USB Mass Storage support
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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Powered by blists - more mailing lists
 
