Hi Ken,
----- Original Message -----
> [...]
> The man page documents the new -o (bit of a bugger that -L was already
> used!)
Heh, yep :)
> and -K ... but the QA test uses --local-PMDA and no -K option ...
> the former probably does not matter, I'll extend 948 to exercise the latter.
Thanks!
> -o implies -L ... is that intended? If there is nothing to log, why not
> exit unless -L is specified, like for other "host" contexts?
Not sure it does - opts.Lflag is "local context mode within libpcp getopts",
hence I set that here as well, so that the libpcp getopt code is informed as
to the context type being requested (and can do its sanity checking).
"linger" is the magic variable for -L in pmlogger, which we don't set auto-
magically - so, I think local context does what you were expecting, and its
the opts.Lflag thats confusing things? Maybe we need a comment there where
that is set.
> In pmlogger's fetch.c I think the call to __pmEncodeResult in myFetch()
> should have kept the first parameter as ctxp->c_pmcd->pc_fd not 0 ...
> this is never called in the PM_CONTEXT_LOCAL case.
*nod*
> Now the first argument to pmEncodeResult() is not used these days, but
> might be used again in the future if we have a new version dependency in
> the protocol (which is what the "fd" argument is used for).
>
> I've reverted this bit of the change in my tree and it passes all -g
> pmlogger QA (including the modified 948).
Okie doke, good rationale re future proofing - I thought it was simply
unused for hysterical raisins, and the fd-passing a leftover. Agreed,
we should go with putting it back as it was.
> And finally the pmnewlog usage message was wrong on multiple fronts, but
> that was mostly prior damage, not part of the most recent commit ...
> I've fixed that too.
OK, great.
> So I have commits ready to be pushed for all of these ... just need your
> feedback and an answer on the -o => -L question.
>
I *think* its OK as is, and is behaving as I think we both expect ... but I
might well be missing something more subtle there?
Thanks!
--
Nathan
|