Re: [PATCH] knotty: Fold knotty2 into knotty and make it the default

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2012-08-15 at 12:20 -0700, Chris Larson wrote:
> On Wed, Aug 15, 2012 at 9:50 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > There is no good reason knotty2 shouldn't be the default now. If you need
> > the old behaviour, just pipe the output through cat as non-interactive
> > terminals get the old output.
> >
> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> 
> I'm 100% in favor of this series, for what it's worth. I've been using
> knotty2 as my default BITBAKE_UI for months, just ignoring the minor
> bugs. The reduction in unnecessary output makes it *much* easier to
> spot *real* problems.

Agreed, that is one of the intents.

> That said, I think we should look into prefixing some of our log
> messages — some of them don't make it clear what task/recipe emitted
> them, making it difficult to isolate their cause. But of course, that
> was an issue with knotty as well, but it was slightly easier to narrow
> down the cause based on where it stood between the task
> started/completed messages :). Would you be open to potentially
> injecting a log message filter which adds task context informastion,
> in the code which forks the tasks? Then the formatter would have to do
> a hasattr() to check for that and add it to the format, but it'd mean
> we *always* know what task log messages are coming from.

Obviously such a change needs to be carefully considered but yes, I
think knowing where a message has come from is important and I'm in
favour of doing something. I'm slightly surprised there isn't something
in the message already.

Thinking about this more, I think we did add in the pid or at least
looked at doing so, with the assumption that the UI code could have
information about what that pid represents and be able to supplement the
data. I think the graphical UIs might use that to put the messages into
different "buckets" in the graphical task display.

The immediate reaction is "lets just add all the data to the event"
which I can certainly understand. My big worry is the pushing up the
size of each event to something that damages performance, particularly
if we so start using remote UIs. This is why the uihelper code exists,
effectively to maintain a UI side cache of the data rather than
pickle/unpickling the same thing many times.

As a side note, I do want to get handlers only receiving the events they
care about with server side filtering too. That is starting to show up
on profiles of some workloads.

Also, we currently use the word "package" in the old knotty output, I
want to change that to "recipe" as its confusing and we should be
consistent about our terminology. I guess I should propose a patch :)

Cheers,

Richard