[systemd-devel] Programmatically setting udev properties

[Peter Hutterer]

On Mon, Feb 02, 2015 at 12:57:24PM +0100, Lennart Poettering wrote:
> 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...

ok, no worries. thanks for the answers, we're going with the /run option
now, which isn't 100% perfect but close enough for the tests we need at the
moment.

Cheers,
   Peter