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 [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver