Quoting Daniel Lezcano (daniel.lezcano@xxxxxxx): > 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? -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
