[systemd-devel] Programmatically setting udev properties

[Lennart Poettering]

On Fri, 30.01.15 08:12, Peter Hutterer (peter.hutterer at who-t.net) wrote:

> Hi,
> 
> I need some sort of way of assigning udev properties on the fly to a device,
> but I'm short of ideas how to do this sensibly.

THis is explicitly not supported. Conceptually udev only supports new,
change and removed events, and there's no way to change only
individual props. if you want to change individual props, you need to
plug them into the rules files, and retrigger the device as a whole,
which will not only refresh the props you are interested but all props
of the device.

> A bit more context:
> The libinput test suite works by setting up uinput devices for each test
> case, then hooking libinput contexts up to those devices. libinput itself
> uses some udev properties to adjust internal behaviours. That works for real
> hardware because the rules are written for that (and we can require a make
> install) but uinput devices don't have the same hierarchy and thus don't
> trigger those rules. Plus, requiring an install before running the test
> suite isn't very nice.
> 
> So basically what I'd like would be a udev_device_set_property() call or
> something similar.  We're in control of the uinput and the libinput bits,
> i.e. there are no race conditions to worry about. 
> 
> Because of uinput, the test suite runs as root. One solution would be to
> drop a custom test rule, reload, create the uinput device, run the test,
> rm the rule again. Not pretty though, I was hoping there was something
> nicer.
> 
> Any ideas?

Sorry, this is not available, and we explicitly don't want that as
people would misuse it if it existed. It would require inventing a new
notifciation scheme for individual prop changes, and we don#t want
that. 

Note that udev reads udev rules from /run, so you could drop them
there, then retrigger the device (by writing "change" into the
device's uevent file in /sys), and remove the rule afterwards.

Other than that umockdev and LD_PRELOAD hacks might be options for
test cases like this...

Lennart

-- 
Lennart Poettering, Red Hat