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

[Daniel Golle]

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)


Cheers


Daniel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel