Amir Goldstein <amir@xxxxxxxxxxx> writes: > On Fri, Sep 6, 2013 at 7:50 PM, Eric W. Biederman > <ebiederm@xxxxxxxxxxxx> wrote: > > Hi Eric, > > If we can get people to take a quick look at the code before LPC > that could make the LPC discussions more effective. > Even looking at one of the subsystem patches can give a basic > idea of the work we have done: > https://github.com/Cellrox/linux/commits/devns-goldfish-3.4 > > I think you are talking about having wrappers around your devices > so you > can share. Which is not the quite same problem the rest of us > have been > thinking of when talking about a device namespace. > > We are interested in all problems related to virtualizated view of > devices > inside a container, so let our work so far be a starting point to > discuss all of them. > > My first impression is that this is better solved with more > appropriate > abstractions in userspace or in the kernel. As I read your code, you are solving the problem of one opener of a device among a group of openers being able to access a device at a time. Which leads to the question why can't the multiplexing happen in userspace? I think with your design it would not be possible to play a song in one device namespace while doing work in the other. As a security model that isn't wrong but as someone trying to get work done that could be a real pain. The more common concern is to have devices we can use all of the time. There may be a need for a device namespace and multiplexing access to hardware devices makes that clearer. So far nothing has risen to the level of we actually need a device namespace to do X. Especially in an erra of hotplug and dynamic device numbers. It is arguable that you could do your kind of device multiplexing with a fuse device in userspace that implements your desired policy. And policy is where cell situtation seems to fall down because it hard codes one specific policy into the kernel, and a policy most situations don't find useful. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
