Re: (pspace,pid) vs true pid virtualization

[Eric W. Biederman]

Herbert Poetzl <herbert@xxxxxxxxxxxx> writes:

> that's something I'm not so worried about, but a statically
> compiled userspace process with 20K sounds unusual in the
> time of 2M *libcs :)

For unshared data, a stack  and page tables is should be achievable
even with glibc but I haven't sat down and done the math.  But
last I looked if you took out the debug symbols glibc was only 1M.

If glibc can't do it one of the lightweight embedded c libraries
certainly should be able to.

>> That is significant but we are still cheap enough that it
>> isn't necessarily a show stopper.
>> 
>> I think the cost was only one extra process, for the case where you
>> have fakeinit now it would be init, for other cases it would be a
>> daemon that gets setup when you initialize the vserver.
>
> well, depends, currently we do not need a parent to handle
> the guest, so there is _no_ waiting process in the light-
> weight case either, which makes that two processes for each
> guest, no?

As I put it together you don't need a parent.  The parent can wait for it
or exit the child doesn't care.  Usual unix semantics here :)

If you are using a pipe to communicate to the outside world that
has to be put someplace, but you can always create a fifo in
the filesystem.  You could have a single parent for all of
the lightweight guests.

Lots of choices on how to put the pieces together.

> anyway, I'm not strictly against having an init process
> inside a guest, as long as it is not an essential part
> of the overall design, because that would make it much
> harder to rip it out later :)

Except for being a child reaper no.  Having a process that
is the child reaper is interesting mainly because it allows
you to get an accurate struct rusage picture of all of the
children in pspace.

Eric

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