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.