[systemd-devel] [systemd-commits] Makefile.am man/udevadm.xml src/libudev src/shared src/test src/udev

[Zbigniew Jędrzejewski-Szmek]

On Mon, Apr 14, 2014 at 09:51:08AM -0700, Kay Sievers wrote:
> On Mon, Apr 14, 2014 at 9:39 AM, Zbigniew Jędrzejewski-Szmek
> <zbyszek at in.waw.pl> wrote:
> > On Mon, Apr 14, 2014 at 09:29:54AM -0700, Kay Sievers wrote:
> >> On Mon, Apr 14, 2014 at 8:52 AM, Zbigniew Jędrzejewski-Szmek
> >> <zbyszek at in.waw.pl> wrote:
> >> > On Sun, Apr 13, 2014 at 04:58:31PM -0700, Kay Sievers wrote:
> >> >>  Makefile.am                         |    6
> >> >>  man/udevadm.xml                     |   22 -
> >> >>  src/libudev/libudev-monitor.c       |   17 -
> >> >>  src/libudev/libudev-queue-private.c |  406 ------------------------------------
> >> >>  src/libudev/libudev-queue.c         |  302 ++------------------------
> >> >>  src/libudev/libudev.h               |   10
> >> >>  src/shared/udev-util.h              |    2
> >> >>  src/test/test-libudev.c             |   24 --
> >> >>  src/udev/udev-ctrl.c                |    2
> >> >>  src/udev/udevadm-settle.c           |  131 +----------
> >> >>  src/udev/udevd.c                    |   59 ++---
> >> >>  11 files changed, 84 insertions(+), 897 deletions(-)
> >> >>
> >> >> New commits:
> >> >> commit 9ea28c55a2488e6cd4a44ac5786f12b71ad5bc9f
> >> >> Author: Kay Sievers <kay at vrfy.org>
> >> >> Date:   Sat Apr 12 22:35:50 2014 -0700
> >> >>
> >> >>     udev: remove seqnum API and all assumptions about seqnums
> >> >>
> >> >>     The way the kernel namespaces have been implemented breaks assumptions
> >> >>     udev made regarding uevent sequence numbers. Creating devices in a
> >> >>     namespace "steals" uevents and its sequence numbers from the host. It
> >> >>     confuses the "udevadmin settle" logic, which might block until util a
> >> >>     timeout is reached, even when no uevent is pending.
> >> >>
> >> >>     Remove any assumptions about sequence numbers and deprecate libudev's
> >> >>     API exposing these numbers; none of that can reliably be used anymore
> >> >>     when namespaces are involved.
> >> > Hi Kay,
> >> > maybe we should make the deprecation process a bit gentler: instead of
> >> > ripping out the functionality in one step, instead just deprecate the
> >> > functions, and allow people to use them, with the caveat that launching
> >> > a namespace and creating devices in it will break this functionality.
> >> > Then after a few releases, actually remove the functionality. Not everyone
> >> > uses namespaces, and that'd be a nod towards those poeple. Would
> >> > that be possible?
> >>
> >> Not really, because the API relies on the queue tracking data.
> >>
> >> But for the queue tracking logic to not break current setups, it would
> >> need to be updated/rewritten to handle holes in the sequence numbers;
> >> with current kernels it is just broken whenever namespaces are
> >> involved. We just did not notice, because we do not use "settle" with
> >> systemd.
> > I'm not volunteering to rewrite the logic to handle holes. Instead I'm
> > suggesting that we keep the current (as of before this commit) logic, to
> > cater to people who use it successfully when no namespaces are involved.
> >
> >> I don't think it is worth to try to make the specific queue tracking
> >> logic work again, it is not a useful API and it makes promises we
> >> cannot hold.
> > I'm not suggesting that. But maybe keeping the partially broken logic
> > around for a while might be more useful for some people than outright
> > removal.
> 
> It is currently broken for our own setups, unit files use namespaces
> in default setups.
I know.

> We cannot just keep the status quo and pretend it works, things are
> broken now and need to be fixed.
Yes.
 
> We would need to rewrite the logic behind the API, or get rid of it; I
> decided for removal, because the assumptions the API makes are not
> valid anymore.
Yes, but udev is also used in different setups... Documenting things as
deprecated is one thing, but replacing implementation by stub functions
is another. People who use this functionality would probably prefer to
have some time to move off it.

Zbyszek