(no subject)

["Andrey Borzenkov"]

> 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

Re: your mail

[Greg KH]

On Mon, Aug 18, 2003 at 10:21:22AM +0400, "Andrey Borzenkov"  wrote:
> 
> 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 ...

Hm, a bit.  First, have you looked at what sysfs provides?  Here's one
of my machines and tell me if it has all the info you are looking for:

$ tree /sys/bus/scsi/
/sys/bus/scsi/
|-- devices
|   `-- 0:0:0:0 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:05.0/host0/0:0:0:0
`-- drivers
    `-- sd
        `-- 0:0:0:0 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:05.0/host0/0:0:0:0

$ tree /sys/block/sda/
/sys/block/sda/
|-- dev
|-- device -> ../../devices/pci0000:00/0000:00:1e.0/0000:02:05.0/host0/0:0:0:0
|-- queue
|   |-- iosched
|   |   |-- antic_expire
|   |   |-- read_batch_expire
|   |   |-- read_expire
|   |   |-- write_batch_expire
|   |   `-- write_expire
|   `-- nr_requests
|-- range
|-- sda1
|   |-- dev
|   |-- size
|   |-- start
|   `-- stat
|-- sda2
|   |-- dev
|   |-- size
|   |-- start
|   `-- stat
|-- sda3
|   |-- dev
|   |-- size
|   |-- start
|   `-- stat
|-- sda4
|   |-- dev
|   |-- size
|   |-- start
|   `-- stat
|-- size
`-- stat


Now, from that you can see exactly where my scsi device is in the pci
tree, and you can see in the block directory, what block device is
assigned to what physical device in the device tree.  Then there are 4
partitions on this disk, all what those specific paramaters.

So, when sda shows up, udev can determine that it lives on a specific
scsi device, located in a specific place in the pci space, and that it
has some number of partitions, all of specific sizes, wich specific
major/minor numbers.  It can then create all of the /dev links based on
this.

Please, take a few minutes looking at the existing sysfs tree on Linux.
If you then have any specific questions, I would be glad to answer
them.

Hope this helps,

greg k-h

Re: Does sysfs really provides persistent hardware path to devices?

[Andrey Borzenkov]

On Tuesday 19 August 2003 00:42, Greg KH wrote:
> On Mon, Aug 18, 2003 at 10:21:22AM +0400, "Andrey Borzenkov"  wrote:
> > 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 ...
>
> Hm, a bit.  First, have you looked at what sysfs provides?  Here's one
> of my machines and tell me if it has all the info you are looking for:
>
> $ tree /sys/bus/scsi/
> /sys/bus/scsi/
>
> |-- devices
> |   `-- 0:0:0:0 ->
> | ../../../devices/pci0000:00/0000:00:1e.0/0000:02:05.0/host0/0:0:0:0
                                                              ^ ^unstable         
[...]
>
> Now, from that you can see exactly where my scsi device is in the pci
> tree, and you can see in the block directory, what block device is
> assigned to what physical device in the device tree.  Then there are 4
> partitions on this disk, all what those specific paramaters.
>
> So, when sda shows up, udev can determine that it lives on a specific
> scsi device, located in a specific place in the pci space, and that it
> has some number of partitions, all of specific sizes, wich specific
> major/minor numbers.  It can then create all of the /dev links based on
> this.
>
> Please, take a few minutes looking at the existing sysfs tree on Linux.
> If you then have any specific questions, I would be glad to answer
> them.
>

Now I have to ask - do we discuss udev-0.2 (what I currently have) or 
udev-as-it-can-be-in-fututure?

In udev-0.2 I cannot do it. I can say I want

TOPOLOGY, BUS="scsi", place="0.0.0.0", NAME="jaz"

but the next time I plug in SCSI card the host number changes. Even after I 
unplug USB stick and plug it again it gets new host number.

And the same applies to USB, PCI and whatever. Sysfs exports entity numbers as 
kernel enumerates them; while Solaris exports persistent device tree leaving 
enumeration to user-level tools. Which means that if hardware changes for 
whatever reason enumeration changes as well and your config becomes invalid. 

> Hope this helps,
>

Well, we did not move a tiny bit since the beginning of this thread :) You 
still did not show me namedev configuration that implements persistent name 
for a device based on its physical location :)))

-andrey

Re: Does sysfs really provides persistent hardware path to devices?

[Greg KH]

On Sun, Aug 31, 2003 at 02:54:06PM +0400, Andrey Borzenkov wrote:
> On Tuesday 19 August 2003 00:42, Greg KH wrote:
> > On Mon, Aug 18, 2003 at 10:21:22AM +0400, "Andrey Borzenkov"  wrote:
> > > 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 ...
> >
> > Hm, a bit.  First, have you looked at what sysfs provides?  Here's one
> > of my machines and tell me if it has all the info you are looking for:
> >
> > $ tree /sys/bus/scsi/
> > /sys/bus/scsi/
> >
> > |-- devices
> > |   `-- 0:0:0:0 ->
> > | ../../../devices/pci0000:00/0000:00:1e.0/0000:02:05.0/host0/0:0:0:0
>                                                               ^ ^unstable         

Heh, so are the pci ids in that link too :)

> Now I have to ask - do we discuss udev-0.2 (what I currently have) or 
> udev-as-it-can-be-in-fututure?

Either is fine with me.

> In udev-0.2 I cannot do it. I can say I want
> 
> TOPOLOGY, BUS="scsi", place="0.0.0.0", NAME="jaz"
> 
> but the next time I plug in SCSI card the host number changes. Even after I 
> unplug USB stick and plug it again it gets new host number.
> 
> And the same applies to USB, PCI and whatever. Sysfs exports entity numbers as 
> kernel enumerates them; while Solaris exports persistent device tree leaving 
> enumeration to user-level tools. Which means that if hardware changes for 
> whatever reason enumeration changes as well and your config becomes invalid. 

I agree.  That's why topology is only one part of the rules, and is so
low in the chain of hierarchy of what to match on.  To recap, here is
the hierarchy:
	1 - label or serial number
	2 - bus device number
	3 - topology on bus
	4 - replace name
	5 - kernel name

So, if you do not have something that matches for your device for rules
1 or 2, then use 3.  But yes, it can change.  So can any of these items,
that's why we have to be flexible.

And yes, we should add wild card matching for topology rules, it's on
the todo list, I haven't had much time to work on udev lately.

> > Hope this helps,
> >
> 
> Well, we did not move a tiny bit since the beginning of this thread :) You 
> still did not show me namedev configuration that implements persistent name 
> for a device based on its physical location :)))

Ok, do you have any other ideas of how to do this?

And patches for udev are always welcome :)

thanks,

greg k-h

Re: Does sysfs really provides persistent hardware path to devices?

[Andrey Borzenkov]

On Thursday 25 September 2003 01:18, Greg KH wrote:
> On Sun, Aug 31, 2003 at 02:54:06PM +0400, Andrey Borzenkov wrote:
> > On Tuesday 19 August 2003 00:42, Greg KH wrote:
> > > On Mon, Aug 18, 2003 at 10:21:22AM +0400, "Andrey Borzenkov"  wrote:
> > > > 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 ...
> > >
> > > Hm, a bit.  First, have you looked at what sysfs provides?  Here's one
> > > of my machines and tell me if it has all the info you are looking for:
> > >
> > > $ tree /sys/bus/scsi/
> > > /sys/bus/scsi/
> > >
> > > |-- devices
> > > |   `-- 0:0:0:0 ->
> > > | ../../../devices/pci0000:00/0000:00:1e.0/0000:02:05.0/host0/0:0:0:0
> >
> >                                                               ^ ^unstable
>
> Heh, so are the pci ids in that link too :)
>

I am not sure if you are just making fun here. No, in _this_ link pci ids are 
not unstable because I do not have hotpug PCI. But SCSI hosts are unstable:

{pts/0}% LC_ALL=C ll /sys/class/scsi_host/*/device
lrwxrwxrwx    1 root     root           71 Jan 17 22:59 
/sys/class/scsi_host/host7/device -> 
../../../devices/pci0000:00/0000:00:1f.4/usb2/2-2/2-2.4/2-2.4:1.0/host7/
lrwxrwxrwx    1 root     root           29 Jan 17 23:19 
/sys/class/scsi_host/host8/device -> ../../../devices/legacy/host8/

after unplugging and replugging USB stick:

pts/0}% LC_ALL=C ll /sys/class/scsi_host/*/device
lrwxrwxrwx    1 root     root           29 Jan 17 23:19 
/sys/class/scsi_host/host8/device -> ../../../devices/legacy/host8/
lrwxrwxrwx    1 root     root           71 Jan 17 23:25 
/sys/class/scsi_host/host9/device -> 
../../../devices/pci0000:00/0000:00:1f.4/usb2/2-2/2-2.4/2-2.4:1.0/host9/

host7 became host9

[... skipped as obsolete now...]
>
> And yes, we should add wild card matching for topology rules, it's on
> the todo list, I haven't had much time to work on udev lately.
>
> > > Hope this helps,
> >
> > Well, we did not move a tiny bit since the beginning of this thread :)
> > You still did not show me namedev configuration that implements
> > persistent name for a device based on its physical location :)))
>
> Ok, do you have any other ideas of how to do this?
>

given current sysfs implementation - using wildcards remains the only 
solution. I for now am using this trivial script:

pts/0}% cat /etc/udev/scripts/removables
#!/usr/bin/perl

my $devpath, $base;

$base = $1 if ($ARGV[0] =~ /(.*\D)\d*$/);
$devpath = readlink "/sys/block/$base/device";

if ($devpath =~ 
m|/devices/pci0000:00/0000:00:1f.4/usb2/2-2/2-2.4/2-2.4:1.0/host\d+/\d+:0:0:0|) 
{
        print "flash0";
} elsif ($devpath =~ 
m|/devices/pci0000:00/0000:00:1f.4/usb2/2-2/2-2.1/2-2.1:1.0/host\d+/\d+:0:0:0|) 
{
        print "flash1";
} elsif ($devpath =~ m|/devices/legacy/host\d+/\d+:0:4:0|) {
        print "jaz";
} else {
        exit(1);
}

1;

with config

KERNEL="sd*" PROGRAM="/etc/udev/scripts/removables %k" SYMLINK="%c/%D"

> And patches for udev are always welcome :)
>

as example shows it probably can be done without serious patches. The only 
problem is to make devpath available; at this point udev already computed it. 
If you think it makes sense, patch will follow.

regards

-andrey

Re: Does sysfs really provides persistent hardware path to devices?

[Greg KH]

On Sat, Jan 17, 2004 at 11:34:13PM +0300, Andrey Borzenkov wrote:
> On Thursday 25 September 2003 01:18, Greg KH wrote:

Heh, nothing like a long time between responses :)

> > On Sun, Aug 31, 2003 at 02:54:06PM +0400, Andrey Borzenkov wrote:
> > > On Tuesday 19 August 2003 00:42, Greg KH wrote:
> > > > On Mon, Aug 18, 2003 at 10:21:22AM +0400, "Andrey Borzenkov"  wrote:
> > > > > 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 ...
> > > >
> > > > Hm, a bit.  First, have you looked at what sysfs provides?  Here's one
> > > > of my machines and tell me if it has all the info you are looking for:
> > > >
> > > > $ tree /sys/bus/scsi/
> > > > /sys/bus/scsi/
> > > >
> > > > |-- devices
> > > > |   `-- 0:0:0:0 ->
> > > > | ../../../devices/pci0000:00/0000:00:1e.0/0000:02:05.0/host0/0:0:0:0
> > >
> > >                                                               ^ ^unstable
> >
> > Heh, so are the pci ids in that link too :)
> >
> 
> I am not sure if you are just making fun here. No, in _this_ link pci ids are 
> not unstable because I do not have hotpug PCI.

Your PCI ids could change over reboots for a number of different
reasons (bios changes, adding or removing cards, phase of the moon,
etc.)  My point is, PCI ids can not be guananteed to be stable for
everyone.

> But SCSI hosts are unstable:

Exactly.

> given current sysfs implementation - using wildcards remains the only 
> solution. I for now am using this trivial script:

You know that udev now supports wildcards in its pattern matching,
right?

> pts/0}% cat /etc/udev/scripts/removables
> #!/usr/bin/perl
> 
> my $devpath, $base;
> 
> $base = $1 if ($ARGV[0] =~ /(.*\D)\d*$/);
> $devpath = readlink "/sys/block/$base/device";
> 
> if ($devpath =~ 
> m|/devices/pci0000:00/0000:00:1f.4/usb2/2-2/2-2.4/2-2.4:1.0/host\d+/\d+:0:0:0|) 
> {
>         print "flash0";

ick, isn't there a unique sysfs id in this location for this device that
you can query off of?  model?  vendor?  scsi uuid?

> } elsif ($devpath =~ 
> m|/devices/pci0000:00/0000:00:1f.4/usb2/2-2/2-2.1/2-2.1:1.0/host\d+/\d+:0:0:0|) 
> {
>         print "flash1";
> } elsif ($devpath =~ m|/devices/legacy/host\d+/\d+:0:4:0|) {
>         print "jaz";
> } else {
>         exit(1);
> }
> 
> 1;
> 
> with config
> 
> KERNEL="sd*" PROGRAM="/etc/udev/scripts/removables %k" SYMLINK="%c/%D"

I just removed %D from udev too :)

> > And patches for udev are always welcome :)
> >
> 
> as example shows it probably can be done without serious patches. The only 
> problem is to make devpath available; at this point udev already computed it. 
> If you think it makes sense, patch will follow.

I could see making devpath available as a % modifier.

thanks,

greg k-h

Re: Does sysfs really provides persistent hardware path to devices?

[Olaf Hering]

 On Sat, Jan 17, Andrey Borzenkov wrote:

> > > Well, we did not move a tiny bit since the beginning of this thread :)
> > > You still did not show me namedev configuration that implements
> > > persistent name for a device based on its physical location :)))
> >
> > Ok, do you have any other ideas of how to do this?
> >
> 
> given current sysfs implementation - using wildcards remains the only 
> solution. I for now am using this trivial script:
> 
> pts/0}% cat /etc/udev/scripts/removables
> #!/usr/bin/perl
> 
> my $devpath, $base;
> 
> $base = $1 if ($ARGV[0] =~ /(.*\D)\d*$/);
> $devpath = readlink "/sys/block/$base/device";
> 
> if ($devpath =~ 
> m|/devices/pci0000:00/0000:00:1f.4/usb2/2-2/2-2.4/2-2.4:1.0/host\d+/\d+:0:0:0|) 
> {
>         print "flash0";
> } elsif ($devpath =~ 
> m|/devices/pci0000:00/0000:00:1f.4/usb2/2-2/2-2.1/2-2.1:1.0/host\d+/\d+:0:0:0|) 
> {
>         print "flash1";
> } elsif ($devpath =~ m|/devices/legacy/host\d+/\d+:0:4:0|) {
>         print "jaz";
> } else {
>         exit(1);
> }

I'm not sure what you are trying to do. Working with the 'physical
location' of removeable devices will probably fail. The usb-storage
devices here have a serial field, I really hope it is unique, use it.

-- 
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

Re: Does sysfs really provides persistent hardware path to devices?

[Andries Brouwer]

On Mon, Jan 19, 2004 at 02:08:17PM +0100, Olaf Hering wrote:

> ... Working with the 'physical
> location' of removeable devices will probably fail. The usb-storage
> devices here have a serial field, I really hope it is unique, use it.

Too optimistic.
I have several devices with serial number 0.

Re: Does sysfs really provides persistent hardware path to devices?

[Olaf Hering]

 On Mon, Jan 19, Andries Brouwer wrote:

> On Mon, Jan 19, 2004 at 02:08:17PM +0100, Olaf Hering wrote:
> 
> > ... Working with the 'physical
> > location' of removeable devices will probably fail. The usb-storage
> > devices here have a serial field, I really hope it is unique, use it.
> 
> Too optimistic.
> I have several devices with serial number 0.

Nice... Is 'serial' empty, or does it just have '0' in it? And would it
also fail to use vendor/device id for these beasts?

-- 
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

Re: Does sysfs really provides persistent hardware path to devices?

[Andrey Borzenkov]

On Monday 19 January 2004 16:08, Olaf Hering wrote:
>  On Sat, Jan 17, Andrey Borzenkov wrote:
> > > > Well, we did not move a tiny bit since the beginning of this thread
> > > > :) You still did not show me namedev configuration that implements
> > > > persistent name for a device based on its physical location :)))
> > >
> > > Ok, do you have any other ideas of how to do this?
> >
> > given current sysfs implementation - using wildcards remains the only
> > solution. I for now am using this trivial script:
> >
> > pts/0}% cat /etc/udev/scripts/removables
> > #!/usr/bin/perl
> >
> > my $devpath, $base;
> >
> > $base = $1 if ($ARGV[0] =~ /(.*\D)\d*$/);
> > $devpath = readlink "/sys/block/$base/device";
> >
> > if ($devpath =~
> > m|/devices/pci0000:00/0000:00:1f.4/usb2/2-2/2-2.4/2-2.4:1.0/host\d+/\d+:0
> >:0:0|) {
> >         print "flash0";
> > } elsif ($devpath =~
> > m|/devices/pci0000:00/0000:00:1f.4/usb2/2-2/2-2.1/2-2.1:1.0/host\d+/\d+:0
> >:0:0|) {
> >         print "flash1";
> > } elsif ($devpath =~ m|/devices/legacy/host\d+/\d+:0:4:0|) {
> >         print "jaz";
> > } else {
> >         exit(1);
> > }
>
> I'm not sure what you are trying to do.

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.

> Working with the 'physical 
> location' of removeable devices will probably fail.

why? The 'physical location' is the only thing that is unlikely to change 
unless you physically change you hardware.

Anyway - it appears that udev (as of 022 now) still does not support doing it. 
Once more - I want to make sure that SCSI disk plugged in specific USB slot 
(that does not ever change) always gets the same name. So that I always know 
how to access it.

naive user would think that something like

KERNEL="sd*" BUS="usb" PLACE="2.4:1.0" SYMLINK="flash0/sd%n"

would work. Surely it does not. When udev sees "sd*" it does not see bus USB. 
When udev sees bus USB it does not see "sd*". It does (probably) see sd* on 
bus SCSI but it does not help me in any way because I have no way to 
associate SCSI ID with USB port. While kernel does know that "sda" is a child 
of USB port 2.4:0.1 I do not see any way to express it in udev.

Could somebody explain what am I doing wrong. Thank you. 

> The usb-storage 
> devices here have a serial field, I really hope it is unique, use it.

Sigh ... let me quote:

> I have 6 different firewire hard drives, and an iPod, a usb stick, a usb
> stick/camera combo, and a bunch of flash memory products (CF, SM, SD) so
> such a thing would be incredibly useful to me.  I'm always modifying my
> fstab to keep things in order.

so you suggest him to add every device separately? And if he has half a dozen 
friends having half a dozen devices each - do you suggest adding yet another 
40 lines for all of them? And keep it in sync with all updates and upgrades?

On the contrary he likely has just a couple of USB ports and one firewire and 
he just needs three lines for *any* device which is ever going to be plugged 
in. Or he would need if it was supported.

thank you

-andrey

Re: Does sysfs really provides persistent hardware path to devices?

[Horst von Brand]

Andrey Borzenkov <arvidjaar@mail.ru> 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

Re: Does sysfs really provides persistent hardware path to devices?

[David Brownell]

> 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

Re: Does sysfs really provides persistent hardware path to devices?

[Greg KH]

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

Re: Does sysfs really provides persistent hardware path to devices?

[jw schultz]

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:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: Does sysfs really provides persistent hardware path to devices?

[Greg KH]

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

Re: Does sysfs really provides persistent hardware path to devices?

[Andrey Borzenkov]

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

Re: Does sysfs really provides persistent hardware path to devices?

[Greg KH]

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

Re: Does sysfs really provides persistent hardware path to devices?

[Andrey Borzenkov]

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 :(

Re: Does sysfs really provides persistent hardware path to devices?

[Dax Kelson]

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

Re: Does sysfs really provides persistent hardware path to devices?

[Greg KH]

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

Re: Does sysfs really provides persistent hardware path to devices?

[J.C. Wren]

	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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Does sysfs really provides persistent hardware path to devices?

[OSDL]

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 

Re: Does sysfs really provides persistent hardware path to devices?

[Greg KH]

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

Re: Does sysfs really provides persistent hardware path to devices?

[Randy.Dunlap]

On Sat, 26 Jul 2003 20:36:13 +0400 Andrey Borzenkov <arvidjaar@mail.ru> 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/

Does sysfs really provides persistent hardware path to devices?

[Andrey Borzenkov]

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