From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Thu 26 Feb 2004 - 13:37:12 GMT
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
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver