[RFC weston 0/9] weston-debug protocol, API, and tool

Thu Jun 8 08:23:47 UTC 2017

On Wed, 7 Jun 2017 14:28:58 +0000
"Ucan, Emre (ADITG/ESB)" <eucan at de.adit-jv.com> wrote:

> Hi Pekka,

Hi Emre,

I'm adding back the Cc's. Replies below.

> > From: Pekka Paalanen [mailto:ppaalanen at gmail.com]
> > Sent: Mittwoch, 7. Juni 2017 10:00
> > To: Ucan, Emre (ADITG/ESB)
> > Cc: wayland-devel at lists.freedesktop.org; Friedrich, Eugen (ADITG/ESB)
> > Subject: Re: [RFC weston 0/9] weston-debug protocol, API, and tool
> > 

> > I explained that somewhere. The "list" scope will print a human
> > description of everything supported. The description is not meant to be
> > machine-parsable, not even the names.  
> 
> But then how can I implement a generic weston-debugger client ?`
> It would be much better to have an event similar to global event of
> wl_registry interface, which advertises available streams.

How do you mean you cannot? The client I provided is already completely
generic.

You can add an event for informing about scope names, but what is the
use case? If the use case is some GUI app with a list of scopes you can
click, you probably also want to update that since scopes can be added
and removed at runtime. That means one needs events for adding and
removing scope names. Then you will have a race between the client
subscribing to a scope name and the remove event, but that shouldn't be
too bad since I defined an unknown name to just trigger the failure
event.

If you really want all that, that's fine, but originally I thought that
would be over-engineering this.

After reading your below comments, I think you wouldn't actually need
that, because you would want to use the command line option to
subscribe to debug scopes from compositor boot.

> > 
> > I never intended the scope names or the output to be standardized in
> > any way, hence I thought there was no need to provide
> > machine-readable introspection.
> > 
> > I also wanted to leave the debug print formats themselves
> > unspecified. Most of the scopes will not print machine-parsable
> > text. I do not want to commit to "stable debug print formats" at
> > all. I want to be able to easily add any sort of debug prints
> > whenever I need them and push them upstream - if I needed it to
> > debug something, quite likely it will be needed again in the
> > future. Of course, when one adds a new scope, one can choose give
> > whatever guarantees they want.  
> 
> My idea is a little bit different. We are working on embedded devices
> which are not very easily debuggable. Furthermore, sometimes it is
> very hard to reproduce bugs in an embedded device. Therefore, it is
> very important that we have some logs about the issue when it
> occurred.
> 
> Our plan is to run the weston-debugger client all the time and parse
> stream contents to a persistent memory. I don't think we have to
> specify print formats tediously to achieve this. It would be enough
> to say every debug message ends with "\n".

Sounds reasonable, but if you want to include upstream weston scopes in
there, I cannot guarantee one line is a whole message. The output is
meant for human consumption, so printing e.g. a long array one may want
to break it into several lines, or format matrices one row per line.

But I do agree that one line should be at most one message.

You'll be interested in the command line option idea I wrote down
below. A client may not get everything from boot.

> > After all, the feature was intended to be used directly by humans,
> > avoiding lots of tedious format etc. specification work.
> >   

> > I have two more ideas I did not write down yet:
> > 
> > - A compositor could have another command line option to start the
> >   named debug streams from boot to the given file(s). This way the
> >   logging would start before any clients could even connect. If
> >   implemented properly, scopes would be subscribed to the moment
> > they are created, so no message would be lost.

Oh, and using this option without the --debug option would not expose
the protocol interface, to avoid the DoS risks.

> > 
> > - Adding arguments to scope subscriptions, e.g. getting all protocol
> >   events related to specific client(s).  
> 
> Both ideas are good. I have also another suggestion.
> We can add debug log levels to subscribe request.
> Levels could be "LOG, WARNING and ERROR" so that we can filter some
> of logs.

I have not seen any need for log levels yet, and I would have very hard
time to pick levels for my messages. Essentially we have two levels:
weston_log() is the LOG, WARNING and ERROR level, and debug scopes are
the DEBUG level.

In systems which use multiple debug log levels, I always enable either
as much as possible, or nothing. If I picked something in between, I
wouldn't know what I'd miss, so to be safe I always use the most
verbose level. Levels are practically never documented by what they
will give you, it's only a vague "more" or "less".

I would rather recommend just using different scopes for different
levels of debug. It's totally supported to subscribe several scopes
with the same underlying file, and the messages will be correctly
ordered too.

E.g. for debugging XWM, I would imagine I have to enable at least
xwm-wm-x11 and desktop-shell-xwm debug scopes to get a complete
picture, possibly also desktop-shell-wm for generic WM messages. The
human readable descriptions would also suggest these, so a newcomer
will get a clue he might want more than just one.

> For example, it would be nice to have some logging about touch
> handling. But it would be an overkill to get logging about every
> touch event as default.

In my opinion that would be a perfect example for separate debug
scopes, say: touch-actions and touch-events. You can pick either or
both.

So far I can think of just one way of how different debug levels would
be useful: if increased level provided more information on the *same*
messages. E.g. level 1 prints only the action, level 2 prints the
action and most important arguments, level 3 prints all arguments
verbatim. But I haven't needed that yet, either, and it might be
awkward to use in the code.

> The clients, who interested to get everything, can set log level to
> LOG and other clients can set it to WARNING or ERROR.

I intended all this to be only DEBUG level. DEBUG prints are what will
flood logs and cause performance degradation when enabled and require
scoping. Informational, warning, and error messages should be logged
via the normal logging system, IMHO.

I did not want this to supersede weston_log(). There is the 'log' scope
which will allow you to see the non-debug messages between the debug
messages in the correct order.

This discussion did bring a new idea to mind: we'd probably want named
collections of scopes. E.g. scope 'input-events' would actually be the
collection of scopes 'pointer-events', 'keyboard-events', and
'touch-events'. This would be more flexible than a level system, since
you can really pick and choose exactly what you wanted. With a level
system it is not usually possible to get only level 3 messages without
level 1 and 2 messages - if levels were used to choose which messages
to print rather than the level of detail for each message.

What I'm actually proposing is a tree of debug scopes, where the leaf
nodes are where the actual messages are produced. None of this would
require changes to the protocol though.

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170608/e6433fea/attachment.sig>