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

[Kay Sievers]

On Mon, Apr 14, 2014 at 10:03 AM, Zbigniew Jędrzejewski-Szmek
<zbyszek at in.waw.pl> wrote:
> 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.

It is not a stub, things will just block for any/all events now,
ignoring the specific sequence numbers given in the API.

Kay