well, IMHO this approach lacks a few things which wouldPID virtualization has nothing to do with containers and its structure. This VPID patch can be used both in environments with hierarchical and flat structure.
be very useful in a mainline pid virtualization, which
pretty much explains why it is relatively small
- hierarchical structure (it's flat, only one level)
- a proper administration schemeCan't catch what you mean. What kind of administration do you want for VPIDs? Do you have one for usual PIDs? It is assigned by kernel and that's it.
- a 'view' into the child pid spacesit has. see proc patch.
- handling of inter context signallingHow is it related to inter context signalling???
and, more important, it does not deal with the existing1. if kernel has some errors, these errors should be fixed. Virtualization doesn't deal with it, doesn't solve such issues, doesn't make it worse. So what do you mean?
issues and error cases, where references to pids, tasks,
task groups and sessions aren't handled properly ...
I think that in real world virtualization scenariosOpenVZ successfully works with >1000 VPSs on a single server.
with hundreds of namespaces those 'imprecisions' will occasionally lead to very strange and random behaviour
which in many cases will go completely unnoticed.
so I really prefer to cleanup the existing pid handlingI'm not against pid handling cleanups, am I?
first, to avoid big surprises later ...