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.
>From Greg's version 0.2 announcement:
<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/
Andrey Borzenkov 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.
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.
> 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.
Right: what you're asking for is persistent per-device user policy.
Linus
On Sat, Jul 26, 2003 at 08:36:13PM +0400, Andrey Borzenkov wrote:
>
> So apparently I cannot rely on sysfs to get reliable persistent information
> about physical location of devices.
That is correct, but you can get pretty close :)
> 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.
Look at the udev announcement I posted to linux-kernel yesterday to see
how to do this.
thanks,
greg k-h
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
On Saturday 26 July 2003 12:36 pm, Andrey Borzenkov 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.
>
> TIA
>
> -andrey
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Sat, Jul 26, 2003 at 12:59:03PM -0400, J.C. Wren wrote:
> 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.
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
On Sat, 2003-07-26 at 10:59, J.C. Wren wrote:
> 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.
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
On Mon, Jul 28, 2003 at 08:44:43PM +0400, Andrey Borzenkov wrote:
> On Saturday 26 July 2003 20:50, Greg KH wrote:
> > On Sat, Jul 26, 2003 at 08:36:13PM +0400, Andrey Borzenkov wrote:
> > > So apparently I cannot rely on sysfs to get reliable persistent
> > > information about physical location of devices.
> >
> > That is correct, but you can get pretty close :)
> >
>
> sure, I know. The more annoying is how difficult is to step over this "close"
> :)
The kernel isn't going to do this. It's a user space issue.
> > > 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.
> >
> > Look at the udev announcement I posted to linux-kernel yesterday to see
> > how to do this.
> >
>
> 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.
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.
> 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.
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 Saturday 26 July 2003 20:50, Greg KH wrote:
> On Sat, Jul 26, 2003 at 08:36:13PM +0400, Andrey Borzenkov wrote:
> > So apparently I cannot rely on sysfs to get reliable persistent
> > information about physical location of devices.
>
> That is correct, but you can get pretty close :)
>
sure, I know. The more annoying is how difficult is to step over this "close"
:)
> > 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.
>
> Look at the udev announcement I posted to linux-kernel yesterday to see
> how to do this.
>
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.
> thanks,
>
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 :(
On Monday 28 July 2003 21:03, Greg KH wrote:
[...]
> > 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.
>
> 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.)
>
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
On Sun, Aug 17, 2003 at 08:41:31PM +0400, Andrey Borzenkov wrote:
> On Monday 28 July 2003 21:03, Greg KH wrote:
> [...]
> > > 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.
> >
> > 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.)
> >
>
> 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.
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
On Sun, Aug 17, 2003 at 11:28:47AM -0700, Greg KH wrote:
> On Sun, Aug 17, 2003 at 08:41:31PM +0400, Andrey Borzenkov wrote:
> > On Monday 28 July 2003 21:03, Greg KH wrote:
> > [...]
> > > > 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.
> > >
> > > 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.)
> > >
> >
> > 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.
>
> 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.
<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>
> Does that help? Have you looked at the 2003 OLS paper about udev for
> more information?
Actually you have not answered his question. And i think it
a reasonable one. It could be it was answered elsewhere.
>>>> 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).
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
On Sun, Aug 17, 2003 at 07:04:25PM -0700, jw schultz wrote:
>
> <OT>
> That's nice. Now add a second camera from the same vendor
> :(
Then don't use that rule :)
> 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.
If there is _no_ unique way to identify the device, that that is
impossible.
> 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.
We already have that today, it's called /dev/mice :)
Seriously, I support topology positions, that solves this problem for
real.
> > Does that help? Have you looked at the 2003 OLS paper about udev for
> > more information?
>
> Actually you have not answered his question. And i think it
> a reasonable one. It could be it was answered elsewhere.
I don't think I really understand the question. Given a specific
question, I think I could.
> >>>> 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.
Um, you can, see the topology stuff.
> 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).
Yup, that works too.
> 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?
Use that position as a topology/name indicator.
> 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?
Again, use the topology position.
Please, go read the paper and look at sysfs before asking anything
else...
thanks,
greg k-h
> 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
Andrey Borzenkov <[email protected]> said:
[...]
> I am trying to assign name for a USB slot on my PCs front so that when I
> plug in USB stick or USB drive or whatever I get the same name. Always.
Not necessary: You can mount by volume label, or UUID (Yes, need a sane
filesystem for that... and MS-DOS ones aren't. Sorry.)
Dangerous: You plug a _different_ USB stick in, and think it is the same.
Besides, plugging your drive in "the same place" on USB is useful today,
with 1 or 2 conectors. Add hubs, and you are talking about hundreds of
places... better concentrate on getting the machine keep track of
bureaucratic details.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513