All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kirill Korotaev <dev@sw.ru>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: 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, haveblue@us.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: Mon, 06 Feb 2006 12:00:08 +0300	[thread overview]
Message-ID: <43E71018.8010104@sw.ru> (raw)
In-Reply-To: <m1lkwoubiw.fsf@ebiederm.dsl.xmission.com>

>>I think that a patch like this - particularly just the 1/5 part - makes 
>>total sense, because regardless of any other details of virtualization, 
>>every single scheme is going to need this.
> I strongly disagree with this approach.  I think Al Viro got it
> right when he created a separate namespace for filesystems.  
These patch set introduces separate namespaces as those in filesystems.
What exactly you don't like in this approach? Can you be more specific?

> First this presumes an all or nothing interface.  But that is not
> what people are doing.  Different people want different subsets
> of the functionality.   For the migration work I am doing having
> multiple meanings for the same uid isn't interesting.
What do you mean by that? That you don't care about virtualization of 
UIDs? So your migration doesn't care at all whether 2 systems have same 
uids? Do you keep /etc/passwd in sync when do migration?
Only full virtualization allows to migrate applications without bugs and 
different effects.

> Secondly by implementing this in one big chunk there is no
> migration path when you want to isolate an additional part of the
> kernel interface.
> 
> So I really think an approach that allows for incremental progress
> that allows for different subsets of this functionality to
> be used is a better approach.  In clone we already have
> a perfectly serviceable interface for that and I have
> seen no one refute that.  I'm not sure I have seen anyone
> get it though.
Just introduce config option for each virtualization functionality. 
That's it.

> My apologies for the late reply I didn't see this thread until
> just a couple of minutes ago.  linux-kernel can be hard to
> follow when you aren't cc'd.
> 
> 
> Patches hopefully sometime in the next 24hours.   So hopefully
> conversation can be carried forward in a productive manner.
Ok. I will remake them either :)

Kirill



  reply	other threads:[~2006-02-06  8:59 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 [this message]
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                 ` [RFC][PATCH 1/5] Virtualization/containers: startup Nigel Cunningham
2006-02-10  6:01                   ` 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=43E71018.8010104@sw.ru \
    --to=dev@sw.ru \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=clg@fr.ibm.com \
    --cc=dev@openvz.org \
    --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.