[OpenWrt-Devel] [RFC] replace outdated udev by eudev?

John Crispin blogic at openwrt.org
Sun Feb 7 05:33:00 EST 2016

On 07/02/2016 11:29, Daniel Golle wrote:
> Hi John,
> On Sun, Feb 07, 2016 at 11:03:16AM +0100, John Crispin wrote:
>>>> maybe i am missing the point but why would you want udev on your system
>>>> in the first place ?
>>> There are situations when udev is currently the only way, such are:
>>> * more than one 3g/wwan/usb-serial device and the need to differentiate
>>>   them based on their serial number rather than on the order the kernel
>>>   probes them.
>>>   I really like those /dev/serial/by-id/ symlinks, because they prevent
>>>   comgt to try speaking with my solar-charger and collectd from trying
>>>   to query battery-voltage and PWM currents from the 3G modem -- both
>>>   are detected as usb-serial devices, thus /dev/ttyUSB* device nodes
>>>   are created in the order they are probed -- which differs e.g.
>>>   depending on cold start or warm reset of the OS.
>>> * similar things apply when having multiple V4L, ALSA or HID devices...
>>> * udev rules are needed for certain USB devices to be accessible for
>>>   non-root users
>> which brings us back to my second question, why not add these features
>> to procd ? my experience is that these features can be implemented in
>> 100 lines +/-
> I agree that I'd be quite easy to sort-out the persistent aliases for
> serial and all sorts of other devices.
> However, e.g. libinput uses a quite wide set of udev's functions:
> udev_enumerate_scan_devices
> udev_device_get_action
> udev_enumerate_unref
> udev_device_new_from_devnum
> udev_device_get_devnode
> udev_enumerate_add_match_subsystem
> udev_device_ref
> udev_monitor_receive_device
> udev_device_new_from_syspath
> udev_new
> udev_device_get_udev
> udev_enumerate_new
> udev_device_get_parent
> udev_enumerate_get_list_entry
> udev_unref
> udev_device_get_sysname
> udev_device_get_syspath
> udev_monitor_new_from_netlink
> udev_ref
> udev_list_entry_get_name
> udev_list_entry_get_next
> udev_device_get_property_value
> udev_monitor_get_fd
> udev_monitor_filter_add_match_subsystem_devtype
> udev_device_unref
> udev_monitor_unref
> udev_device_get_is_initialized
> udev_monitor_enable_receiving
> So re-implementing all of this seems overkill to me...
> And I'd really like to see Wayland/weston on OpenWrt targets capable of
> providing a GUI (and not just on RaspbPi). Wait for better days?
> Stick to lcdproc and directfb?
> Many routers (3g/mobile as well as top-edge home-user devices) come
> with small touch-screens in our days, I'd like to see that supported in
> some way, and preferably not by re-implementing the whole graphics and
> input stack yet another time (unless some really feels like going into
> that)

ah ok, you are building desktop stuff. i dont really care in that case.
it thought you wanted to run udev on a router which made me wonder.

> Cheers
> Daniel
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list