Re: Device Namespaces

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

Amir Goldstein <amir-3AfRa/s5aFdBDgjK7y7TUQ@public.gmane.org> writes:

> What we really like to see is a setns() style API that can be used to
> add a device in the context of a namespace in either a "shared" or
> "private" mode.

I think you mean an "ip link set dev FOO netns XXX" style API.

Right now one of the best suggestions on the table is:

mkdir -p /dev/container/X
ln /dev/zero /dev/container/X/zero
ln /dev/null /dev/container/X/null
...

With /dev/container/X mounted on /dev for container X.

Which seems to cover putting a device in a namespace, while allowing
things to still be reasonably managed.

There are a few other variations on that scheme but nothing that says we
must have kernel support or to create any kind of kernel context beyond
which directory the device nodes live in.

> This kind of API is a required building block for us to write device
> drivers that are namespace aware in a way that userspace will have
> enough flexibility for dynamic configuration.
>
> We are trying to come up with a proposal for that sort of API.  When
> we have something decent, we shall post it.

I really think what you need to write are special drivers that
facilitate your use case.

For the networking stack we wound up adding veth pairs, and macvlan
devices, to handle the common sharing modes.

Outside of your sharing situation I am not seeing any need or any
advantage of creating devices that are modified to be sharable and I am
seeing a lot of disadvantages to implementing things that way.  The
biggest is that you seem to working independent of the subsystem
maintainers of those devices which is generally a poor idea.

Unprivileged creation of device nodes we can handle if it can be shown
that it is safe to create device nodes.

As I understand your problem you are trying to multiplex a device by
building a device with a built in stop light.  Where one opener can
write and the other openers are stopped/dropped.  That sounds very
similar to macvlan, or ethernet bridging.   From the patches you have
floated I suspect it would be very simple to build and just need a
little bit of glue.

Eric