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

[Pekka Paalanen]

On Tue, 6 Jun 2017 15:54:06 +0000
"Ucan, Emre (ADITG/ESB)" <eucan at de.adit-jv.com> wrote:

> Hello Pekka,
> 
> Thank you very much for this RFC. We are also investigating options
> to improve logging in weston. Your proposal looks very good. I have
> some comments and suggestions below
> 
> Best regards
> 
> Emre Ucan
> Engineering Software Base (ADITG/ESB)
> 
> > -----Original Message-----
> > From: wayland-devel [mailto:wayland-devel-
> > bounces at lists.freedesktop.org] On Behalf Of Pekka Paalanen
> > Sent: Samstag, 3. Juni 2017 13:58
> > To: wayland-devel at lists.freedesktop.org
> > Cc: Pekka Paalanen
> > Subject: [RFC weston 0/9] weston-debug protocol, API, and tool
> > 
> > From: Pekka Paalanen <pq at iki.fi>
> > 
> > Hi,
> > 
> > this is a little something I wrote while being stuck off-line in a
> > hot place and not having to care about anyone's priorities one bit.
> > 
> > Debug printing has usually been ad hoc weston_log() or even
> > fprintf() calls, often guarded by #ifdefs which require recompiling
> > if you want to enable them.
> > Once enabled, you needed to recompile again to disable them. That
> > works for
> > developers somewhat, but becomes a PITA when you need a user to get
> > you that
> > debug information. I have experienced that particularly with XWM
> > debugs.  
> 
> Why did you make this protocol weston specific ? I think it would be
> better to put in wayland-protocols. Because the protocol itself and
> its use-case is not weston specific.

Hi,

I intended it to be specific to libweston. I didn't care about anyone
else or their use cases, because this was a holiday effort "for fun". I
also avoided most the pain of inventing good names for things. But, RFC
is exactly for gathering feedback before committing, much
appreciated. :-)

If someone wants this to be formulated (named, really) in
not-libweston-specific terms and put it in wayland-protocols, I'm
totally fine with that.

I just wonder if anyone else would actually want to use this - I mean
compositors that do not use libweston. Sounds like you have some
Wayland servers not based on libweston that could behefit?

Just do not name the tool "wayland-debug" or anything like that
sounding overly standard, since I expect most Wayland environments to
not support it. ;-)

We might want to invent a whole new base name for this infrastructure
and name all pieces after that.

> Will it be possible to use weston_debug implementation from out of
> tree weston plugins ?

Yes, that is a goal. I inteded it as a public libweston feature, and
everything using libweston should be able to register new scopes and
print stuff.

> > Here's an alternative proposal: let a Wayland client give Weston an
> > open file descriptor, and Weston will write the debug prints into
> > it on demand. Of course, this is a risky move, and should not
> > usually be allowed - I added a command line option to control it.
> > 
> > As we have different things to debug, and just enabling everything
> > would be a
> > massive flood, let's introduce "debug scopes" to, well, give some
> > scope to the
> > prints. A client can subsribe to any number of scopes, and only
> > those it is interested in.  
> 
> I like the debug scopes concept. But in the proposed protocol, there
> is no way for clients to learn which stream names are supported. Am I
> missing something ? IMO, an event for supported stream names is
> needed.

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.

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.

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

> > This patch series adds the protocol extension, the libweston
> > implementation, Weston command line option to enable it all, and a
> > command line tool to subscribe to the debug messages.
> > 
> > This patch series also adds debug scopes for XWM, Weston logs, and
> > Wayland
> > protocol dumps. We could add a lot more, too: window manager
> > actions, input
> > events, KMS debugging, timeline/wesgr, etc.
> > 
> > This is an RFC because it is still missing some bits I noted in the
> > commit messages, but I wanted to send it out now because I have no
> > idea when I might
> > be able to finish it. If someone else wants to take over, that
> > would be cool.  
> 
> We can take it over, if we can agree upon design and architecture of
> this protocol. Anyway we have to implement something similar for our
> projects...

Oh, excellent!

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.

- Adding arguments to scope subscriptions, e.g. getting all protocol
  events related to specific client(s).

The first one would probably be useful, the second one we could live
without since we can grep.

Given my reasoning which could also be persuaded otherwise, how would
you like to change the design?


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/20170607/cd9ac0d6/attachment.sig>