pagg
[Top] [All Lists]

Re: [ckrm-tech] Re: [RFC][patch 00/21] PID Virtualization: Overview and

To: Gerrit Huizenga <gh@xxxxxxxxxx>
Subject: Re: [ckrm-tech] Re: [RFC][patch 00/21] PID Virtualization: Overview and Patches
From: Dave Hansen <haveblue@xxxxxxxxxx>
Date: Fri, 16 Dec 2005 13:10:54 -0800
Cc: Matt Helsley <matthltc@xxxxxxxxxx>, Hubertus Franke <frankeh@xxxxxxxxxxxxxx>, CKRM-Tech <ckrm-tech@xxxxxxxxxxxxxxxxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, LSE <lse-tech@xxxxxxxxxxxxxxxxxxxxx>, vserver@xxxxxxxxxxxxxxxxxxxxxx, Andrew Morton <akpm@xxxxxxxx>, Rik van Riel <riel@xxxxxxxxxx>, pagg@xxxxxxxxxxx
In-reply-to: <E1EnMSU-0004pH-00@xxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <E1EnMSU-0004pH-00@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: pagg-bounce@xxxxxxxxxxx
On Fri, 2005-12-16 at 12:45 -0800, Gerrit Huizenga wrote:
> Interesting...  So how to tasks get *into* a container?

Only by inheritance.  

> And can they ever get back "out" of a container?

No.  Think of the pids again.  Even the "outside" of a container, things
like the real init, have to have unique pids.  What if the process's pid
is the same as one in use in the default container?

> Are most processes on the system
> initially not in a container?  And then they can be stuffed in a container?
> And then containers can be moved around or be isolated from each other?

The current idea is that processes are assigned at fork-time.  The
isolation is for the lifetime of the process.

> And, is pid virtualization the point where this happens?  Or is that
> a slightly higher level?  In other words, is pid virtualization the
> full implementation of container isolation?  Or is it a significant
> element on which additional policy, restrictions, and usage models
> can be built?

pid virtualization is simply the one that's easiest to understand, and
the one that demonstrates the largest number of issues.  It is a small
piece of the puzzle, but an important one.

-- Dave


<Prev in Thread] Current Thread [Next in Thread>