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 S
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
w
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
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
On Sun, 6 Jan 2008 [EMAIL PROTECTED] 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 d
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 U
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
[EMAIL PROTECTED] 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 f
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 an
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 b
>
> 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 b
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 wi
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 assembl
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.)
Di
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'
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 CD
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?
> ...
> >
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 "
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 implementati
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-lik
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 impl
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 withi
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 menu
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
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 is
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
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
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 an
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 imple
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
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 <[EMAIL PROTECTED]>
Cc: Greg KH <[EMA
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 <[EMAIL PROTECTED]>
>
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 <[EMAIL PROTECTED]>
> > Cc: Greg KH <[EMAIL PROTECTED]>
> > Cc: Andrew Morton <[EMAIL PROTECTED]>
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 R
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 ne
On Sat, 5 Jan 2008 18:41:39 +0300 Al Boldi wrote:
>
> Select SCSI for USB Mass Storage support.
>
>
> Cc: David Brownell <[EMAIL PROTECTED]>
> Cc: Greg KH <[EMAIL PROTECTED]>
> Cc: Andrew Morton <[EMAIL PROTECTED]>
> Signed-off-by: Al Boldi <[EMAIL PROTECTED]>
>
> ---
>
> --- 23.a/drivers/usb
Select SCSI for USB Mass Storage support.
Cc: David Brownell <[EMAIL PROTECTED]>
Cc: Greg KH <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Al Boldi <[EMAIL PROTECTED]>
---
--- 23.a/drivers/usb/storage/Kconfig
+++ 23.b/drivers/usb/storage/Kconfig
@@ -2,14 +2,10 @@
#
37 matches
Mail list logo
