Andrew Morton <akpm at osdl.org> writes: > 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? It certainly appears uncoordinated. Unless something big is missed they should be complementary pieces that do not depend on each other. > 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. Ok. It sounds like we need to do have a close code review of what is in -mm and give recommendations on it. > 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. Sounds good. > 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. A reasonable concern. > 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. There is certainly a communication failure here and I'm not certain how to fill it. Unless someone beats me to it. I will see if I can arrange a group ack/nack session of what we have in -mm from 2.6.19 from all of the interested parties. Eric
