[Wayland-bugs] [Bug 85573] Provide a udev handle from the libinput device
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Thu Oct 30 18:19:19 PDT 2014
https://bugs.freedesktop.org/show_bug.cgi?id=85573
Peter Hutterer <peter.hutterer at who-t.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
CC| |peter.hutterer at who-t.net
--- Comment #1 from Peter Hutterer <peter.hutterer at who-t.net> ---
Main question here: better to get the udev_device handle directly, or the
device node and leave the rest up to the caller?
What are the side-effects to each approach?.
If libinput caches the udev_device handle and returns that, there's some odd
case where dropping privileges in the caller may give a device the caller does
not have access to anymore (struggling to find a use-case for that though,
since it would also break hotplugging).
If the cached handle is returned, a buggy caller could call udev_device_unref
too often and cause a (hard to debug) segfault in libinput. I'd consider that a
normal bug though, can be avoided by returning a new handle for the device.
If a new handle is returned, the code isn't much different than returning the
device node, other than adding another udev dependency on the API. The path
backend uses udev internally, but returning the device node would be simple
enough.
Any new, uncached handle can suffer from race conditions if the device
disappears. Not much different to normal error handling though.
Not all devices may have a udev handle, but then again not all devices have a
device node.
Comments, more things to think about?
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-bugs/attachments/20141031/12b85fc0/attachment.html>
More information about the wayland-bugs
mailing list