Does sysfs really provides persistent hardware path to devices?

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

On Sat, 26 Jul 2003 20:36:13 +0400 Andrey Borzenkov <[email protected]> wrote:

| 
| 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.

You'll probably get a barrage of replies...

You want udev + namedev, userspace naming policy. See the recent udev announcements from Greg Kroah-Hartman.

udev/namedev use sysfs device tree info to apply device naming policy.

<quotes> kernel.org/pub/linux/utils/kernel/hotplug/udev-0.2.tar.gz

There's a BitKeeper tree of the latest stuff available at:
bk://kernel.bkbits.net/gregkh/udev/

I've also placed the slides from my OLS talk up at:

	http://www.kroah.com/linux/talks/ols_2003_udev_talk/

The paper which attempts to explain the background of udev, what it does, and where it is going is at:
http://archive.linuxsymposium.org/ols2003/Proceedings/All-Reprints/Reprint-Kroah-Hartman-OLS2003.pdf
</selected quotes>

There's more in the announcment email. This is still early code, so there's much more to be done on it, but the demo yesterday looked very good.

--
~Randy
| http://developer.osdl.org/rddunlap/ | http://www.xenotime.net/linux/ | For Linux-2.6:
http://www.codemonkey.org.uk/post-halloween-2.5.txt
or http://lwn.net/Articles/39901/
http://www.kernel.org/pub/linux/kernel/people/rusty/modules/

Absolutely.

The fact is, the kernel _cannot_ give persistent names to devices, because it is simply not a problem that is solvable with the resources the kernel has access to.

For persistent naming, you need (a) user policy and (b) stable storage, neither of which the kernel has.

GregKH has a "udev" setup that plugs into /sbin/hotplug and uses sysfs to implement stable naming. So sysfs is part of the picture, but it's not the whole answer.

Right: what you're asking for is persistent per-device user policy.

Linus

Specifically using your example of USB memories, I have seen devices move
around just because of rebooting. I have a Sandisk SDDR-31 (MMC) and a SDDR-33 (CF) that remain plugged into the same USB ports all the time. Occasionally, they come up swapped (normally the MMC reader is /dev/sda), which is really infuriating, since my scripts for building MMC and CF cards then exhibit much breakage.

And whether it's something unique to this motherboard, those devices, or
what, but I've seen any number of times the kernel/modules get into a state where the module cannot be unloaded because the in-use counter is set, yet nothing appears to be using it. When it gets into this state, the device is unusable, and my only recourse is to reboot (just like Windows!)

I haven't had an opportunity to further characterize the problem, but it's
been persistent across 2.4 and 2.5 kernels.

	--John

Test out udev's ability to name devices based on bus topology (the USB bus topology doesn't change for you.) It should solve your problem.

thanks,

greg k-h

man devlabel in Red Hat Linux 9 and above would solve this 100% for you.

Also, the devlabel home page:

http://www.lerhaupt.com/linux.html

and a whitepaper on it:

http://www.dell.com/us/en/esg/topics/power_ps1q03-lerhaupt.htm

That is correct, but you can get pretty close :)

Look at the udev announcement I posted to linux-kernel yesterday to see how to do this.

thanks,

greg k-h

sure, I know. The more annoying is how difficult is to step over this "close" :)

I know udev.

udev does not answer my question. It operates on logical device (bus) numbers. My question was how to name devices based on physical position *independently* of logical numbers they get.

It is not strictly speaking udev fault but simply result of kernel exporting logical device names instead of true physical paths. I miss Solaris /devices filesystem ...

OK I may mot see something obvious. Simple example.

I have SCSI HBA sitting in PCI slot 3. It gets SCSI host number 1. I configure udev to name SCSI device 1.0.0.1 "database"

I add one more SCSI HBA in PCI slot 1. Next time system is booted *this* gets SCSI host number 1 and my first HBA in slot 3 gets SCSI host 2. Oops.

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.

I thank you

-andrey

PS this obviously applies not only to SCSI. It is just it is most simple example and you do not open network interfaces by name so there is *no* way at all to assign their numbers :(

The kernel isn't going to do this. It's a user space issue.

You don't know udev then :)
This is exactly what udev solves. Please read the paper I posted a link to, it should answer your questions.

If you can't rely on scsi position, then you need to look for something that uniquely describes the device. Like a filesystem label, or a uuid on the device. udev can handle this (well I'm still working on the filesystem label, but others have already done the hard work for that to be intregrated easily.)

thanks,

greg k-h

On Monday 28 July 2003 21:03, Greg KH wrote:
[...]

I tried to explain that I can rely on SCSI position but kernel does not give me this SCSI position. Apparently we have some communication problem. You do not understand my question and I do not understand what you do not understand :) I attribute it to my bad English.

Let's avoid this communication problem. You show me namedev.config line that implements the above. If it really does it - it is likely I understand what you mean better and won't bother you with stupid questions anymore. If it does not do it - I can immediately point out where it fails.

OK?

thank you

-andrey

Here's the line that I used in my demo at OLS 2003 for udev:

# USB camera from Fuji to be named "camera" LABEL, BUS="usb", vendor="FUJIFILM", NAME="camera"

This is a scsi device on the USB bus that has the vendor name "FUJIFILM" in it's scsi sysfs directory.

Now, partition issues asside (all partitions of this device will be named camera, camera1, camera2, etc., but I'm working on identifying partitions better) this shows that the vendor of a scsi device is able to be named uniquely.

Does that help? Have you looked at the 2003 OLS paper about udev for more information?

thanks,

greg k-h

<OT>
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. </OT>

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

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).

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.

________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		[email protected]

		Remember Cernan and Schmitt

Then don't use that rule :)

If there is _no_ unique way to identify the device, that that is impossible.

We already have that today, it's called /dev/mice :)

Seriously, I support topology positions, that solves this problem for real.

I don't think I really understand the question. Given a specific question, I think I could.

Um, you can, see the topology stuff.

Yup, that works too.

Use that position as a topology/name indicator.

Again, use the topology position.

Please, go read the paper and look at sysfs before asking anything else...

thanks,

greg k-h