On Thu, Feb 26, 2004 at 12:39:03PM +0000, Mark Lawrence wrote: > 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.
that is my fault, it was done on irc, and not published (at least not the way it should 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. ah, that might be the point where we where/are both wrong, I do not consider your script wasted time or useless efford, because I know that the folks using vserver might start using this interface, the moment it is depreciated ;) facts are: - we need a better interface for hierarchical vservers - the current interface is in stable and will remain there ... so let me make this clear, I appreciate your work and effords, I just don't want to change the interface the third time, after we agreed on that particular interface, without any good reason ... best, Herbert > > 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