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@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel