[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Announce: A useful d-bus analyzer
From:       Andreas Hartmetz <ahartmetz () gmail ! com>
Date:       2014-01-24 20:44:54
Message-ID: 2554371.vQvtaLul65 () rechenplan
[Download RAW message or body]

On Friday 24 January 2014 21:40:30 Andreas Hartmetz wrote:
> On Friday 24 January 2014 14:21:15 =C0lex Fiestas wrote:
> > On Tuesday 14 January 2014 19:54:14 Andreas Hartmetz wrote:
> > > Hello,
> > > =

> > > I've worked on and off on an implementation of the d-bus protocol
> > > which, of course, needs a proof of concept. That proof of concept is
> > > a d-bus analyzer, probably the best d-bus analyzer around if your use
> > > case isn't exactly what Bustle covers - in that case, Bustle is the
> > > best.
> > > The analyzer can:
> > > - filter messages on various header fields
> > > - group calls with returns
> > > - displays call/return latency as observed from the d-bus daemon
> > > - show a list of currently unanswered calls (helps find those that
> > > =

> > >   take really long or time out)
> > > =

> > > - pause, continue and reset capturing
> > > - save and load captures
> > > - display the full types and contents of messages in a nice format
> > > - associate calls with returns in order to obtain nicer sender and
> > > =

> > >   receiver addresses - in the screenshot, the address parts in
> > >   parentheses are obtained that way
> > > =

> > > Screenshot: http://i.imgur.com/CK1ejcb.png
> > > =

> > > With the library part, I tried to make it nice to use and fast because
> > > those features must be there from the beginning if they are ever going
> > > to be there at all. What it is not is complete (not even close) or ev=
en
> > > memory leak proof under some circumstances. The parts that are not
> > > core marshalling are also not as optimized as they could be.
> > > =

> > > The thing is called Dferry and can be found under Playground/SDK
> > > on projects.kde.org or just kde:dferry in git if you have that git
> > > shortcut set up.
> > > After building and installing, the analyzer is called dfer-analyzer.
> > > =

> > > Cheers,
> > > Andreas
> > =

> > This looks awesome !
> > =

> > I remember a conversation between you and Thiago to make use of your
> > marshaller instead of libdbus, is that still in place?
> =

> Well, kdbus has switched to GVariant marshalling in the meantime.
> I heard that about a week ago and I'm not particularly happy about it.
> The serialization format is incompatible (although somewhat similar)
> and there are even some semantic differences like an option type and a
> fixed length array type that don't exist in libdbus. That is obviously
> a problem if you try to bridge the formats both ways.
> I guess I could implement the GVariant format: it's not more difficult
> than the old format, most of the unit tests will be applicable, and I
> know how to handle the tricky cases that can occur in that kind of
> serialization format.
> Also the GVariant code is not crap unlike libdbus, so it can serve as
> an example.
> =

> For the benefit of any semi-involved onlookers let me state very
> clearly here:
> - "kdbus" is a multicast local socket type in the Linux kernel.
>   It knows almost nothing about d-bus. It's just a few hundred lines.
> - the user-space part that implements the d-bus protocol lives in the
>   systemd repository and is called libystemd (no kidding). It's about

Eh, of course it's "libsystemd".

>   23k lines. That is what people mean most of the time when they say
>   "kdbus". I'm using it like that as well because it has no proper name
>   otherwise.


>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib=
e <<
[prev in list] [next in list] [prev in thread] [next in thread]