Re: [systemd-devel] Programmatically setting udev properties
On Mon, Feb 02, 2015 at 12:57:24PM +0100, Lennart Poettering wrote: On Fri, 30.01.15 08:12, Peter Hutterer (peter.hutte...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Programmatically setting udev properties
On Fri, 30.01.15 08:12, Peter Hutterer (peter.hutte...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Programmatically setting udev properties
On Fri, Jan 30, 2015 at 09:22:51AM +0100, Martin Pitt wrote: Tomasz Torcz [2015-01-29 23:42 +0100]: Have you seen umockdev? https://github.com/martinpitt/umockdev/ Right, with that you can run your tests as normal user, completely isolated from the actual system, and you can set up/change devices, attributes and properties at any time without restrictions. umockdev supports its own device and ioctl dump/restore format, but it can also read and write the evemu format (that might be useful for you). https://github.com/martinpitt/umockdev has a summary of what this does and how to use it. I'm happy to discuss that further with you (perhaps on PM/IRC/etc.) if you are interested. thanks, I've started looking through it. For now dumping into /run/udev/rules.d is a lot easier to add than hooking up umockdev - we have our own test framework around check, umockdev would be a bit more extensive to change bits and pieces around. That's mainly because we don't use the evemu format, we have a bunch struct input_event arrays or wrappers around it. We don't use the recordings, it'd be a bit unwieldly for the various interactions that we're testing. So to switch to umockdev we'd have to juggle a lot more things than we do now, that'll take time to write. Cheers, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Programmatically setting udev properties
Peter Hutterer [2015-01-30 8:12 +1000]: 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. I'm not aware of anything nicer either, apart from completely faking everything (cf. umockdef in the other part of the thread). Your test suite can create/use /run/udev/rules.d/ to at least ensure that the custom rule at least won't be around forever if your test fails without being able to clean up after itself. That's the approach that e. g. the gvfs tests use (see test/gvfs-testbed in the source tree). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Programmatically setting udev properties
Tomasz Torcz [2015-01-29 23:42 +0100]: Have you seen umockdev? https://github.com/martinpitt/umockdev/ Right, with that you can run your tests as normal user, completely isolated from the actual system, and you can set up/change devices, attributes and properties at any time without restrictions. umockdev supports its own device and ioctl dump/restore format, but it can also read and write the evemu format (that might be useful for you). https://github.com/martinpitt/umockdev has a summary of what this does and how to use it. I'm happy to discuss that further with you (perhaps on PM/IRC/etc.) if you are interested. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Programmatically setting udev properties
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. 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? Cheers, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Programmatically setting udev properties
On Fri, Jan 30, 2015 at 08:12:54AM +1000, Peter Hutterer 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. 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? Have you seen umockdev? https://github.com/martinpitt/umockdev/ -- Tomasz Torcz ,,(...) today's high-end is tomorrow's embedded processor.'' xmpp: zdzich...@chrome.pl -- Mitchell Blank on LKML ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
