Re: Device Namespaces

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)]

"Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> writes:

> Quoting Andy Lutomirski (luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org):
>> On Tue, Oct 1, 2013 at 7:19 AM, Janne Karhunen <janne.karhunen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman
>> > <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
>> >
>> >>> - We can relay a call of /sbin/hotplug from outside of a container
>> >>>   to inside of a container based on policy.
>> >>>   (But no one uses /sbin/hotplug anymore).
>> >>
>> >> That's right, they should be listening to libudev events, so why can't
>> >> your daemon shuffle them off to the proper container, all in userspace?
>> >
>> > Which reminds me, one potential reason being..
>> > http://lists.linuxfoundation.org/pipermail/containers/2013-May/032591.html
>> >
>> 
>> Can't the daemon live outside the container and shuffle stuff in?
>
> That's exactly what Michael Warfield is suggesting, fwiw.

Michael Warfields example of dynamically assigning serial ports to
containers is a pretty good test case.  Serial ports are extremely well
known kernel objects who evolution effectively stopped long ago.  When
we need it we have ptys to virtual serial ports when we need it, but in
general unprivileged users are safe to directly use a serial port
device.

Glossing over the details.  The general problem is some policy exists
outside of the container that deciedes if an when a container gets a
serial port and stuffs it in.

The expectation is that system containers will then run the udev
rules and send the libuevent event.  

To make that all work without kernel modifications requires placing
a faux-udev in the container, that listens for a device assignment from
outside the container and then does exactly what udev would have done.

The problems with this that I see are:

- udev is a moving target making it hard to build a faux-udev that will
  work everywhere.

- On distro's running systemd and udev integration is sufficiently tight
  that I am not certain a faux-udev is possible or will continue to be
  possible.

- There are two other widely deployed solutions for managing hotplug
  devices besides udev.

So given these difficulties I do not believe that the evolution of linux
device management is done, and that patches to udev, the kernel or both
will be needed.  While it would be good for testing and understanding
the problem I don't think a faux-udev will be a long term maintainable
solution.

I also understand the point that we aren't talking patches yet and just
discussing ideas.  Right now it is my hope that if we talk this out we
can figure out a general direction that has a hope of working.

From where I am standing faking uevents instead of replacing
udev/mdev/whatever looks simpler and more maintainable.

Eric