On Fri, Jul 12, 2013 at 4:49 PM, Daniel P. Berrange <[email protected]> wrote: > On Fri, Jul 12, 2013 at 04:42:34PM +0200, Kay Sievers wrote: >> On Fri, Jul 12, 2013 at 4:21 PM, Kay Sievers <[email protected]> wrote: >> > On Fri, Jul 12, 2013 at 4:14 PM, Daniel P. Berrange <[email protected]> >> > wrote: >> >> On Fri, Jul 12, 2013 at 04:10:35PM +0200, Kay Sievers wrote: >> > >> >>> Hmm, we just don't really support running udev inside of containers. >> >>> Hotplug and full OS containers have did never get any real attention >> >>> from udev running inside container setups. >> >> >> >> This example is *not* running udev in the container. The 'udevadm settle' >> >> command above is being run in the primary OS. IOW, the fact that the >> >> container has a network namespace with a veth, is breaking udevadm in >> >> the host. >> > >> > Oh, interesting. I thought you meant running 'settle' inside the container. >> > >> > That, then sounds like something we should be able cope with. I'll >> > have a look now ... >> >> The kernel uevents generated inside the network namespace use the same >> single global sequence number as the host, but the events for the >> in-namespace devices are simply filtered out not to show up in the >> host. >> >> Settle expects to see *all* sequence numbers to wait for, and does not >> accept holes in the sequence. >> >> Hmm, at this moment, I have no idea how that should work, we cannot >> easily find out that these events will never show up in the host and >> we should not wait for them. >> >> The uevent filter hack in the kernel maybe should just be changed to >> not allocate sequence numbers of the *host* inside the namespace, and >> always compose the events inside the namespace with SEQNUM=0. > > Ewww, yes, that's pretty nasty kernel behaviour/change there :-(
The sequence numbers were done to track queued events in the host and to wait for them, having the netns hack "stealing" the devices in /sys and the uevents by filtering seems to work ok, but stealing our sequence numbers is pretty nasty. :) Yeah, we need to find out what other options we have. Maybe there is a way to reliably work around that issue in udev, but at this moment I don't really see how ... Kay _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
