About this list Date view Thread view Subject view Author view Attachment view

From: Mark Lawrence (nomad_at_null.net)
Date: Wed 11 Feb 2004 - 16:24:36 GMT


On Tue, 10 Feb 2004, Mark Lawrence wrote:

> I have written an alpha-quality (untested) version of the vshelper script
> (and accompanying manpage) which I would like to invite discussion on. It
> does not actually do anything at the moment because it requires the
> vserver(8) script to be patched with a new "kill" command.

So, I hacked on the script a bit more, and found a system to test it on.
The results surprised me a bit, and I'd like to make the following
comments with regards to the interface between the kernel and userland.

The kernel patch to reboot(2) invokes the vshelper script with the
following syntax:

  vshelper restart|halt|poweroff|restart2 <ctx> [arg]

My first comment about this is that it is only suitable for use for reboot
related activities, and can't be nicely extended. Although I don't have
any examples, I thought that vshelper would be intended as a a more
generic tool.

So I put the script location into /proc/sys/kernel/vshelper and called
halt(1) from a context. The following showed up in the syslog:

Feb 10 19:24:07 hsee-tor-s001 logger: reboot(restart2) ctx 3 (unknown), uid 0, pid 508, arg
Feb 10 19:24:07 hsee-tor-s001 logger: reboot(halt) ctx 3 (unknown), uid 0, pid 508, arg
Feb 10 19:24:07 hsee-tor-s001 logger: reboot(restart2) ctx 3 (unknown), uid 0, pid 508, arg

No I did not call halt or restart three times. It turns out that the
sysvinit utilities (halt, reboot etc) make several calls to reboot(2).

The first changes the Ctl-Alt-Del setting (flag LINUX_REBOOT_CMD_CAD_ON).
Then it calls reboot(2) to actually halt (flag LINUX_REBOOT_CMD_HALT). The
third call (flag ...RESTART2) is actually a fall-through because normally
the CMD_HALT would not return.

What I find misleading, is that the current vserver-reboot(2) patch makes
a distiction between restart, poweroff, halt and restart2, but not the
other two possibilites CAD_ON and CAD_OFF. In fact it kind of puts the
last two flags into the RESTART2 category.

I would prefer that vshelper be the true user-space policy implementation
of reboot(2), and be given a clearer message of what the context
requested.

Therefore I would like to propose the following interface between
kernel/vshelper.

  vshelper <action> <ctx> [<arg...>]

Where <action> depends on the system call or unique area of request from
the context. <ctx> is of course the context, and <arg...> are zero or more
arguments which are specific to the <action>.

Hence for reboot we would have in the generic sense:

  vshelper reboot <ctx> <flag> [arg]

which in the specific sense would be:

  vshelper reboot <ctx> reboot|halt|poweroff|cad_on|cad_off|{restart2 arg}

(actually I would just let the kernel pass the actual hex value of flag).

As you can see this is much closer to the original system call, and lets
us better define policy in userland. Maybe one day we want to perform an
action when CAD_ON or CAD_OFF are called? However calling vshelper with
"restart2" to do that is not very obvious.

I have also put together a script which implements this syntax (but no
man-page yet) at http://rekudos.net/download/vshelper-new.

Once again feedback is welcome...

Cheers, Mark.

-- 
Mark Lawrence

_______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver


About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Wed 11 Feb 2004 - 16:32:38 GMT by hypermail 2.1.3