Bug#827704: udev is not portable and mandates kernel features

[Pierre Ynard]

Package: udev
Version: 230-2
Severity: wishlist

When trying to upgrade udev from version 175-7.2 to 230-2, I get greeted
by the:

> Since release 198, udev requires support for the following features in
> the running kernel:
> 
> - inotify(2)            (CONFIG_INOTIFY_USER)
> - signalfd(2)           (CONFIG_SIGNALFD)
> - accept4(2)
> - open_by_handle_at(2)  (CONFIG_FHANDLE)
> - timerfd_create(2)     (CONFIG_TIMERFD)
> - epoll_create(2)       (CONFIG_EPOLL)

Thank you for the preinst check and documenting in more details in the
README. However, some of these requirements seem unwarranted, backwards
and frankly outrageous. Decent software should make a minimum effort at
portability, and not direct the underlying system around.

- accept4() can be trivially emulated on ENOSYS. Any portable software
  will do that trivial job. I don't believe that SOCK_CLOEXEC race
  conditions would be a crippling issue for udev.

- epoll is just one out of many polling APIs. Any portable software will
  fall back onto more common APIs like poll() or even select(), and wrap
  around them or emulate missing features. Frankly, mandating epoll like
  there's no way around it is simply appalling. epoll has main scaling
  and performance purposes, but polling performance does not seem to be
  any relevant for udev, really.

- timerfd_create() and signalfd() are just convenience APIs around the
  more pervasive mechanisms of timers and signal handling. Equivalent
  functionality can be emulated with a handler that writes into a pipe;
  at any rate, they do not seem required to do the job.

I don't need to delve into the other items because the point is already
clear.

I can understand mandating stuff like CONFIG_DEVTMPFS, since it's
actually a major feature core to udev business, and would even be a
paradigm shift. I can understand mandating CONFIG_SYSFS_DEPRECATED=n
since that's within core udev business too. But most of the items above
have nothing particular to do with udev, and are just generic APIs.
Generic API availability gets properly managed, detected, emulated or
gracefully handled in portable software, not mandated; and the more
generic and trivial the API, the less understandable it is.

For the sake of openness, the feature missing on my system is
CONFIG_FHANDLE. It's not hidden under CONFIG_EXPERT like some others,
and the current Linux kernel Kconfig help only mentions "userspace
file servers", not a system component like udev, so I did not think
much of it. I can vaguely imagine how it would be useful (although not
necessary) to udev, and I don't really mind enabling it, but this is not
this point of the bug report - the principle is.

Please improve the portability of udev and reduce or eliminate the above
list of required non-essential features.

udev is a basic package that would be installed on most systems. On
mine, it still remains depended on by X.Org (for very understandable
reasons); it cannot be removed, nor substituted by any alternative. As
such, anything the udev package imposes has consequences that take away
user choice on a distribution-wide scale. Please provide and/or document
the ability to remove udev or substitute alternatives for it.

As a last resort, please make this apparent lack of portability more
understandable for users. The information in the README is a very good
start already, I appreciate it, but please complete it to document
what requires the features in the above list and foremost why they
are essential. Lack of portability, and mandating features in other
system components from such a basic and pervasive package, set a bad
example for software; please document, explain and present in a more
understandable way this approach and its outstanding, exceptional
and/or discouraged character. Please improve the most visible part of
it, the output of the preinst check, to make it sound less entitled
and outrageous to upgrading users, especially in view of some of the
required features in the list.

After taking care of this bug report I'm looking forward to being
able to upgrade udev, I hope I won't run into any more hurdle. The
changelog looks good, and I'm looking forward to being able to disable
CONFIG_UEVENT_HELPER :)

Thanks,


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.6-grsec (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages udev depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  libc6                  2.22-11
ii  libselinux1            2.5-3
ii  libudev0               175-7.2
ii  lsb-base               9.20160601
ii  procps                 2:3.3.11-3
ii  util-linux             2.28-5

Versions of packages udev recommends:
ii  pciutils  1:3.3.1-1.1
ii  usbutils  1:007-4

udev suggests no packages.

-- debconf information:
  udev/title/upgrade:
  udev/reboot_needed:
  udev/new_kernel_needed: false
  udev/sysfs_deprecated_incompatibility: