linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* (no subject)
@ 2003-08-18  6:21 "Andrey Borzenkov" 
  2003-08-18 20:42 ` your mail Greg KH
  0 siblings, 1 reply; 25+ messages in thread
From: "Andrey Borzenkov"  @ 2003-08-18  6:21 UTC (permalink / raw)
  To: "jw schultz" ; +Cc: "Greg KH" , linux-kernel


> Actually you have not answered his question.  And i think it
> a reasonable one.  It could be it was answered elsewhere.

No it was not answered. Yes you got this exactly. Aparently my
englisg is not as bad after all ... :)

>>>>> Question: how to configure udev so that "database" always refers to LUN 0
>>>>> on target 0 on bus 0 on HBA in PCI slot 1.
>>> Let's avoid this communication problem. You show me namedev.config line that 
>>> implements the above.

> I'll try to put slightly differently.  I'll concede that we
> cannot positionaly identify USB devices so lets set that
> aside for the nonce.  We can persistently, positionaly
> identify a device within the HBA context (BUS +ID + LUN) and
> should be able to do the same for a PCI HBA (PCI slot +
> device) or (PCI bridge topology).

actually you can. As Greg pointed out, topology rarely changes,
so it gives you enough information (of course if you constantly
add and remove USB hubs it becomes a bit of pain). But it has
the same problem - USB bus grows off PCI bus (usually) so adding
new USB controller possibly invalidates all configuration.

> So can i uniquely identify using persistent positional
> information a drive at PCI_slot=1, HBA_on_card=0, BUS=0,
> ID=1, LUN=0?  And how do i uniquely identify it in the udev
> config file so that adding the same model drive in the same
> BUS+ID+LUN on an same model HBA card in another PCI slot
> does not confuse the two?  If i cannot, can i at least do
> the identification so that adding ID=0,LUN=0 to the scsi buss
> doesn't cause a name change.

yep.

just to show what I expected from sysfs - here is entry from Solaris
/devices:

brw-r-----   1 root     sys       32,240 Jan 24  2002 /devices/pci@16,4000/scsi@5,1/sd@0,0:a

this entry identifies disk partition 0 on drive with SCSI ID 0, LUN 0
connected to bus 1 of controller in slot 5 of PCI bus identified
by 16. Now you can use whatever policy you like to give human
meaningful name to this entry. And if you have USB it will continue
further giving you exact topology starting from the root of your
device tree.

and this path does not contain single logical id so it is not subject
to change if I add the same controller somewhere else.

hopefully it clarifies what I mean ...

regards

-andrey

^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: Does sysfs really provides persistent hardware path to devices?
@ 2003-08-19 17:56 David Brownell
  0 siblings, 0 replies; 25+ messages in thread
From: David Brownell @ 2003-08-19 17:56 UTC (permalink / raw)
  To: jw; +Cc: Linux Kernel Mailing List

> 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


^ permalink raw reply	[flat|nested] 25+ messages in thread
* Does sysfs really provides persistent hardware path to devices?
@ 2003-07-26 16:36 Andrey Borzenkov
  2003-07-26 16:43 ` Randy.Dunlap
                   ` (3 more replies)
  0 siblings, 4 replies; 25+ messages in thread
From: Andrey Borzenkov @ 2003-07-26 16:36 UTC (permalink / raw)
  To: linux-kernel


As far as I can tell sysfs device names include logical bus numbers which 
means, if hardware is added or removed it is possible names do change.
 
Example:

/sys/devices/pci0000:00/0000:00:1f.4/usb2/2-2/2-2.1/2-2.1:0/host1/1:0:0:0

PCI part reflects bus number. Now this example is trivial in that it is 
integrated USB controller so it is unlikely to ever change its number - but 
if it were external controller (and even worse with PCI-to-PCI bridge) it is 
likely that adding extra card would shift all numbers.

And USB part of name starts with logical USB bus number i.e. it is obvious 
that adding one more USB adapter will definitely change it.

So apparently I cannot rely on sysfs to get reliable persistent information 
about physical location of devices.

the point is - I want to create aliases that would point to specific slots. 
I.e. when I plug USB memory stick in upper slot on front panel I'd like to 
always create the same device alias for it.

TIA

-andrey

^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2004-03-14 19:28 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
  -- strict thread matches above, loose matches on Subject: below --
2003-08-19 17:56 David Brownell
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).