<div dir="ltr">My use case for having device namespaces is device isolation. Isn't what namespaces are there for (as I understand)? Not everything should be accessible (or even visible) from a container all the time (we have seen people come up with different use cases for this). However, bind-mounting takes away this flexibility. I agree that assigning fixed device numbers is clearly not a long-term solution. Emulation for safe and flexible multiplexing, like you suggested either using CUSE/FUSE or something like devpts, is what I'm exploring.<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 24, 2014 at 12:04 AM, Eric W. Biederman <span dir="ltr"><<a href="mailto:ebiederm@xmission.com" target="_blank">ebiederm@xmission.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>riya khanna <<a href="mailto:riyakhanna1983@gmail.com" target="_blank">riyakhanna1983@gmail.com</a>> writes:<br>
<br>
> (Please pardon multiple emails, artifact of merging all separate conversations)<br>
><br>
> Thanks for your feedback!<br>
><br>
> Letting the kernel know about what devices a container could access (based on<br>
> device cgroups) and having devtmpfs in the kernel create device nodes for a<br>
> container that map to corresponding CUSE nodes is what I thought of. For<br>
> example, "echo 29:0 > /proc/<pid>/devices" would prepare a virtual framebuffer<br>
> (based on real fb0 SCREENINFO properties) for this process provided permissions<br>
> allow this operation. To view the framebuffer, the CUSE based virtual device<br>
> would talk to the actual hardware. Since namespaces would have different view of<br>
> the underlying devices, "sysfs" has to made aware of this as well.<br>
><br>
> Please let me know your inputs. Thanks again!<br>
<br>
</span>The solution hugely depends on what you are trying to do with it.<br>
<br>
The situation today is that device nodes are slowly fading out.  In<br>
another 20 years linux may not have any device nodes at all.<br>
<br>
Therefore the question becomes what are you trying to support.<br>
<br>
If it is just filtering of existing device nodes.  We can do a pretty<br>
good approximation with bind mounts.<br>
<br>
If you want to emulate a device you can use normal fuse (not cuse).<br>
As normal fuse file will support arbitrary ioctls.<br>
<br>
There are a few cases where it is desirable to emulate what devpts<br>
does for allowing arbitrary users to creating virtual devices in the<br>
kernel.  Loop devices in particular.<br>
<br>
Ultimately given the existence of device hotplug I don't see any call<br>
for being able to create device nodes with well known device numbers<br>
(fundamentally what a device namespace would be about).<br>
<br>
The conversation last year was about people wanting to multiplex devices<br>
that don't have multiplexer support in the kernel.  If that is your<br>
desire I think it is entirely reasonable to device type by device type<br>
add support for multiplexing that device type to the kernel, or<br>
potentially just use fuse or cuse to implement your multiplexer in<br>
userspace but that has the potential to be unusably slow.<br>
<br>
Eric<br>
--<br>
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in<br>
the body of a message to <a href="mailto:majordomo@vger.kernel.org" target="_blank">majordomo@vger.kernel.org</a><br>
More majordomo info at  <a href="http://vger.kernel.org/majordomo-info.html" target="_blank">http://vger.kernel.org/majordomo-info.html</a><br>
Please read the FAQ at  <a href="http://www.tux.org/lkml/" target="_blank">http://www.tux.org/lkml/</a><br>
</blockquote></div><br></div></div></div>