Messages in this thread | | | Date | Sat, 17 Jan 2004 13:34:16 -0800 | From | Greg KH <> | Subject | Re: Does sysfs really provides persistent hardware path to devices? |
| |
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 - 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/
| |