On Sun, Sep 29, 2013 at 10:28:55PM +0300, Amir Goldstein wrote:
> 
> 
> 
> On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman 
> <gre...@linuxfoundation.org
> > wrote:
> 
>     On Wed, Sep 25, 2013 at 02:34:54PM -0700, Eric W. Biederman wrote:
>     > So the big issues for a device namespace to solve are filtering which
>     > devices a container has access to and being able to dynamically change
>     > which devices those are at run time (aka hotplug).
> 
>     As _all_ devices are hotpluggable now (look, there's no CONFIG_HOTPLUG
>     anymore, because it was redundant), I think you need to really think
>     this through better (pci, memory, cpus, etc.) before you do anything in
>     the kernel.
> 
>     > After having thought about this for a bit I don't know if a pure
>     > userspace solution is sufficient or actually a good idea.
>     >
>     > - We can manually manage a tmpfs with device nodes in userspace.
>     >   (But that is deprecated functionality in the mainstream kernel).
> 
>     Yes, but I'm not going to namespace devtmpfs, as that is going to be an
>     impossible task, right?
> 
> 
> That sounds like a challenge ;-)
> Seriously, as Serge correctly noted, it would not be that different from 
> devpts
> if you start from an empty devtmpfs and populate it with devices that are
> "added in the context of that namespace".  The semantics in which
> devices are "added in the context of a namespace" is the missing piece
> of the puzzle.

And the fact that these devices are almost all created before userspace
starts up, is a non-trivial "piece of the puzzle" :)

Good luck,

greg k-h

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Reply via email to