On Friday 24 January 2014 21:40:30 Andreas Hartmetz wrote: > On Friday 24 January 2014 14:21:15 Àlex 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 even > > > 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 unsubscribe <<
