[Devel] Device Namespaces

[Greg Kroah-Hartman]

On Tue, Oct 01, 2013 at 12:51:36PM -0700, Eric W. Biederman wrote:
> "Serge E. Hallyn" <serge at hallyn.com> writes:
> 
> > Quoting Andy Lutomirski (luto at amacapital.net):
> >> On Tue, Oct 1, 2013 at 7:19 AM, Janne Karhunen <janne.karhunen at gmail.com> wrote:
> >> > On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman
> >> > <gregkh at linuxfoundation.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.

How is udev a moving target?  Use libudev and all should be fine, that's
an ABI you can rely on, right?

Or, if you don't like/want udev, use mdev in your container.  Or
something else, what does this have to do with the kernel?

> - 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.

That's not a kernel issue, that's a "ouch, this is hard, let's give up"
issue.

Or perhaps it is a "maybe I shouldn't even be trying to do this" type
issue... :)

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

I know of mdev, what's the other one?  The hacked-up shell script that
Android uses?  Or something else?

> 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.

You are saying that for some reason you feel helpless with the way
userspace is going, so we have to change the kernel.  That's horrible,
and is not going to be a reason I accept to change the kernel, sorry.

> 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.

Have you really looked into this?  Numerous people, who understand this
code path and userspace issues, have said it is not a good idea at all.

But hey, what do I know...

I still have yet to see a reason why you can't use libudev today for
something like this.

Anyway, I'm done discussing this as it's pointless this early, I'm going
to refrain for any more pithy comments until someone posts some code, as
this is just wasting people's time at the moment.

greg k-h