From: Sam Vilain <sam@vilain.net>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <haveblue@us.ibm.com>,
linux-kernel@vger.kernel.org,
Herbert Poetzl <herbert@13thfloor.at>,
OpenVZ developers list <dev@openvz.org>,
"Serge E.Hallyn" <serue@us.ibm.com>,
Andrew Morton <akpm@osdl.org>
Subject: Re: [RFC] [PATCH 0/7] Some basic vserver infrastructure
Date: Thu, 23 Mar 2006 16:29:20 +1200 [thread overview]
Message-ID: <44222420.4040403@vilain.net> (raw)
In-Reply-To: <m1k6anq8uq.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
>I certainly have not. I do feel that developing this just from the
>top down is the wrong way to do this.
>
>
OK, you said "just" the top down. That's fine, I can agree with that.
Obviously if any of the implementation of the top down features hits
ugliness that needs refactoring, that refactoring has to go first.
>In some of the preliminary
>patches we have found several pieces of code that we will have to
>touch that is currently in need of a cleanup. That is why I have
>been cleaning up /proc. sysctl is in need of similar treatment
>but is in less bad shape.
>
>
I made a preliminary attempt to rebase the /proc hooks atop of your
work. I looked forward to being ready for if a patchset like this got
adopted to -mm to be able to hand that piece over :-).
The reason I didn't persue that to completion was I wasn't sure how I
would then submit it - relative to the -mm tree? I didn't want to
include your patches in my series.
It would be nice if someone could make a git branch on kernel.org for
each -mm release so it can be more easily imported to a git tree. Sure,
`stg import' might take a while for all 1,400 patches, but that's OK -
so long as Andrew's not waiting for it :-).
>I don't think that is the case on the fundamentals. I think with pids
>I am an inch away from implementing a pid namespace that is both
>recursive, efficient, and can map all of the pids into another pid
>space if that is desirable. Plus I can merge most of it incrementally
>in the existing kernel, before I even allow for multiple pid spaces.
>
>Which should reduce the patch for multiple pid namespaces to something
>reasonable to talk about.
>
>
Well I see pids as just another virtualisable entity, but OK... if you
come up with anything I'm happy to rebase atop it.
>>What about going back to the very simple "struct container" on which to
>>build?
>>
>>
>
>I guess my problem there is that isn't something on which to build
>that is something to hang things off of.
>
>
Yes, hanging things off is the intention, but they are both starting
points, just from different perspectives.
Sam.
next prev parent reply other threads:[~2006-03-23 4:29 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060321061333.27638.63963.stgit@localhost.localdomain>
2006-03-21 18:50 ` Dave Hansen
2006-03-21 21:08 ` Sam Vilain
2006-03-21 21:32 ` Dave Hansen
2006-03-21 23:12 ` Sam Vilain
2006-03-22 5:18 ` Sam Vilain
2006-03-22 7:13 ` Eric W. Biederman
2006-03-23 4:17 ` Sam Vilain
2006-03-24 15:36 ` [Devel] " Kirill Korotaev
2006-03-27 12:45 ` Serge E. Hallyn
2006-03-28 5:28 ` Sam Vilain
2006-03-29 12:07 ` Kirill Korotaev
2006-03-29 13:47 ` Serge E. Hallyn
2006-03-29 21:30 ` Sam Vilain
2006-04-19 7:50 ` Eric W. Biederman
2006-04-19 21:42 ` Sam Vilain
2006-03-22 6:41 ` Eric W. Biederman
2006-03-23 4:29 ` Sam Vilain [this message]
2006-03-23 4:50 ` Andrew Morton
2006-03-24 15:38 ` Kirill Korotaev
2006-03-24 15:37 ` Kirill Korotaev
2006-03-24 20:28 ` Eric W. Biederman
2006-03-24 21:01 ` Herbert Poetzl
2006-03-24 21:13 ` Eric W. Biederman
2006-03-24 21:40 ` Herbert Poetzl
2006-03-24 22:30 ` Eric W. Biederman
2006-03-25 18:37 ` Eric W. Biederman
[not found] ` <20060321061333.27638.9112.stgit@localhost.localdomain>
2006-03-21 18:53 ` [RFC] [PATCH 1/7] Add process virtualisation umbrella structure (vx_info) Dave Hansen
2006-03-21 21:52 ` Sam Vilain
2006-03-22 2:02 ` Herbert Poetzl
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=44222420.4040403@vilain.net \
--to=sam@vilain.net \
--cc=akpm@osdl.org \
--cc=dev@openvz.org \
--cc=ebiederm@xmission.com \
--cc=haveblue@us.ibm.com \
--cc=herbert@13thfloor.at \
--cc=linux-kernel@vger.kernel.org \
--cc=serue@us.ibm.com \
/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