(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