* (no subject) @ 2003-08-18 6:21 "Andrey Borzenkov" 2003-08-18 20:42 ` your mail Greg KH 0 siblings, 1 reply; 11+ messages in thread From: "Andrey Borzenkov" @ 2003-08-18 6:21 UTC (permalink / raw) To: "jw schultz" ; +Cc: "Greg KH" , linux-kernel > Actually you have not answered his question. And i think it > a reasonable one. It could be it was answered elsewhere. No it was not answered. Yes you got this exactly. Aparently my englisg is not as bad after all ... :) >>>>> Question: how to configure udev so that "database" always refers to LUN 0 >>>>> on target 0 on bus 0 on HBA in PCI slot 1. >>> Let's avoid this communication problem. You show me namedev.config line that >>> implements the above. > I'll try to put slightly differently. I'll concede that we > cannot positionaly identify USB devices so lets set that > aside for the nonce. We can persistently, positionaly > identify a device within the HBA context (BUS +ID + LUN) and > should be able to do the same for a PCI HBA (PCI slot + > device) or (PCI bridge topology). actually you can. As Greg pointed out, topology rarely changes, so it gives you enough information (of course if you constantly add and remove USB hubs it becomes a bit of pain). But it has the same problem - USB bus grows off PCI bus (usually) so adding new USB controller possibly invalidates all configuration. > So can i uniquely identify using persistent positional > information a drive at PCI_slot=1, HBA_on_card=0, BUS=0, > ID=1, LUN=0? And how do i uniquely identify it in the udev > config file so that adding the same model drive in the same > BUS+ID+LUN on an same model HBA card in another PCI slot > does not confuse the two? If i cannot, can i at least do > the identification so that adding ID=0,LUN=0 to the scsi buss > doesn't cause a name change. yep. just to show what I expected from sysfs - here is entry from Solaris /devices: brw-r----- 1 root sys 32,240 Jan 24 2002 /devices/pci@16,4000/scsi@5,1/sd@0,0:a this entry identifies disk partition 0 on drive with SCSI ID 0, LUN 0 connected to bus 1 of controller in slot 5 of PCI bus identified by 16. Now you can use whatever policy you like to give human meaningful name to this entry. And if you have USB it will continue further giving you exact topology starting from the root of your device tree. and this path does not contain single logical id so it is not subject to change if I add the same controller somewhere else. hopefully it clarifies what I mean ... regards -andrey ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: your mail 2003-08-18 6:21 "Andrey Borzenkov" @ 2003-08-18 20:42 ` Greg KH 2003-08-31 10:54 ` Does sysfs really provides persistent hardware path to devices? Andrey Borzenkov 0 siblings, 1 reply; 11+ messages in thread From: Greg KH @ 2003-08-18 20:42 UTC (permalink / raw) To: Andrey Borzenkov; +Cc: jw schultz, linux-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Does sysfs really provides persistent hardware path to devices? 2003-08-18 20:42 ` your mail Greg KH @ 2003-08-31 10:54 ` Andrey Borzenkov 2003-09-24 21:18 ` Greg KH 0 siblings, 1 reply; 11+ messages in thread From: Andrey Borzenkov @ 2003-08-31 10:54 UTC (permalink / raw) To: Greg KH; +Cc: jw schultz, linux-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Does sysfs really provides persistent hardware path to devices? 2003-08-31 10:54 ` Does sysfs really provides persistent hardware path to devices? Andrey Borzenkov @ 2003-09-24 21:18 ` Greg KH 2004-01-17 20:34 ` Andrey Borzenkov 0 siblings, 1 reply; 11+ messages in thread From: Greg KH @ 2003-09-24 21:18 UTC (permalink / raw) To: Andrey Borzenkov; +Cc: jw schultz, linux-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Does sysfs really provides persistent hardware path to devices? 2003-09-24 21:18 ` Greg KH @ 2004-01-17 20:34 ` Andrey Borzenkov 2004-01-17 21:34 ` Greg KH 2004-01-19 13:08 ` Olaf Hering 0 siblings, 2 replies; 11+ messages in thread From: Andrey Borzenkov @ 2004-01-17 20:34 UTC (permalink / raw) To: Greg KH; +Cc: jw schultz, linux-kernel, linux-hotplug-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Does sysfs really provides persistent hardware path to devices? 2004-01-17 20:34 ` Andrey Borzenkov @ 2004-01-17 21:34 ` Greg KH 2004-01-19 13:08 ` Olaf Hering 1 sibling, 0 replies; 11+ messages in thread From: Greg KH @ 2004-01-17 21:34 UTC (permalink / raw) To: Andrey Borzenkov; +Cc: jw schultz, linux-kernel, linux-hotplug-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Does sysfs really provides persistent hardware path to devices? 2004-01-17 20:34 ` Andrey Borzenkov 2004-01-17 21:34 ` Greg KH @ 2004-01-19 13:08 ` Olaf Hering 2004-01-19 13:59 ` Andries Brouwer 2004-03-14 11:53 ` Andrey Borzenkov 1 sibling, 2 replies; 11+ messages in thread From: Olaf Hering @ 2004-01-19 13:08 UTC (permalink / raw) To: Andrey Borzenkov; +Cc: Greg KH, jw schultz, linux-kernel, linux-hotplug-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Does sysfs really provides persistent hardware path to devices? 2004-01-19 13:08 ` Olaf Hering @ 2004-01-19 13:59 ` Andries Brouwer 2004-01-19 14:04 ` Olaf Hering 2004-03-14 11:53 ` Andrey Borzenkov 1 sibling, 1 reply; 11+ messages in thread From: Andries Brouwer @ 2004-01-19 13:59 UTC (permalink / raw) To: Olaf Hering Cc: Andrey Borzenkov, Greg KH, jw schultz, linux-kernel, linux-hotplug-devel 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Does sysfs really provides persistent hardware path to devices? 2004-01-19 13:59 ` Andries Brouwer @ 2004-01-19 14:04 ` Olaf Hering 0 siblings, 0 replies; 11+ messages in thread From: Olaf Hering @ 2004-01-19 14:04 UTC (permalink / raw) To: Andries Brouwer Cc: Andrey Borzenkov, Greg KH, jw schultz, linux-kernel, linux-hotplug-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Does sysfs really provides persistent hardware path to devices? 2004-01-19 13:08 ` Olaf Hering 2004-01-19 13:59 ` Andries Brouwer @ 2004-03-14 11:53 ` Andrey Borzenkov 2004-03-14 19:25 ` Horst von Brand 1 sibling, 1 reply; 11+ messages in thread From: Andrey Borzenkov @ 2004-03-14 11:53 UTC (permalink / raw) To: Olaf Hering; +Cc: Greg KH, jw schultz, linux-kernel, linux-hotplug-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Does sysfs really provides persistent hardware path to devices? 2004-03-14 11:53 ` Andrey Borzenkov @ 2004-03-14 19:25 ` Horst von Brand 0 siblings, 0 replies; 11+ messages in thread From: Horst von Brand @ 2004-03-14 19:25 UTC (permalink / raw) To: Andrey Borzenkov; +Cc: linux-kernel, linux-hotplug-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2004-03-14 19:28 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-08-18 6:21 "Andrey Borzenkov" 2003-08-18 20:42 ` your mail Greg KH 2003-08-31 10:54 ` Does sysfs really provides persistent hardware path to devices? Andrey Borzenkov 2003-09-24 21:18 ` Greg KH 2004-01-17 20:34 ` Andrey Borzenkov 2004-01-17 21:34 ` Greg KH 2004-01-19 13:08 ` Olaf Hering 2004-01-19 13:59 ` Andries Brouwer 2004-01-19 14:04 ` Olaf Hering 2004-03-14 11:53 ` Andrey Borzenkov 2004-03-14 19:25 ` Horst von Brand
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).