On Mon, Apr 14, 2014 at 10:03 AM, Zbigniew Jędrzejewski-Szmek <zbys...@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 >> <zbys...@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 >> >> <zbys...@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 <k...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel