[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