Re: More Elegant udev rules

>> Yes, you can use one of the sysfs variables to limit on the specific
>> serial number of the drive. Or you could limit it to a model number,
>> or manufacturer, etc
>>
>> In the "ACTION" line, it currently selects based on the SYSFS{vendor}
>> variable being "ATA     ", you could change that to SYSFS{serial} =
>> "yourserial". Get the serial number via sysfs itself to make sure
>> you're referring to the right thing
>>
> I had considered that but was more looking for code that would work in
> all instances instead of a specific instance.
> Not being a programmer I can't fully comprehend why the combination of
> SYSFS{vendor} and ID doesn't isolate devices more than it seems to
> already.
> Literally hundreds of devices appear in the removable storage list
> using the above code.

How much less specific do you want?  Could you filter on a partial 
serial number (all Seagate drives start with ST, for example)

If the drives are USB-connected, there is a "removable" variable you can 
filter on, which will only be set to 1 if the drive is a removable one 
(usb, floppy, cdrom etc).

And if you know which device nodes you want to connect (eg, sdb, sdc, 
sdd) and they don't change, then you can just filter on that.


>> You already run a script in that rule on add/remove events. You could
>> either modify that script or write a new wrapper script that calls
>> your hdparm command and then calls the local-device-change script. Or
>> maybe the semantics of the RUN command allow multiple RUN lines, I
>> can't recall.
> Thanks,  I'm a little worried about the warning to not run long running
> tasks using RUN. To make this elegant I would need to run hdparm on all
> possible hard disk devices. As part of a wrapper script would this be
> regarded as long?

Why would you run it on all devices? udev will call this script for 
every device add event, and as you only care about updating the current 
device anyway, you should only need to run hdparm on the specific device 
that udev is referring to right now, which is far more elegant than 
attempting to run it on all possible devices IMO. Any other devices 
you've added prior to that will have already had hdparm run on them, for 
example.  In the code you pasted, the script gets called with a 
parameter called %k, which expands out to the kernel name for the device 
I believe, which will be f.e. /dev/sdb.

I believe the cavaet about long-running tasks refers to things taking 
many seconds or minutes to run. hdparm to turn the write cache off for a 
single device shouldn't take more than a few seconds. Time it yourself 
and see though.


>> Either way, reading the udev manuals will help you a lot.
> I have read and re-read this site
> http://reactivated.net/writing_udev_rules.html and tried to understand
> the man pages prior to asking for help.
> My lack of programming knowledge is restricting my progress.
> I'm sorry I'm a real novice, particularly at low level interactions
> with hardware.
> Can anyone point me to a link better addressing the specific example
> with respect to udev rules writing?


If you could give a clearer example of what's going wrong, I may be able 
to help more.

A quick google search reveals these links, which may help you more 
specifically:

http://kiekeboe100.hoefman.be/blog/2009/06/attaching-disk-to-xenserver-guest/
http://techblog.conglomer.net/sata-direct-local-disk-access-on-xenserver/

Both use more specific variants of the same udev rule than the one you 
are using, so will probably help you.
_______________________________________________
NZLUG mailing list [email protected]
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug