All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nigel Cunningham <ncunningham@cyclades.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>, Kirill Korotaev <dev@sw.ru>,
	Linus Torvalds <torvalds@osdl.org>,
	Kirill Korotaev <dev@openvz.org>, Andrew Morton <akpm@osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	frankeh@watson.ibm.com, clg@fr.ibm.com, greg@kroah.com,
	alan@lxorguk.ukuu.org.uk, serue@us.ibm.com, arjan@infradead.org,
	Rik van Riel <riel@redhat.com>,
	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	Andrey Savochkin <saw@sawoct.com>,
	devel@openvz.org, Pavel Emelianov <xemul@sw.ru>
Subject: Re: [RFC][PATCH 1/5] Virtualization/containers: startup
Date: Fri, 10 Feb 2006 15:40:56 +1000	[thread overview]
Message-ID: <200602101541.07631.ncunningham@cyclades.com> (raw)
In-Reply-To: <m13biwnxkc.fsf@ebiederm.dsl.xmission.com>

[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]

Hi.

On Tuesday 07 February 2006 04:37, Eric W. Biederman wrote:
> Dave Hansen <haveblue@us.ibm.com> writes:
> > On Mon, 2006-02-06 at 02:19 -0700, Eric W. Biederman wrote:
> >> That you placed the namespaces in a separate structure from
> >> task_struct.
> >> That part seems completely unnecessary, that and the addition of a
> >> global id in a completely new namespace that will be a pain to
> >> virtualize
> >> when it's time comes.
> >
> > Could you explain a bit why the container ID would need to be
> > virtualized?
>
> As someone said to me a little bit ago, for migration or checkpointing
> ultimately you have to capture the entire user/kernel interface if
> things are going to work properly.  Now if we add this facility to
> the kernel and it is a general purpose facility.  It is only a matter
> of time before we need to deal with nested containers.
>
> Not considering the case of having nested containers now is just foolish.
> Maybe we don't have to implement it yet but not considering it is silly.
>
> As far as I can tell there is a very reasonable chance that when we
> are complete there is a very reasonable chance that software suspend
> will just be a special case of migration, done complete in user space.
> That is one of the more practical examples I can think of where this
> kind of functionality would be used.

Am I missing something? I though migration referred only to userspace 
processes. Software suspend on the other hand, deals with the whole system, 
of which process data/context is only a part.

Regards,

Nigel

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2006-02-10  5:44 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-03 16:58 [RFC][PATCH 1/5] Virtualization/containers: startup Kirill Korotaev
2006-02-03 17:03 ` [RFC][PATCH 2/5] Virtualization/containers: UIDs Kirill Korotaev
2006-02-03 17:06 ` [RFC][PATCH 3/5] Virtualization/containers: UTSNAME Kirill Korotaev
2006-02-06  8:21   ` Eric W. Biederman
2006-02-06  8:53     ` Kirill Korotaev
2006-02-03 17:15 ` [RFC][PATCH 1/5] Virtualization/containers: startup Linus Torvalds
2006-02-03 17:22   ` Kirill Korotaev
2006-02-03 17:49     ` Linus Torvalds
2006-02-03 18:34       ` Dave Hansen
2006-02-03 18:55         ` Jeff Garzik
2006-02-03 19:18         ` Hubertus Franke
2006-02-03 19:56         ` Hubertus Franke
2006-02-03 20:19         ` Greg KH
2006-02-03 20:34           ` Hubertus Franke
2006-02-05 15:11             ` Kirill Korotaev
2006-02-05 15:39               ` Hubertus Franke
2006-02-06  9:08                 ` Kirill Korotaev
2006-02-06 22:31               ` Cedric Le Goater
2006-02-07 12:28                 ` Kirill Korotaev
2006-02-05 15:10           ` Kirill Korotaev
2006-02-05 15:05         ` Kirill Korotaev
2006-02-06 16:35           ` Dave Hansen
2006-02-06 16:51             ` Kirill Korotaev
2006-02-06 16:56           ` Linus Torvalds
2006-02-06 17:21             ` Kirill Korotaev
2006-02-07  0:28             ` Sam Vilain
2006-02-07 12:21               ` Kirill Korotaev
2006-02-07 22:21                 ` Sam Vilain
2006-02-20 11:56                   ` Kirill Korotaev
2006-02-03 18:36       ` Summary: PID virtualization , Containers, Migration Hubertus Franke
2006-02-03 18:36       ` [RFC][PATCH 1/5] Virtualization/containers: startup Rik van Riel
2006-02-05 14:52       ` Kirill Korotaev
2006-02-06  8:39       ` Eric W. Biederman
2006-02-06  9:00         ` Kirill Korotaev
2006-02-06  9:19           ` Eric W. Biederman
2006-02-06 16:37             ` Dave Hansen
2006-02-06 18:37               ` Eric W. Biederman
2006-02-06 19:32                 ` Kirill Korotaev
2006-02-06 22:40                 ` Cedric Le Goater
2006-02-07  1:57                   ` Eric W. Biederman
2006-02-08 21:54                 ` swsusp done by migration (was Re: [RFC][PATCH 1/5] Virtualization/containers: startup) Pavel Machek
2006-02-09 18:20                   ` Eric W. Biederman
2006-02-10  0:21                     ` Kyle Moffett
2006-02-10  4:31                       ` Sam Vilain
2006-02-10  6:23                         ` [Devel] " Vasily Averin
2006-02-11  2:38                           ` Sam Vilain
2006-02-11 17:29                             ` Vasily Averin
2006-02-12 23:29                               ` Sam Vilain
2006-02-10  8:29                         ` Kyle Moffett
2006-02-10  5:40                 ` Nigel Cunningham [this message]
2006-02-10  6:01                   ` [RFC][PATCH 1/5] Virtualization/containers: startup Eric W. Biederman
2006-02-06 10:16   ` Jes Sorensen
2006-02-05 20:13 ` Andi Kleen
2006-02-06  9:04   ` Kirill Korotaev
2006-02-06  0:56 ` Benjamin Herrenschmidt
2006-02-06  9:03   ` [Devel] " Kirill Korotaev
2006-02-06  8:31 ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200602101541.07631.ncunningham@cyclades.com \
    --to=ncunningham@cyclades.com \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=clg@fr.ibm.com \
    --cc=dev@openvz.org \
    --cc=dev@sw.ru \
    --cc=devel@openvz.org \
    --cc=ebiederm@xmission.com \
    --cc=frankeh@watson.ibm.com \
    --cc=greg@kroah.com \
    --cc=haveblue@us.ibm.com \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@redhat.com \
    --cc=saw@sawoct.com \
    --cc=serue@us.ibm.com \
    --cc=torvalds@osdl.org \
    --cc=xemul@sw.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.