:)fine, agreed on this finally, same for OpenVZ.hey we have soemthing :)
this is more logically clean to me, since containers/namespaces are not tasks.definitely, we (Linux-VServer) added this some time agobut why sys_waitpid? we can make it in many other ways,
and it helps to maintain/restart a guest.
yes, we currently have a syscall switch command to wait for the guest, but, of course, it is
very similar to the 'normal' unix waitpid()
see my another email about sockets.And we had issues in OpenVZ, that very fast VPS stop/start can fail due to not freed resources yet.this is a design problem, if your design allows
to have _more_ than one pid space with the same
identifier/properties, but with only one active
and thus reachable space, it is no problem to create a new one right after the old one did send
the event (which doesn't mean that it was destroyed
just that the last process left the space)
Even if we don't take into account proprietary apps, there too many opensource control panels, management tools etc.How about third party apps?I don't think we care about third party apps when
adding new kernel functionality, especially not
proprietary ones which cannot be modified easily
agreed. Though I don't like a backdoor name :) It is just a way to get access to VPS.
well, it is often a way to get access to the VPSWhen you have a physical box there are many ways to get access to it without knowing passwords etc. This is the same.
without the 'owner' of that VPS even knowing, so
IMHO it's a backdoor, access would be via sshd or
console :)