From: Greg KH <greg@kroah.com> To: Andrey Borzenkov <arvidjaar@mail.ru> Cc: jw schultz <jw@pegasys.ws>, linux-kernel@vger.kernel.org, linux-hotplug-devel@lists.sourceforge.net Subject: Re: Does sysfs really provides persistent hardware path to devices? Date: Sat, 17 Jan 2004 13:34:16 -0800 [thread overview] Message-ID: <20040117213415.GB22238@kroah.com> (raw) In-Reply-To: <200401172334.13561.arvidjaar@mail.ru> 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
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <greg@kroah.com> To: Andrey Borzenkov <arvidjaar@mail.ru> Cc: jw schultz <jw@pegasys.ws>, linux-kernel@vger.kernel.org, linux-hotplug-devel@lists.sourceforge.net Subject: Re: Does sysfs really provides persistent hardware path to devices? Date: Sat, 17 Jan 2004 21:34:16 +0000 [thread overview] Message-ID: <20040117213415.GB22238@kroah.com> (raw) In-Reply-To: <200401172334.13561.arvidjaar@mail.ru> 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 ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2004-01-17 21:34 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 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 20:34 ` Andrey Borzenkov 2004-01-17 21:34 ` Greg KH [this message] 2004-01-17 21:34 ` Greg KH 2004-01-18 1:03 ` Kay Sievers 2004-01-18 14:05 ` Kay Sievers 2004-01-19 19:51 ` Greg KH 2004-01-19 13:08 ` Olaf Hering 2004-01-19 13:08 ` Olaf Hering 2004-01-19 13:59 ` Andries Brouwer 2004-01-19 13:59 ` Andries Brouwer 2004-01-19 14:04 ` Olaf Hering 2004-01-19 14:04 ` Olaf Hering 2004-03-14 11:53 ` Andrey Borzenkov 2004-03-14 11:53 ` Andrey Borzenkov 2004-03-14 19:25 ` Horst von Brand 2004-03-14 19:25 ` Horst von Brand -- strict thread matches above, loose matches on Subject: below -- 2003-08-19 17:56 David Brownell 2003-07-26 16:36 Andrey Borzenkov 2003-07-26 16:43 ` Randy.Dunlap 2003-07-26 16:50 ` Greg KH 2003-07-28 16:44 ` Andrey Borzenkov 2003-07-28 17:03 ` Greg KH 2003-08-17 16:41 ` Andrey Borzenkov 2003-08-17 18:28 ` Greg KH 2003-08-18 2:04 ` jw schultz 2003-08-18 20:47 ` Greg KH 2003-07-26 16:54 ` OSDL 2003-07-26 16:59 ` J.C. Wren 2003-07-26 17:07 ` Greg KH 2003-07-26 22:51 ` Dax Kelson
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20040117213415.GB22238@kroah.com \ --to=greg@kroah.com \ --cc=arvidjaar@mail.ru \ --cc=jw@pegasys.ws \ --cc=linux-hotplug-devel@lists.sourceforge.net \ --cc=linux-kernel@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.