"Paul Menage" <[EMAIL PROTECTED]> writes: > On 3/7/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote: >> >> All that being said, if it were going to save space without overly >> complicating things I'm actually not opposed to using nsproxy, but it > > If space-saving is the main issue, then the latest version of my > containers patches uses just a single pointer in the task_struct, and > all tasks in the same set of containers (across all hierarchies) will > share a single container_group object, which holds the actual pointers > to container state.
Yes. However: > Effectively, container_group is to container as nsproxy is to namespace. The statement above nicely summarizes the confusion in terminology. In the namespace world when we say container we mean roughly at the level of nsproxy and container_group. Although it is expected to be a user space concept like an application, not a concept implemented directly in the kernel. i.e. User space is expected to combine separate resource controls and namespaces and run processes inside that combination. You are calling something that is on par with a namespace a container. Which seriously muddies the waters. About as much as calling as referring to your shoe as your whole outfit. Without fixing the terminology it is going to be very hard to successfully communicate. Eric ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
