From: Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de)
Date: Tue 18 Nov 2003 - 14:29:07 GMT
nomad_at_null.net (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
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
Vserver mailing list