Suggestions on implementing Wayland Protocol Dumper.
Pekka Paalanen
ppaalanen at gmail.com
Wed Jun 11 00:33:07 PDT 2014
On Mon, 09 Jun 2014 16:54:09 +0800
Boyan Ding <stu_dby at 126.com> wrote:
> Hi,
> According to [1], from which the idea of protocol dumper came, the
> purpose of the protocol dumper is to track exactly how a client
> communicate with the server, and to make a difference with how
> WAYLAND_DEBUG=server works.
>
> So IMHO, the protocol dumper may be implemented as a standalone program,
> though it may probably reside in the wayland source tree. And it job is
> to reset the WAYLAND_DISPLAY environment argument, fork off the client
> wanted and redirect what the client send to the real server, dumping the
> data in the process -- just like a proxy.
>
> The benefit of this way of implementation is that it not only help
> weston but may also help the development of other projects (e.g. you may
> even use it under Gnome on Wayland).
Hi,
I fully agree with Boyan here. A basic usage (tracing a single
application, all its connections, and all its children) should not
require *any* changes to any software: not libwayland, not a
compositor, and not clients. If it requires changes or even just
recompilation, it will be too hard to use. Bryce gave good examples on
why.
I also think it should start as a separate project from Wayland and
Weston. I would like it to be an independent tool. Wayland is stable,
after all, and the tool should not have any specific dependencies to
e.g. a compositor.
In IRC, I had a discussion with blsd, who wanted to trace absolutely
all clients of a compositor from the beginning, and his problem was
where to "hijack" the connections. While it probably would be useful in
some cases, I believe the basic usage as above is more important and
useful first. Once the basic part works, we can find a way later how to
put in place so it will catch all clients.
At a later stage, you might also want to see, if some existing analysis
framework could be useful (Wireshark?). I have no idea if there is a
flexible enough one, and even then it would probably be worthwhile to
have a mininal command line tool that just stores the trace into a
file and leaves analysis for off-line.
Thanks,
pq
> On Mon, 2014-06-09 at 11:17 +0530, Srivardhan wrote:
> > Hi,
> >
> > The following are the ways in which a Protocol Dumper can be implemented:
> > 1. Just before sending a message or when a message is received, the message
> > can be written to a file. This change can be done in libwayland under #ifdef
> > DEBUG. So when built enabling DEBUG, we should get all the protocol
> > messages.
> > 2. We can introduce another layer in Weston for monitoring. This layer would
> > act as Man in the middle. This layer would listen to a socket to which all
> > the Wayland clients would attach and this layer would in turn attach to the
> > server socket. This layer would print the messages it received from the
> > client and would transfer to the server and vise a versa. This could be
> > included in #ifdef DEBUG, so that it is enabled only in DEBUG builds.
> >
> > I feel the 1st approach is simpler, What are your thoughts?
> >
> > Thank-you,
> > Hebbar
More information about the wayland-devel
mailing list