https://bugs.freedesktop.org/show_bug.cgi?id=85573
Peter Hutterer <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |[email protected] --- Comment #1 from Peter Hutterer <[email protected]> --- 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.
_______________________________________________ wayland-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-bugs
