From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amir Goldstein Subject: Re: RFC: Device Namespaces Date: Tue, 10 Sep 2013 09:09:31 +0200 Message-ID: References: <20130822182118.GA28331@sergelap> <8761udlu0d.fsf@xmission.com> <871u4yddg4.fsf@xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <871u4yddg4.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Eric W. Biederman" Cc: Linux Containers , lxc-devel List-Id: containers.vger.kernel.org On Mon, Sep 9, 2013 at 2:51 AM, Eric W. Biederman wrote: > Amir Goldstein writes: > > > On Fri, Sep 6, 2013 at 7:50 PM, Eric W. Biederman > > 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. > As a matter of fact, in our multi persona phone, you *can* hear music played from background persona, but you *cannot* see images drawn from background persona. > 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. > I agree about it being arguable :-) We shall present our arguments on LPC. > > 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. > > It's true that for our product, we have made hardcoded policy decisions in our kernel patches, but that was just as a proof of concept for the technique. We do envision being able to dynamically assign a device to a specific devns (e.g. block,loop) keep a device shared between multi devns (e.g. audio) and in addition to that, being able to multiplex a device between multi devns (e.g. framebuffer) > Eric >