Re: [RFC][PATCH 01/20] pid: Intoduce the concept of a wid (wait id)

[Jeff Dike <jdike@addtoit.com>]

First of all, for an RFC, this is very thorough.

Second, I've been thinking along these lines for UML.  The motivation
is to get UML out of the system call tracing business as much as
possible, and to do so by having the host set up such that it can run
system calls itself and they do the same thing as the UML system call
would.

For example, for a UML process chrooted into a UML filesystem, the
file operations on normal files will do the same thing as they would
in UML, so they could be left to run on the host.

Similarly, something like virtualized processes could be made to do
the same thing with the process operations.  Trivially, getpid() will
return the right value if left to run on the host, so UML wouldn't
need to intercept it.  If there is a process tree inside a container
that mirrors the UML process tree, then lots of other system calls
also work, and don't need to be intercepted.

Ideally, I'd like namespaces on the host for all the resources under
UML control, and for a container to group those namespaces.  However,
something which stops short of that is still usable - UML just gets
less benefit from it.

As far as processes go, ideally I'd like a containerized process to be
an empty shell which can be completely filled from userspace.  The
motivation for this is that when you have a UP UML with 100 processes,
it's wasteful to have 100 virtualized processes on the host.  What I
would want is one virtualized process which can be completely refilled
with new attributes on a context switch.

What I want to do is related to process migration, where you want to
move a process but have it not be able to tell.  I'm describing
migrating a process from the UML to the host such that the host
performs as many system calls itself, but those which can't get
intercepted and executed within the UML.  For migration between
physical machines, this would be the same as redirecting a system call
from the new host back to its original home.  You want to do that as
infrequently as possible, so you want the container to provide as much
context from the home host as possible.

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