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

[Miles Roper <mroper@xtra.co.nz>]

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