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.