Re: [Thinstation-developer] Re: udev PROGRAM action

[Kay Sievers <kay.sievers@vrfy.org>]

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