mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Al Boldi <a1426z@gawab.com>
To: David Brownell <david-b@pacbell.net>, jengelh@computergmbh.de
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, greg@kroah.com
Subject: Re: [RFC] USB Kconfig: Declutter USB Kconfig Menu
Date: Sat, 22 Dec 2007 09:51:57 +0300	[thread overview]
Message-ID: <200712220951.57634.a1426z@gawab.com> (raw)
In-Reply-To: <20071222061919.A5B1D1915EF@adsl-69-226-248-13.dsl.pltn13.pacbell.net>

David Brownell wrote:
> > > The driver stacks are independent of each other, except for common
> > > data structures like what's in the <linux/usb/ch9.h> header file.  I
> > > think there's no real point, other than history, to having both sides
> > > share the same menu.
> >
> > They aren't.
>
> How can you say that, when you showed (right above!!) that they are???
> Sure, there are submenus too.  But they're clearly in the same menu.

Well, in that case even if you moved them to the upper level, then they would 
still be in the same menu, if that's what you mean.

> >	USB Gadget Support is in its own sub-menu.  And strictly
> > speaking, Host-side USB should be too, but some people may feel that
> > this would be nesting it too deep, and so it unfolds in the same menu.
>
> Which is why my suggestion was to have them both move up a level, with
> host and peripheral side menus nested normally:
>
> 	Device Drivers:
> 		...
> 		[ ] HID devices
> 		< > Host side USB
> 		< > Peripheral side USB
> 		< > MMC/SD/SDIO card support
> 		[ ] LED support
> 		...
>
> That way both host and peripheral side support would have their own
> menu, and that pointless nesting would be reduced.

You mean:
 		[ ] Host side USB
 		[ ] Peripheral side USB

Right?

All this does is loose the USB menu, which was used to group them and to 
un-clutter the Device Drivers menu.  Note:  They would still be sharing the 
same menu, only this time it's the Device Drivers menu.

I guess it's a judgment call.  Let's see what others think.


Thanks!

--
Al


  reply	other threads:[~2007-12-22  6:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-21 13:30 Al Boldi
2007-12-21 21:16 ` Jan Engelhardt
2007-12-21 23:58   ` David Brownell
     [not found]     ` <200712220806.24730.a1426z@gawab.com>
2007-12-22  6:19       ` David Brownell
2007-12-22  6:51         ` Al Boldi [this message]
2007-12-22  7:22           ` David Brownell
2007-12-22 13:49             ` Al Boldi
2007-12-23  6:07               ` David Brownell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200712220951.57634.a1426z@gawab.com \
    --to=a1426z@gawab.com \
    --cc=david-b@pacbell.net \
    --cc=greg@kroah.com \
    --cc=jengelh@computergmbh.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®