From: David Brownell <david-b@pacbell.net>
To: Patrick Mochel <mochel@osdl.org>, Greg KH <greg@kroah.com>
Cc: Dave Jones <davej@suse.de>,
linux-usb-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [linux-usb-devel] Re: [PATCH] driverfs support for USB - take 2
Date: Tue, 29 Jan 2002 18:15:13 -0800 [thread overview]
Message-ID: <08cf01c1a933$f45ac460$6800000a@brownell.org> (raw)
In-Reply-To: <Pine.LNX.4.33.0201291711560.800-100000@segfault.osdlab.org>
> > > > Yes, I need to have better names for the devices than just "usb_bus",
> > > > any suggestions? These devices nodes are really the USB root hubs in
> > > > the USB controller, so they could just have the USB number as the name
> > > > like the other USB devices (001), but that's pretty boring :)
Actually one of my criticisms of Greg's patch is that
it hides the actual device tree. The root hub is easily
distinguishable, it's the topmost one in the tree! There
should be no need to name it specially.
I'd really rather move away from the model which
exposes a USB bus as a flat non-hierarchical
setup, and move instead to a model reflects the
actual topology of the USB devices and hubs.
> > > "usb_root0" .. "usb_rootN" ?
> >
> > Hm, that's a good idea, it would match the usbfs bus numbers which
> > should keep people happy.
>
> Would it be usb_rootN or usb_busN?
I'd rather see neither, and have the device names reflect
physical topology ... so they could make sense to users.
For example, if you plug a USB device into a particular
USB socket it would have a particular name, and that
name would show up in diagnostics. So when something
goes flakey about the device, the diagnostic will be able
to completely identify it. And likewise, when userspace
tools need to do something, they should be able to use
the same pathname each time, unless the devices got
re-cabled ... re-enumerating shouldn't affect those names.
The notion of a "bus number" is bothersome, since it's
a function only of the order of driver initialization, and that
isn't a "stable" way to identify anything. Re-ordering
driver initialization shouldn't change device name.
- Dave
next prev parent reply other threads:[~2002-01-30 2:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-30 0:24 [PATCH] driverfs support for USB - take 2 Greg KH
2002-01-30 1:03 ` Dave Jones
2002-01-30 1:09 ` Greg KH
2002-01-30 1:19 ` Patrick Mochel
2002-01-30 2:15 ` David Brownell [this message]
2002-01-30 4:09 ` Greg KH
2002-01-30 20:07 ` [linux-usb-devel] " David Brownell
2002-02-02 0:18 ` Greg KH
2002-02-02 19:13 ` David Brownell
2002-02-05 6:49 ` Greg KH
2002-01-30 1:49 ` [linux-usb-devel] " Stephen J. Gowdy
2002-01-30 4:10 ` Greg KH
2002-01-30 18:26 ` Patrick Mochel
2002-01-30 20:24 ` [linux-usb-devel] " David Brownell
2002-02-02 0:23 ` Greg KH
2002-02-02 19:27 ` David Brownell
2002-01-31 12:49 ` Pavel Machek
2002-02-01 9:27 ` Horst von Brand
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='08cf01c1a933$f45ac460$6800000a@brownell.org' \
--to=david-b@pacbell.net \
--cc=davej@suse.de \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=mochel@osdl.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