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