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

[Hubertus Franke]

On Fri, 2005-12-16 at 13:10 -0800, Dave Hansen wrote:
> On Fri, 2005-12-16 at 12:45 -0800, Gerrit Huizenga wrote:
> > Interesting...  So how to tasks get *into* a container?
> 
> Only by inheritance.  

That is only true today. There is no reason (other then introducing
some heavy code complexity (haven't thought about that) 
why we can't at some point move a process group/tree into a container.
The reason for this is that for the global container V=R in pid space
terms (read the vpid=realpid). Moving an entire group into a container
requires to assign new kernel pids to each task, while keeping the 
the vpid part constant. Lots of kpid related references though..
Don't know whether that's worth the trouble, particularly at this stage.

> 
> > 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?

Correct..look at my answer above  moving from global to container can be
accomplished because in a fresh container all pids are available, so we
can simply reoccupy the same vpids in the new pidspace. This keeps all
user level "references" and pid values valid.
The only way we could EVER go back is if we could guarantee that the
pids the global space are free, hence they would have to be reserved.
NOWAY.... particularly if migration is involved later on..

> 
> > 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.
> 

Ditto..

> -- Dave
> 
> 
-- 
Hubertus Franke <frankeh@xxxxxxxxxxxxxx>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/