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

2016-02-07 Thread John Crispin


On 07/02/2016 10:22, Daniel Golle wrote:
> The main reason why I'd like to have udev is persistent aliasing of
> (hotpluggable) serial devices like wwan modems and input devices; udev
> is required for libinput to build.

why dont we just add this to the procd code ?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


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

2016-02-07 Thread John Crispin


On 07/02/2016 10:22, Daniel Golle wrote:
> Hi!
> 
> I recently bumped into eudev, a fork of systemd-udev 220 which doesn't
> require all the rest of systemd. The gentoo folks came up with it as
> many of them still use OpenRC or SystemV init.
> It was easy to port it to OpenWrt by re-using and modifying the
> existing udev packaging. See
> https://github.com/openwrt/packages/pull/2354
> 
> However, there are some problems which I'd like to discuss:
> * PROVIDES and CONFLICTS doesn't work well in opkg and proper support
>   for alternative packages (except for build-variants) is missing in
>   buildroot. Any idea on how this could be fixed?
> * Why is udev-173 part of core? I can't see what actually depends on it
>   since udevtrigger is provided by procd for ages now.
> * eudev and udev conflict also in terms of InstallDev providing the
>   same header filenames and consuming packages expect to find them
>   there. This means they cannot co-exist in the same buildroot without
>   overwriting each others staging files...
> * We could just switch to eudev instead of the (unmaintained and
>   outdated) version of udev we currently got -- however,
> * eudev got almost twice of the binary size of udev...
> 
> The main reason why I'd like to have udev is persistent aliasing of
> (hotpluggable) serial devices like wwan modems and input devices; udev
> is required for libinput to build.
> 
> Please share your ideas and opinions on the issues above and whatever
> else comes to your mind when you think about udev and linux hotplug on
> OpenWrt!
> 
> 


maybe i am missing the point but why would you want udev on your system
in the first place ?


> Cheers
> 
> 
> Daniel
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


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

2016-02-07 Thread John Crispin


On 07/02/2016 10:53, Daniel Golle wrote:
> Hi John!
> 
> On Sun, Feb 07, 2016 at 10:28:25AM +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 the both implementations (udev and eudev) are over-bloated
> and I'm sure that the use-cases I'm interested in can be provided by
> a few dozend lines of code and a few kilobytes in binary instead of
> that 1.2M executable which includes support for all sorts of weird
> legacy stuff like 3.5" floppy drivers conencted via USB...
> 
> 
> Cheers
> 
> 
> Daniel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


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

2016-02-07 Thread Daniel Golle
Hi John!

On Sun, Feb 07, 2016 at 10:28:25AM +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

I agree that the both implementations (udev and eudev) are over-bloated
and I'm sure that the use-cases I'm interested in can be provided by
a few dozend lines of code and a few kilobytes in binary instead of
that 1.2M executable which includes support for all sorts of weird
legacy stuff like 3.5" floppy drivers conencted via USB...


Cheers


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


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

2016-02-07 Thread Felix Fietkau
On 2016-02-07 10:22, Daniel Golle wrote:
> Hi!
> 
> I recently bumped into eudev, a fork of systemd-udev 220 which doesn't
> require all the rest of systemd. The gentoo folks came up with it as
> many of them still use OpenRC or SystemV init.
> It was easy to port it to OpenWrt by re-using and modifying the
> existing udev packaging. See
> https://github.com/openwrt/packages/pull/2354
> 
> However, there are some problems which I'd like to discuss:
> * PROVIDES and CONFLICTS doesn't work well in opkg and proper support
>   for alternative packages (except for build-variants) is missing in
>   buildroot. Any idea on how this could be fixed?
> * Why is udev-173 part of core? I can't see what actually depends on it
>   since udevtrigger is provided by procd for ages now.
I think it was probably simply forgotten - we should just delete it from
trunk.

> * eudev and udev conflict also in terms of InstallDev providing the
>   same header filenames and consuming packages expect to find them
>   there. This means they cannot co-exist in the same buildroot without
>   overwriting each others staging files...
> * We could just switch to eudev instead of the (unmaintained and
>   outdated) version of udev we currently got -- however,
> * eudev got almost twice of the binary size of udev...
I don't really care about the binary size increase, I don't think many
people need udev.

> The main reason why I'd like to have udev is persistent aliasing of
> (hotpluggable) serial devices like wwan modems and input devices; udev
> is required for libinput to build.
Interesting.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


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

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


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

2016-02-07 Thread Daniel Golle
Hi John,

On Sun, Feb 07, 2016 at 11:33:00AM +0100, John Crispin wrote:
> >> 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.

I shall investigate and maybe suggest an implementation for persistent
aliases of serial devices inside procd within the next weeks.

> > However, e.g. libinput uses a quite wide set of udev's functions:
> > [...]
> 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.

Ok, so I'd suggest to drop udev from OpenWrt core and provide eudev via
the packages feed for things which require it beyond the core use-cases
OpenWrt is designed for. Does that sound agreeable to everyone?


About the GUI libraries, please consider devices like those:

This 4" touch-screen doesn't exactly make it a desktop device, I'm not
planning to run libreoffice and firefox on top of Gnome shell and all
that... it's still a special-purpose thing, just that it warns you when
your shitty smart TV calls home or shows some bandwidth graphs, allows
you to enter credentials for authentication with the ISP or provide a
password for cryptsetup storage on your NAS box -- in a way which
doesn't depend on other devices (usually running a vulnerable browser
and a proprietary or at least tainted OS) to be free from keyloggers,
rootkits and all that...

OpenWrt is a nice platform for all sorts of so-called 'IoT' stuff which
in some cases could use udev for meaningful things and yet it's not at
all a desktop system -- think of printers, scanners, IoT remotes with
touch-screens, fridges, coffee-machines and also (outdated) mobile
phones running vanilla Linux like the Nokia N9 and yet no useful
minimalistic GUI... I'd love to see EFL on top of OpenWrt running on
the N9 without all the bloat of Android, Tizen, MER, megoo and
what-not...



Cheers


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


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

2016-02-07 Thread John Crispin


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