From: Mark Lawrence (nomad_at_null.net)
Date: Thu 26 Feb 2004 - 12:39:03 GMT
On Thu, 26 Feb 2004, Herbert Poetzl wrote:
> - char *argv[] = {vshelper_path, id_buf, NULL, NULL, 0};
> + char *argv[] = {vshelper_path, "reboot", id_buf, cmd_buf, 0, 0};
>
> adds a redundant "reboot" argument which doesn't make
> any sense, because everybody knows that restart/halt/etc ...
> is sent from sys_reboot() ... and if it would not be sent
> from sys_reboot() it would also require the redundant
> "reboot" arg to work in userspace, so what's the rationale
> behind that?
>From a discussion at the very beginning, when Paul first wrote schelper we
talked about the context helper tool being called from places in the
kernel other than sys_reboot. If any other use also needs a "restart"
argument you have a clash.
I don't think specific examples were identified, but I could imagine
something like a userspace copy-on-write implementation triggered by
open(2) on a unified context file. Perhaps nothing else would use the
vshelper script, but then why is it not called vsreboot?
> this simply ignores the CAD_ON/OFF messages, which might
> make sense, but which definitely falls exactly in the
> 'unecessarily hide the details of the call' section, you
> claim to avoid ...
I agree - it was a last minute change because I didn't like seeing
multiple messages in my logs.
> using the hex identifier instead of the 'verbose' command
> only makes it more complicated to generate similar messages
> from a different place in the kernel, and it might give
> a difference on different archs where the reboot commands
> are defined differently ... (16/32/64 bit)
ok.
> no problem there, just what is a vshelper good for, when
> the interface was defined in a long and extensive evaluation
> process, and the helper doesn't conform to that interface?
I have missed the evaluation process and can't find the history for it -
did it take place on irc? My apologies again then for re-opening something
which should not have been.
> well, actually I do not care very much, as this vshelper
> interface will go away soon, and it seems that nobody is using
> it at all ...
I must have been sleeping, because this is also news to me. The last post
I can find on this topic is yours from November last year
http://archives.linux-vserver.org/200311/0115.html. There is no mention
that this is an interface that is going away.
I wish I had known, because I would not have put the effort I have into
vshelper... but instead into the new requirement (if any). I believe the
only reason nobody is using the interface is because they didn't have the
tool.
> feel free to branch and/or provide vshelper kernel patches ...
Not my style. However I'll revert to the current kernel interface and put
up a page on the Wiki for those interested.
Cheers, Mark.
-- Mark Lawrence_______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver