[PATCH 0/5] USB Kconfig: Reorganize USB Kconfig Menu

[PATCH 0/5] USB Kconfig: Reorganize USB Kconfig Menu

[Al Boldi]

Reorganize USB Kconfig Menu, and move USB_GADGET out into the Device Driver
Menu.  This helps the USB Kconfig Menu to be more logical/usable.

Patchset against 2.6.23

 arch/arm/Kconfig            |    2 ++
 arch/v850/Kconfig           |    2 ++
 drivers/Kconfig             |    2 ++
 drivers/usb/Kconfig         |   26 ++++++++++++--------------
 drivers/usb/atm/Kconfig     |   12 ++++++------
 drivers/usb/class/Kconfig   |    6 +++++-
 drivers/usb/core/Kconfig    |    7 +++++++
 drivers/usb/gadget/Kconfig  |   10 +++++-----
 drivers/usb/host/Kconfig    |    3 ++-
 drivers/usb/image/Kconfig   |    7 ++++++-
 drivers/usb/misc/Kconfig    |    6 +++++-
 drivers/usb/serial/Kconfig  |   10 ++++------
 drivers/usb/storage/Kconfig |   25 ++++++++++++++-----------
 13 files changed, 72 insertions(+), 46 deletions(-)



Thanks!

--
Al

Re: [PATCH 0/5] USB Kconfig: Reorganize USB Kconfig Menu

[Greg KH]

On Sat, Jan 05, 2008 at 06:40:38PM +0300, Al Boldi wrote:
> 
> Reorganize USB Kconfig Menu, and move USB_GADGET out into the Device Driver
> Menu. ?This helps the USB Kconfig Menu to be more logical/usable.
> 
> Patchset against 2.6.23

So what was the final verdict in this patch set?

Can you rsend this against 2.6.24-rc7 with the requested changes (if
any) in it?

thanks,

greg k-h

Re: [PATCH 0/5] USB Kconfig: Reorganize USB Kconfig Menu

[Al Boldi]

Greg KH wrote:
> On Sat, Jan 05, 2008 at 06:40:38PM +0300, Al Boldi wrote:
> > Reorganize USB Kconfig Menu, and move USB_GADGET out into the Device
> > Driver Menu. ?This helps the USB Kconfig Menu to be more logical/usable.
> >
> > Patchset against 2.6.23
>
> So what was the final verdict in this patch set?

IMHO, it's a lot better than what we have right now, and it's split up so 
that you can pick and choose what you think is useful.

> Can you rsend this against 2.6.24-rc7 with the requested changes (if
> any) in it?

The only critical change is in patch 2/5:

        menuconfig USB_STORAGE
        tristate "USB Mass Storage support"
-       depends on USB && SCSI
+       depends on USB && BLOCK
+       select SCSI


I was hoping you could take care of it, or maybe wait until 2.6.25 is out.


Thanks!

--
Al

Re: [PATCH 0/5] USB Kconfig: Reorganize USB Kconfig Menu

[Greg KH]

On Sat, Jan 12, 2008 at 01:20:46PM +0300, Al Boldi wrote:
> Greg KH wrote:
> > On Sat, Jan 05, 2008 at 06:40:38PM +0300, Al Boldi wrote:
> > > Reorganize USB Kconfig Menu, and move USB_GADGET out into the Device
> > > Driver Menu. ?This helps the USB Kconfig Menu to be more logical/usable.
> > >
> > > Patchset against 2.6.23
> >
> > So what was the final verdict in this patch set?
> 
> IMHO, it's a lot better than what we have right now, and it's split up so 
> that you can pick and choose what you think is useful.
> 
> > Can you rsend this against 2.6.24-rc7 with the requested changes (if
> > any) in it?
> 
> The only critical change is in patch 2/5:
> 
>         menuconfig USB_STORAGE
>         tristate "USB Mass Storage support"
> -       depends on USB && SCSI
> +       depends on USB && BLOCK
> +       select SCSI
> 
> 
> I was hoping you could take care of it, or maybe wait until 2.6.25 is out.

Well, if you want such a change to go into 2.6.25, I need the patches
now :)

So, can you respin these against 2.6.24-rc7, with the above fix, so that
I can apply them and test them out?

thanks,

greg k-h

Re: [PATCH 0/5] USB Kconfig: Reorganize USB Kconfig Menu

[Al Boldi]

Greg KH wrote:
> On Sat, Jan 12, 2008 at 01:20:46PM +0300, Al Boldi wrote:
> > Greg KH wrote:
> > > On Sat, Jan 05, 2008 at 06:40:38PM +0300, Al Boldi wrote:
> > > > Reorganize USB Kconfig Menu, and move USB_GADGET out into the Device
> > > > Driver Menu. ?This helps the USB Kconfig Menu to be more
> > > > logical/usable.
> > > >
> > > > Patchset against 2.6.23
> > >
> > > So what was the final verdict in this patch set?
> >
> > IMHO, it's a lot better than what we have right now, and it's split up
> > so that you can pick and choose what you think is useful.
> >
> > > Can you rsend this against 2.6.24-rc7 with the requested changes (if
> > > any) in it?
> >
> > The only critical change is in patch 2/5:
> >
> >         menuconfig USB_STORAGE
> >         tristate "USB Mass Storage support"
> > -       depends on USB && SCSI
> > +       depends on USB && BLOCK
> > +       select SCSI
> >
> >
> > I was hoping you could take care of it, or maybe wait until 2.6.25 is
> > out.
>
> Well, if you want such a change to go into 2.6.25, I need the patches
> now :)
>
> So, can you respin these against 2.6.24-rc7, with the above fix, so that
> I can apply them and test them out?

Not so easy, as I don't have rc7 available.  You know, dialup.


Thanks!

--
Al

Re: [PATCH 0/5] USB Kconfig: Reorganize USB Kconfig Menu

[Stefan Richter]

Greg KH wrote:
> On Sat, Jan 12, 2008 at 01:20:46PM +0300, Al Boldi wrote:
>> Greg KH wrote:
>>> On Sat, Jan 05, 2008 at 06:40:38PM +0300, Al Boldi wrote:
>>>> Reorganize USB Kconfig Menu, and move USB_GADGET out into the Device
>>>> Driver Menu. ?This helps the USB Kconfig Menu to be more logical/usable.
>>>>
>>>> Patchset against 2.6.23
>>> So what was the final verdict in this patch set?
>> IMHO, it's a lot better than what we have right now, and it's split up so 
>> that you can pick and choose what you think is useful.
>>
>>> Can you rsend this against 2.6.24-rc7 with the requested changes (if
>>> any) in it?
>> The only critical change is in patch 2/5:
>>
>>         menuconfig USB_STORAGE
>>         tristate "USB Mass Storage support"
>> -       depends on USB && SCSI
>> +       depends on USB && BLOCK
>> +       select SCSI
>>
>>
>> I was hoping you could take care of it, or maybe wait until 2.6.25 is out.
> 
> Well, if you want such a change to go into 2.6.25, I need the patches
> now :)
> 
> So, can you respin these against 2.6.24-rc7, with the above fix, so that
> I can apply them and test them out?

May I repeat my request that nobody does "select SCSI", please?

Al Boldy, would you please explain like I asked you:
  - what is wrong with the current solution which tells the user to
    first enable SCSI to get the USB_STORAGE option,
  - whether there are frequent end-user requests which demonstrate
    that many people currently don't realize how to enable USB_STORAGE.

Please use "select" carefully, particularly *only* for options which
enable simple compact library-like code which
  - is small,
  - doesn't itself depend on anything,
  - doesn't has further configuration options in some other menu.
None of this applies to CONFIG_SCSI.
-- 
Stefan Richter
-=====-==--- ---= -==-=
http://arcgraph.de/sr/

Re: [PATCH 0/5] USB Kconfig: Reorganize USB Kconfig Menu

[Randy Dunlap]

On Sun, 13 Jan 2008 12:50:16 +0100 Stefan Richter wrote:

> Greg KH wrote:
> > On Sat, Jan 12, 2008 at 01:20:46PM +0300, Al Boldi wrote:
> >> Greg KH wrote:
> >>> On Sat, Jan 05, 2008 at 06:40:38PM +0300, Al Boldi wrote:
> >>>> Reorganize USB Kconfig Menu, and move USB_GADGET out into the Device
> >>>> Driver Menu. ?This helps the USB Kconfig Menu to be more logical/usable.
> >>>>
> >>>> Patchset against 2.6.23
> >>> So what was the final verdict in this patch set?
> >> IMHO, it's a lot better than what we have right now, and it's split up so 
> >> that you can pick and choose what you think is useful.
> >>
> >>> Can you rsend this against 2.6.24-rc7 with the requested changes (if
> >>> any) in it?
> >> The only critical change is in patch 2/5:
> >>
> >>         menuconfig USB_STORAGE
> >>         tristate "USB Mass Storage support"
> >> -       depends on USB && SCSI
> >> +       depends on USB && BLOCK
> >> +       select SCSI
> >>
> >>
> >> I was hoping you could take care of it, or maybe wait until 2.6.25 is out.
> > 
> > Well, if you want such a change to go into 2.6.25, I need the patches
> > now :)
> > 
> > So, can you respin these against 2.6.24-rc7, with the above fix, so that
> > I can apply them and test them out?
> 
> May I repeat my request that nobody does "select SCSI", please?
> 
> Al Boldy, would you please explain like I asked you:
>   - what is wrong with the current solution which tells the user to
>     first enable SCSI to get the USB_STORAGE option,
>   - whether there are frequent end-user requests which demonstrate
>     that many people currently don't realize how to enable USB_STORAGE.
> 
> Please use "select" carefully, particularly *only* for options which
> enable simple compact library-like code which
>   - is small,
>   - doesn't itself depend on anything,
>   - doesn't has further configuration options in some other menu.
> None of this applies to CONFIG_SCSI.
> -- 

I second all of that.

---
~Randy

Re: [PATCH 0/5] USB Kconfig: Reorganize USB Kconfig Menu

[Al Boldi]

Stefan Richter wrote:
> Greg KH wrote:
> > On Sat, Jan 12, 2008 at 01:20:46PM +0300, Al Boldi wrote:
> >> Greg KH wrote:
> >>> On Sat, Jan 05, 2008 at 06:40:38PM +0300, Al Boldi wrote:
> >>>> Reorganize USB Kconfig Menu, and move USB_GADGET out into the Device
> >>>> Driver Menu. ?This helps the USB Kconfig Menu to be more
> >>>> logical/usable.
> >>>>
> >>>> Patchset against 2.6.23
> >>>
> >>> So what was the final verdict in this patch set?
> >>
> >> IMHO, it's a lot better than what we have right now, and it's split up
> >> so that you can pick and choose what you think is useful.
> >>
> >>> Can you rsend this against 2.6.24-rc7 with the requested changes (if
> >>> any) in it?
> >>
> >> The only critical change is in patch 2/5:
> >>
> >>         menuconfig USB_STORAGE
> >>         tristate "USB Mass Storage support"
> >> -       depends on USB && SCSI
> >> +       depends on USB && BLOCK
> >> +       select SCSI
> >>
> >>
> >> I was hoping you could take care of it, or maybe wait until 2.6.25 is
> >> out.
> >
> > Well, if you want such a change to go into 2.6.25, I need the patches
> > now :)
> >
> > So, can you respin these against 2.6.24-rc7, with the above fix, so that
> > I can apply them and test them out?
>
> May I repeat my request that nobody does "select SCSI", please?
>
> Al Boldy, would you please explain like I asked you:
>   - what is wrong with the current solution which tells the user to
>     first enable SCSI to get the USB_STORAGE option,
>   - whether there are frequent end-user requests which demonstrate
>     that many people currently don't realize how to enable USB_STORAGE.
>
> Please use "select" carefully, particularly *only* for options which
> enable simple compact library-like code which
>   - is small,
>   - doesn't itself depend on anything,
>   - doesn't has further configuration options in some other menu.
> None of this applies to CONFIG_SCSI.

I thought we discussed this before.  We do it here, for the same reasons 
libata does it.  In any case, the patch is optional.


Thanks!

--
Al

Re: [PATCH 0/5] USB Kconfig: Reorganize USB Kconfig Menu

[Greg KH]

On Mon, Jan 14, 2008 at 01:21:51PM +0300, Al Boldi wrote:
> Stefan Richter wrote:
> > Greg KH wrote:
> > > On Sat, Jan 12, 2008 at 01:20:46PM +0300, Al Boldi wrote:
> > >> Greg KH wrote:
> > >>> On Sat, Jan 05, 2008 at 06:40:38PM +0300, Al Boldi wrote:
> > >>>> Reorganize USB Kconfig Menu, and move USB_GADGET out into the Device
> > >>>> Driver Menu. ?This helps the USB Kconfig Menu to be more
> > >>>> logical/usable.
> > >>>>
> > >>>> Patchset against 2.6.23
> > >>>
> > >>> So what was the final verdict in this patch set?
> > >>
> > >> IMHO, it's a lot better than what we have right now, and it's split up
> > >> so that you can pick and choose what you think is useful.
> > >>
> > >>> Can you rsend this against 2.6.24-rc7 with the requested changes (if
> > >>> any) in it?
> > >>
> > >> The only critical change is in patch 2/5:
> > >>
> > >>         menuconfig USB_STORAGE
> > >>         tristate "USB Mass Storage support"
> > >> -       depends on USB && SCSI
> > >> +       depends on USB && BLOCK
> > >> +       select SCSI
> > >>
> > >>
> > >> I was hoping you could take care of it, or maybe wait until 2.6.25 is
> > >> out.
> > >
> > > Well, if you want such a change to go into 2.6.25, I need the patches
> > > now :)
> > >
> > > So, can you respin these against 2.6.24-rc7, with the above fix, so that
> > > I can apply them and test them out?
> >
> > May I repeat my request that nobody does "select SCSI", please?
> >
> > Al Boldy, would you please explain like I asked you:
> >   - what is wrong with the current solution which tells the user to
> >     first enable SCSI to get the USB_STORAGE option,
> >   - whether there are frequent end-user requests which demonstrate
> >     that many people currently don't realize how to enable USB_STORAGE.
> >
> > Please use "select" carefully, particularly *only* for options which
> > enable simple compact library-like code which
> >   - is small,
> >   - doesn't itself depend on anything,
> >   - doesn't has further configuration options in some other menu.
> > None of this applies to CONFIG_SCSI.
> 
> I thought we discussed this before.  We do it here, for the same reasons 
> libata does it.  In any case, the patch is optional.

Yes, I do not want to do this, as we went round and round on it in the
past many times over the years.  It should be left as-is.

thanks,

greg k-h

Re: [PATCH 0/5] USB Kconfig: Reorganize USB Kconfig Menu

[Stefan Richter]

Greg KH wrote:
> On Mon, Jan 14, 2008 at 01:21:51PM +0300, Al Boldi wrote:
>> Stefan Richter wrote:
>>> would you please explain like I asked you:
>>>   - what is wrong with the current solution which tells the user to
>>>     first enable SCSI to get the USB_STORAGE option,
>>>   - whether there are frequent end-user requests which demonstrate
>>>     that many people currently don't realize how to enable USB_STORAGE.
...
>> I thought we discussed this before.  We do it here, for the same reasons 
>> libata does it.  In any case, the patch is optional.

Al,
I admit I haven't read everything of the discussion.  So, sorry if I got
on your nerves.  (However, http://lkml.org/lkml/2008/1/5/151 and
http://lkml.org/lkml/2008/1/5/209 didn't yield responses which addressed
the mentioned points.  Also, "libata's reasons for doing so apply to
usb-storage as well" is not a fact-based answer to these points either.
Anyway, sorry if I missed an according response elsewhere.)

> Yes, I do not want to do this, as we went round and round on it in the
> past many times over the years.  It should be left as-is.

I'm relieved.  :-)
-- 
Stefan Richter
-=====-==--- ---= -===-
http://arcgraph.de/sr/