From: ebiederm@xmission.com (Eric W. Biederman)
To: Kirill Korotaev <dev@sw.ru>
Cc: Linus Torvalds <torvalds@osdl.org>,
Rik van Riel <riel@redhat.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
devel@openvz.org, Andrey Savochkin <saw@sawoct.com>,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
Stanislav Protassov <st@sw.ru>,
serue@us.ibm.com, frankeh@watson.ibm.com, clg@fr.ibm.com,
haveblue@us.ibm.com, mrmacman_g4@mac.com,
alan@lxorguk.ukuu.org.uk, Herbert Poetzl <herbert@13thfloor.at>,
Andrew Morton <akpm@osdl.org>
Subject: Re: Which of the virtualization approaches is more suitable for kernel?
Date: Fri, 24 Feb 2006 14:44:42 -0700 [thread overview]
Message-ID: <m1oe0wbfed.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <43F9E411.1060305@sw.ru> (Kirill Korotaev's message of "Mon, 20 Feb 2006 18:45:21 +0300")
Kirill Korotaev <dev@sw.ru> writes:
> Linus, Andrew,
>
> We need your help on what virtualization approach you would accept to
> mainstream (if any) and where we should go.
>
> If to drop VPID virtualization which caused many disputes, we actually
> have the one virtualization solution, but 2 approaches for it. Which one
> will go depends on the goals and your approval any way.
My apologies for not replying sooner.
>From the looks of previous replies I think we have some valid commonalities
that we can focus on.
Largely we all agree that to applications things should look exactly as
they do now. Currently we do not agree on management interfaces.
We seem to have much more agreement on everything except pids, so discussing
some of the other pieces looks worth while.
So I propose we the patches to solve the problem into three categories.
- General cleanups that simplify or fix problems now, but have
a major advantage for our work.
- The kernel internal implementation of the various namespaces
without an interface to create new ones.
- The new interfaces for how we create and control containers/namesp aces.
This should allow the various approach to start sharing code, getting
progressively closer to each other until we have an implementation
we can agree is ready to go into Linus's kernel. Plus that will
allow us to have our technical flame wars without totally stopping
progress.
We can start on a broad front, looking at several different things.
But I suggest the first thing we all look at is SYSVIPC. It is
currently a clearly recognized namespace in the kernel so the scope is
well defined. SYSVIPC is just complicated enough to have a
non-trivial implementation while at the same time being simple enough
that we can go through the code in exhausting detail. Getting the
group dynamics working properly.
Then we can as a group look at networking, pids, and the other pieces.
But I do think it is important that we take the problem in pieces
because otherwise it is simply to large to review properly.
Eric
next prev parent reply other threads:[~2006-02-24 21:48 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-20 15:45 Kirill Korotaev
2006-02-20 16:12 ` Herbert Poetzl
2006-02-21 16:00 ` Kirill Korotaev
2006-02-21 20:33 ` Sam Vilain
2006-02-21 23:50 ` Herbert Poetzl
2006-02-22 10:09 ` [Devel] " Kir Kolyshkin
2006-02-22 15:26 ` Eric W. Biederman
2006-02-23 12:02 ` Kir Kolyshkin
2006-02-23 13:25 ` Eric W. Biederman
2006-02-23 14:00 ` Kir Kolyshkin
2006-02-24 21:44 ` Eric W. Biederman [this message]
2006-02-24 23:01 ` Herbert Poetzl
2006-02-27 17:42 ` Dave Hansen
2006-02-27 21:14 ` Eric W. Biederman
2006-02-27 21:35 ` Dave Hansen
2006-02-27 21:56 ` Eric W. Biederman
2006-03-04 3:17 ` sysctls inside containers Dave Hansen
2006-03-04 10:27 ` Eric W. Biederman
2006-03-06 16:27 ` Dave Hansen
2006-03-06 17:08 ` Herbert Poetzl
2006-03-06 17:18 ` Dave Hansen
2006-03-06 18:56 ` Eric W. Biederman
2006-03-10 10:17 ` Kirill Korotaev
2006-03-10 13:22 ` Eric W. Biederman
2006-03-10 10:19 ` Kirill Korotaev
2006-03-10 11:55 ` Eric W. Biederman
2006-03-10 18:58 ` Dave Hansen
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=m1oe0wbfed.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=clg@fr.ibm.com \
--cc=dev@sw.ru \
--cc=devel@openvz.org \
--cc=frankeh@watson.ibm.com \
--cc=haveblue@us.ibm.com \
--cc=herbert@13thfloor.at \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=mrmacman_g4@mac.com \
--cc=riel@redhat.com \
--cc=saw@sawoct.com \
--cc=serue@us.ibm.com \
--cc=st@sw.ru \
--cc=torvalds@osdl.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome