From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miles Roper Date: Thu, 25 Aug 2005 12:03:47 +0000 Subject: Re: [Thinstation-developer] Re: udev PROGRAM action Message-Id: <430DB3A3.6090001@xtra.co.nz> List-Id: References: <430C3C87.4080209@xtra.co.nz> In-Reply-To: <430C3C87.4080209@xtra.co.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Thanks Kay & Others for all your help :o) Cheers Miles Kay Sievers wrote: > On Thu, Aug 25, 2005 at 10:53:05PM +1200, Miles Roper wrote: > >>I've noticed that there is a devfs udev rules file, but it says not to use >>it as devfs compatibalty isn't really the way to go. I've also noticed >>mandrake & others all seem to use it. > > > SUSE an Red Hat never used it and never will. Gentoo is on the way > getting rid of it (half way done). I can't speak for others, but be sure > that this scheme was already dead before it hit the kernel. > > >>Is there a standard defined >>somewhere which lists what device name/symlinks you should use for likes of >>ide devices & others? > > > Yes, the LSB names, which are mostly the kernel names. For some > subsystems there is s subdirectory for the nodes to live in. > > Enumerating devices like the devfs approach is a silly idea in a world > where device come and go at any time. It just doesn't make _any_ sense > to give a disk a number depending on the order of recognition. > > For persistent disk naming, Hannes Reinecke specified a scheme for > SUSE, which can solve many problems in that area. SUSE uses this scheme > and udev tools also in initramfs for a while. The recent udev has a new > infrastructure with the IMPORT key to make stuff like this very easy. > It also makes the crappy mount-by-label code obsolete. We've had a BOF at > OLS this year and everybody agreed that we want to go this way. See here: > http://www.kroah.com/log/2005/08/18/#2005_08_18-persistent > > Everything needed is in the udev tarball. If any other subsystems has a > reqirement of stable device names, just some small binaries or scripts and a > bunch of IMPORT udev rules wold be needed to maintain persistent names > in /dev. > > >>Either I try to get the devfs script file working, >>or recode several different scripts. Both is about the same amount of work >>as the script doesn't work on busybox ash. >> >>Also, I don't want to have to recode things again later on so are trying to >>work out the best way to do it now. > > > I suggest looking at the /dev/disk/* rules and start from there to > improve and extend this scheme and let the devfs stuff finally rest > in peace. > > Thanks, > Kay > > > >>Kay Sievers wrote: >> >>>On Wed, Aug 24, 2005 at 09:47:47AM -0400, Bill Nottingham wrote: >>> >>> >>>>Miles Roper (mroper@xtra.co.nz) said: >>>> >>>> >>>>>Thanks very much for your help so far. Its starting to make sense :o) >>>>> >>>>>I still can't get the below rule to work :o( >>>>> >>>>>KERNEL="sd*", ACTION="add", BUS="usb", RUN=+"/etc/udev/scripts/usb.sh" >>>>>KERNEL="sd*", ACTION="remove", BUS="usb", >>>>>RUN=+"/etc/udev/scripts/usb.sh" >>>>> >>>>>neither script gets run (as they create a test file in /tmp if they run) >>>>> >>>>>I can post info from syslog when the device is added if you want? >>>> >>>>sd* device names are on the SCSI bus, not the USB bus. >>> >>>That should match, cause udev will walk up the chain of devices in >>>sysfs. Matching on SYSFS, DRIVER and BUS on any of the devices >>>following the "device" link should work. (But all matches must be true on >>>the same device directory, you can't match BUS and SYSFS from different >>>devices at the same time. See "udevinfo -a -p /block/sda".) >>> >>>It's RUN+="...", not RUN=+"...". :) >>>And you can't match on BUS with "remove" cause there is no bus anymore, >>>while the device is removed. Only in the environment of the event you >>>will find PHYSDEVBUS, cause the kernel knows that, but the sysfs >>>directory is already gone. ENV{PHYSDEVBUS}="..." should work if really >>>needed. > > ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ 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