Re: (pspace,pid) vs true pid virtualization

On Fri, Feb 17, 2006 at 03:57:26AM -0700, Eric W. Biederman wrote:
Dave Hansen <haveblue@xxxxxxxxxx> writes:

On Thu, 2006-02-16 at 12:44 -0600, Serge E. Hallyn wrote:
Now Dave and I were just talking about actually using the
init process in a pspace to do administration from outside.
For instance, the userspace code, in /sbin/pspaceinit, which
runs as (pspace 2, pid 1), could open a pipe with it's parent
(pspace1, pid 234). pid 234 can then ask the init process to
do things like list processes, kill a process, and maybe even
recursively talk to the init process in pspace 3.

This would require a much smarter init, and that a child be nice,
cooperate and pass on what is requested of it if it's nested children
are to be killed. If a child decided to be mean and ignore its parent's
requests, the parent can always just kill the child.

As for that. When I mad that suggestion to Herbert Poetzl
his only concern was that a smart init might be too heavy weight
for lightweight vserver. Generally I like the idea.

well, may I remind that this solution would require _two_
init processes for each guest, which could easily make up
300-400 unnecessary processes in a lightweight server
setup?

(Read the last sentence, and in case you're wondering, no I don't have
any children in real life)

Speaking of that. One of my coworkers mentioned that it is unfortunate
that our names don't have the double meaning. So it was suggested we
call them

Speaking of that problematic naming. One of my coworkers mentioned that
it is unfortunate that our set of names does not have a double meaning.
After that the suggestion came up to call them families, instead of guest
or pidspaces. Although I guess calling them guests is about as bad :)

well, at least Guests or VEs are terms already used by
existing projects, where pspace sounds somewhat strange.

at the same time I'd like to point out that *spaces is
a good name for the building blocks, but we definitely
have to name the 'construct' different, i.e. a 'guest'
(or VPS or VE or whatever) is _more_ than just a p-space
it's the sum of all *-spaces required to make it look
like a real linux system.

best,
Herbert

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/

Relevant Pages

  • Re: (pspace,pid) vs true pid virtualization
    ... init process in a pspace to do administration from outside. ... (pspace1, pid 234). ... After that the suggestion came up to call them families, ...
    (Linux-Kernel)
  • Re: (pspace,pid) vs true pid virtualization
    ... init process in a pspace to do administration from outside. ... (pspace1, pid 234). ... This would require a much smarter init, and that a child be nice, ...
    (Linux-Kernel)
  • Re: (pspace,pid) vs true pid virtualization
    ... "Migrate" was just a checkpoint (from pspace 1) ... If you are just talking the pid of the init process the problem seems ... only allow pid 1 of any pspace to be visible in the parent. ...
    (Linux-Kernel)
  • Re: (pspace,pid) vs true pid virtualization
    ... Now consider pspace 4 which is a child of pid 567 ... The pid of the init process for pspace 4. ... only allow pid 1 of any pspace to be visible in the parent. ...
    (Linux-Kernel)
  • Re: root or openssh exploited?
    ... > PID 20: not in readdir output ... > You have 1 process hidden for readdir command ... > PID 1 is of course init. ... > seconds after the real init process. ...
    (comp.os.linux.security)