From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Thu 26 Feb 2004 - 11:03:11 GMT
On Thu, Feb 26, 2004 at 09:29:47AM +0000, Mark Lawrence wrote:
> On Thu, 26 Feb 2004, Herbert Poetzl wrote:
>
> > hrm, what do you need the patch for?
> >
> > reboot restart
> > reboot halt
> > reboot ...
> >
> > isn't useful in my opinion
>
> Herbert, please re-read my email here:
>
> http://list.linux-vserver.org/archive/vserver/msg06152.html
>
> where I explained my rational for a change in the interface between kernel
> and userland for vserver events. The main points were extensibility beyond
> the reboot function, and to not unecessarily hide the details of the call.
- 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?
+ case LINUX_REBOOT_CMD_CAD_ON:
+ case LINUX_REBOOT_CMD_CAD_OFF:
+ return 0
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 ...
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)
> I thought I made a reasonable case, but did not hear back from anyone. My
> fault for assuming silence equals agreement, but I would still appreciate
> knowing why you think I'm on the wrong track. I'm willing to take my
> medicine :-) [English expression for having to go though necessary pain]
> > (you do not want to provide patches for each
> > vserver kernel patch, and folks do not want to
> > apply it ;)
>
> The patch was for developers to take a look and/or play with. I certainly
> don't expect people with production systems to go through the effort. My
> apologies to all if that was how it was taken.
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?
we could have taken Paul's vshelper and 'just' adapt the kernel
to that interface, but we did not, because we considered the
current approach better ...
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 ...
feel free to branch and/or provide vshelper kernel patches ...
best,
Herbert
> Cheers, Mark.
> --
> Mark Lawrence
>
> _______________________________________________
> Vserver mailing list
> Vserver_at_list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver