On 3/18/2013 11:45 PM, Eric W. Biederman wrote: > I will say what I have said elsewhere recently to ensure the idea > percolates. What can be implemented now without kernel support and > that is interesting is devtmpfs emulation. That is a tmpfs filesystem > inside the container to serve as /dev. A process outside the container > (with not particular privileges) that has acess to the container's > dev. The process would then wait for a uevent, and based on some > policy do roughly touch /containerpath/dev/name; mount --bind > /dev/name /containerpath/dev/name Or umount -l > /containerpath/dev/name; unlink /containerpath/dev/name. The normal > udev policy would then have to allow the users in the container access > to those device nodes. I think that is simple and pretty doable right > now without much code. I suppose I stupid version could even safely > propogate all device nodes into a container that uses user namespaces > without danger. Which implies an even simpler solution for user > namespace based containers. Except for special cases it is possible > and safe to just share the same /dev filesystem inside and outside of > the container. That means /dev/ptmx needs to link to /dev/pts/ptmx and > that you can't pretend to have /dev/ttyN inside the contianer but I > can't think of any other downsides. Eric So here's the scenario that I'd like to find a solution for:
I have two "identical" USB devices, A and B, and I plug them into the host system, in some arbitrary order. What I would like to be able to do is assign A to container 1, and B to container 2. Irrelevant of whether A or B is inserted first into the system. I'd like the two devices to be "staged" into the host, and then following some administrative action A is bound to container 1, and B is bound to container 2. If the devices are USB serial ports, one will become ttyUSB0, and the other will be ttyUSB1. Which device gets assigned to which name, barring some tagging is insertion order dependent. There is external knowledge that must be provided to make the association, namely that the back end of those serial ports are connected to different physical piece of hardware, independent of which USB slot that the cable is plugged into. I was thinking that a hotplug script running on the host could do something like you describe. I would have to disable the propagation of the uevent to the container, or simply remove the capability of doing mknod from the container completely. I'm still trying to figure out why the udev running in my Gentoo container doesn't create devices even though it has the capability to do so. ---Michael J Coss ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
