<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 24, 2014 at 5:38 PM, 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">Riya Khanna <<a href="mailto:riyakhanna1983@gmail.com">riyakhanna1983@gmail.com</a>> writes:<br>
<br>
> On Sep 24, 2014, at 12:43 PM, Eric W. Biederman <<a href="mailto:ebiederm@xmission.com">ebiederm@xmission.com</a>> wrote:<br>
><br>
>> Serge Hallyn <<a href="mailto:serge.hallyn@ubuntu.com">serge.hallyn@ubuntu.com</a>> writes:<br>
>><br>
>>> Isolation is provided by the devices cgroup.  You want something more<br>
>>> than isolation.<br>
>>><br>
>>> Quoting riya khanna (<a href="mailto:riyakhanna1983@gmail.com">riyakhanna1983@gmail.com</a>):<br>
>>>> My use case for having device namespaces is device isolation. Isn't what<br>
>>>> namespaces are there for (as I understand)?<br>
>><br>
>> Namespaces fundamentally provide for using the same ``global'' name<br>
>> in different contexts.  This allows them to be used for isolation<br>
>> and process migration (because you can take the same name from<br>
>> machine to machine).<br>
>><br>
>> Unless someone cares about device numbers at a namespace level<br>
>> the work is done.<br>
>><br>
>> The mount namespace provides exsits to deal with file names.<br>
>> The devices cgroup will limit which devices you can access (although<br>
>> I can't ever imagine a case where the mout namespace would be<br>
>> insufficient).<br>
>><br>
>>>> Not everything should be<br>
>>>> accessible (or even visible) from a container all the time (we have seen<br>
>>>> people come up with different use cases for this). However, bind-mounting<br>
>>>> takes away this flexibility.<br>
>><br>
>> I don't see how.  If they are mounts that propogate into the container<br>
>> and are controlled from outside you can do whatever you want.  (I am<br>
>> imagining device by device bind mounts here).  It should be trivial<br>
>> to have a a directory tree that propogates into a container and works.<br>
>><br>
><br>
> Device-by-device bind mounts can grant/revoke access to real<br>
> individual devices as and when needed. However, revoking the access to<br>
> real devices could break the applications if there’s no transparent<br>
> mechanism to back up the propagated (but now revoked) device bind<br>
> mounts that could fool the apps into believing that they are working<br>
> with real devices. Frame buffer is one such example, where safe<br>
> multiplexing could be applied.<br>
><br>
>>>> I agree that assigning fixed device numbers is<br>
>>>> clearly not a long-term solution. Emulation for safe and flexible<br>
>>>> multiplexing, like you suggested either using CUSE/FUSE or something like<br>
>>>> devpts, is what I'm exploring.<br>
>><br>
>> Is the problem you actually care about multiplexing devices?<br>
>><br>
><br>
> The problem I care about is access to real devices, such as input, fb,<br>
> loop, etc. as and when needed, thereby having native I/O performance -<br>
> either through secure multiplexing or exclusive ownership, whatever<br>
> makes sense according to the device type.<br>
<br>
Riya Khanna <<a href="mailto:riyakhanna1983@gmail.com">riyakhanna1983@gmail.com</a>> writes:<br>
<br>
> I guess policy-based multiplexing (or exclusive ownership) is the<br>
> usage. What kind of devices (loop, fb, etc.) this is needed for<br>
> depends on the usage. If there are multiple FBs, then each container<br>
> could potentially own one. One may want to provide exclusive ownership<br>
> of input devices to one container at a time to avoid information<br>
> leakage. Like we saw at LPC last year, this applies to sensors (gps,<br>
> accelerometer, etc.) on mobile devices as well.<br>
<br>
Allowing mutiplexing of those devices seems reasonable.<br>
<br>
Where the discussion ran into problems last time was that people did not<br>
want to use any of the existing linux solutions for multiplexing those<br>
kind of thing and wanted to invent something new.<br>
<br>
Inventing something new is fine if it the extra code maintenance can be<br>
justified, or if the invention just a better solution for all users and<br>
new code can just start using that in general.<br>
<br>
The old solution to your problem of multiplexing devices is by<br>
allocating a virtual terminal nd sending signals to coordinate<br>
cooperatively sharing those resources.<br>
<br>
If you want some sort of preemtive multitasking that requires<br>
something a bit more effort, and work in the device abstractions.<br>
You may be able to share concepts and library code but I don't believe<br>
there is something you can just pain on top of devices and make it<br>
happen.  Certainly in the bad old days of X terminal switching the<br>
cooperation was necessary so that when a video card was yanked from an<br>
application writing directly to that video card the application would<br>
need to restore the video card to a known state so the next application<br>
would have a chance of making sense of it.   Furthermore most devices<br>
are not safe to let unprivileged users to access their control registers<br>
directly.<br>
<br>
All of which boils down the simple fact that for each type of device you<br>
would like to share it is necessary to update the subsystem to support<br>
arbitrary numbers of virtual devices that you can talk to.<br>
<br>
The macvlan driver in the networking stack is a rough example of what I<br>
expect you would like.  Something that takes one real physical device<br>
and turns it into N virtual devices each of which runs at effectively<br>
full speed.  Along with some kind of new master interface for<br>
controlling when the multiplexing takes place.<br>
<br>
I think we do most of this is software today and arguably for a lot of<br>
devices the overhead is small enough that a software solution is fine.<br>
So perhaps all you need is a fuse interface to the existing software<br>
multiplexers so that weird legacy code can be made to run.<br>
<br></blockquote><div><br></div><div>What kind of existing multiplexers could be used? Is there one for fb? We have evdev abstractions for input in place already.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Now I suspect part of doing this right will be getting proper video<br>
drivers on Android.  I assume that Android is the platform you care<br>
about.<br>
<span class=""><font color="#888888"><br>
Eric<br>
<br>
<br>
</font></span></blockquote></div><br></div></div>