public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: jw@pegasys.ws
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Does sysfs really provides persistent hardware path to devices?
Date: Tue, 19 Aug 2003 10:56:10 -0700	[thread overview]
Message-ID: <3F4264BA.3020207@pacbell.net> (raw)

> That's nice.  Now add a second camera from the same vendor
> :(  No, i don't expect you to be able to uniquely identify
> identical devices being added and removed from a single USB buss
> in a persistent way.  But it would be nice if we could get
> consistency between busses so that a mouse on one USB buss
> weren't confused with a mouse on another USB buss.

Well the add/remove part is potentially an issue, depending
on how you run things.  The conventional solution, used
with other serial lines since long before UNIX, is labeling
ports according to what should be plugged in to them.

There's a usb_device->devpath field that provides a stable
topological identifier for devices within a USB bus, each id
corresponding to one of those port labels.  That field is
merged into sysfs bus_id values for USB.

It's not so nice for bus identifiers themselves, "usbN".
Though clearly there's a physical path there too, and it's
normally stable enough that PCI slot names won't change.
(Except on high end systems, where the topology may be
more stable than the bus numbers ... but we don't have
anything like usb_device->devpath for use with PCI.)

So the problem is how to munch the sysfs information into
the persistent path information you want.  It's demonstrably
doable ... though it does look to be a PITA.

- Dave


             reply	other threads:[~2003-08-19 18:04 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-19 17:56 David Brownell [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-08-18  6:21 "Andrey Borzenkov" 
2003-08-18 20:42 ` your mail Greg KH
2003-08-31 10:54   ` Does sysfs really provides persistent hardware path to devices? Andrey Borzenkov
2003-09-24 21:18     ` Greg KH
2004-01-17 20:34       ` Andrey Borzenkov
2004-01-17 21:34         ` Greg KH
2004-01-19 13:08         ` Olaf Hering
2004-01-19 13:59           ` Andries Brouwer
2004-01-19 14:04             ` Olaf Hering
2004-03-14 11:53           ` Andrey Borzenkov
2004-03-14 19:25             ` Horst von Brand
2003-07-26 16:36 Andrey Borzenkov
2003-07-26 16:43 ` Randy.Dunlap
2003-07-26 16:50 ` Greg KH
2003-07-28 16:44   ` Andrey Borzenkov
2003-07-28 17:03     ` Greg KH
2003-08-17 16:41       ` Andrey Borzenkov
2003-08-17 18:28         ` Greg KH
2003-08-18  2:04           ` jw schultz
2003-08-18 20:47             ` Greg KH
2003-07-26 16:54 ` OSDL
2003-07-26 16:59 ` J.C. Wren
2003-07-26 17:07   ` Greg KH
2003-07-26 22:51   ` Dax Kelson

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=3F4264BA.3020207@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=jw@pegasys.ws \
    --cc=linux-kernel@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