All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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 ` [RFC] [PATCH 0/7] Some basic vserver infrastructure 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 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.