[EMAIL PROTECTED] (Mark Lawrence) writes: >> > that would do a context id check (ie where's it coming from and what's >> > it trying to apply those changes to) and then if everything checks out, >> > does the vserver <context-id-resolves-to-this-name> start/stop/restart. >> >> How will you do this resolving for vserver-in-a-vserver? > > When we get to the stage where nested vservers are possible, I'm sure it > will be a relatively simple kernel task to send the event to the correct > context.
As far as I understand the userhelper-idea implemented in 1.1.3, there is just a program which gets called by the kernel (similarly to 'modprobe'). There is no way to do anything with a context; starting the program in calling or parent's context would be bad since the root-directory is not associated with the context. So the needed (re)start-commands are impossible to determine in a secure manner. An IMO better and more simple approach would be a poll()/select()-like interface, and/or /proc/virtual/<ctx>/event (similarly to /proc/acpi/event). Possible events are HALT, REBOOT or KILL which could be handled by a daemon in the parent's userspace Enrico _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
