[PATCH 2/2] Define struct pspace

Cedric Le Goater clg at fr.ibm.com
Mon Aug 21 12:50:47 PDT 2006


Andrew Morton wrote:
> On Wed, 16 Aug 2006 17:01:45 -0700
> Sukadev Bhattiprolu <sukadev at us.ibm.com> wrote:
> 
>> Define a per-container pid space object.  And create one instance of this
>> object, init_pspace, to define the entire pid space.  Subsequent patches
>> will provide/use interfaces to create/destroy pid spaces.
> 
> This comes on the same day as the user-bean-counters work.  Are these
> efforts complementary, contradictory or unrelated?  Are they coordinated?
> 
> 
> Generally, I am not very comfortable merging any
> namespace/containerization/resource management patches into mainline until
> we have some sort of high-level agreed-to roadmap which will take us to an
> agreed-to-at-a-high-level destination.  Because there is a risk that we'll
> end up with a fair amount of unused infrastructure which turns out not to
> be suitable for our eventual implementation.
> 
> Now, I _am_ OK with merging useless infrastructure as long as all the prime
> stakeholders are OK with it.  So, for example, as long as Eric, Serge and
> Kirril (and others I missed) are OK with namespaces-utsname-*.patch then
> let's put it into 2.6.19.  Simply so that people have a common codebase to
> work against and so that -mm doesn't have 1000 containerisation patches by
> mid-2007.
> 
> That would not be a useful patchset on its own because nothing _uses_ it. 
> And there is a risk that it will remain a useless patchset for evermore. 
> But I think it's an acceptably low risk.  We don't normally merge useless
> patches, but this is a special case.
> 
> 
> So, (policy making on the fly), let's start merging the well-tested,
> well-isolated, low-overhead generally-agreed-to features into mainline.
> 
> But that will only take us so far.  At some stage the process will stall
> because we simply do not know what the plan is, so we cannot judge whether
> a particular feature is getting us there.
> 
> That's in the future, and we can muddle along for a while.  But at some
> stage you guys are going to need to be able to show us the roadmap, please.

A thread was started on the topic 2 or 3 weeks ago :

	http://list.linux-vserver.org/archive/vserver/msg14023.html
	http://openvz.org/pipermail/devel/2006-July/000904.html

It didn't have much echo. I guess we all had to catch up on other things
after OLS.

IMHO, the first very important steps are :

	1 - make sure what is in -mm fits openvz, vserver and other
	    products.
	2 - make sure the initial framework also fits the requirements of a
            basic resource management system.

Cheers,

C.



More information about the Containers mailing list