Serge E. Hallyn wrote: > Quoting Daniel Lezcano ([email protected]): > >> Serge E. Hallyn wrote: >> >>>> The idea of Kamezawa-san to use a fuse proc is maybe a good idea in >>>> this case. So we can address the entire /proc specific informations. >>>> For >>>> >>> I agree, nice idea. And hopefully pretty simple to whip up for the >>> meminfo and cpuinfo files as an example. >>> >>> Are you thinking a fuse fs which takes a config file, holds an open >>> ref to its ancestor /proc, and for each file looks in a config file to >>> decide whether to show userspace: >>> 1. nothing >>> 2. the underlying file, unprocessed >>> 3. a simple ascii file instead >>> 4. the underlying file, processed? >>> >>> >> Yes, exactly :) >> But, I am not sure how to retrieve the container context, I mean how to >> pick and return the right information. >> eg: in the container foo, when looking at /proc/meminfo, fuse-lxcfs >> should process /cgroup/foo/(somefiles), how to know the request is >> coming from 'foo' without doing multiple mount, one in each container ? >> > > Why without doing one mount per container? :) > > I figure the container can be responsible for the actual mounting, > if it cares. The host/kernel should keep it *safe* for the container > to use unfiltered /proc (, /sys, /cgroup, etc), but the container > can be responsible for filtering it however much it feels necessary. > > (That fits with the 2006 kernel summit pseudo-decree that we are not > trying to fake a container into thinking it is a real host, only > make the container useful.) > > Are you worried about the extra memory overhead? >
Well, I am used to see a single instance of a daemon like sshfs :) I am not used of fuse, I will play a bit with a trivial fuse-lxcfs to see how that behaves with a container. _______________________________________________ Containers mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list [email protected] https://openvz.org/mailman/listinfo/devel
