Re: [openbmc-tools] dbus-vis: DBus capture visualization tool

["Andrew Jeffery" <andrew@aj.id.au>]

Hi Sui,

On Sat, 25 Jul 2020, at 08:29, Sui Chen wrote:
> Hello,
> 
> dbus-vis is a GUI tool that does the following:
> - It visualizes busctl pcap files, the same format that dbus-pcap reads 
> and parses.
> - It somewhat half-automates the process of doing a capture on the BMC 
> and transferring back to the host for analysis (console access to the 
> BMC is required for this purpose.)
> 
> dbus-vis started from an IPMI timeline visualization tool that only 
> processes IPMI requests exposed on DBus. After I learned about 
> dbus-pcap 
> <https://github.com/openbmc/openbmc-tools/tree/master/amboar/obmc-scripts/dbus-pcap>, it turns out DBus visualization is a natural extension to this visualization tool. Because this tool currently accepts the same packet capture format that dbus-pcap uses (by using a slightly modified version of dbus-pcap), it kind of functions like a GUI version of dbus-pcap, and is therefore named "dbus-vis" to indicate what it does.
> 
> The main difference between this tool and other existing dbus 
> visualizers (such as GNU bustle) is that dbus-vis shows data in a 
> compact timeline format, making it possible to show >10K events 
> simultaneously on the screen at an acceptable frame rate, as well as 
> making it easier to focus on DBus performance rather than the 
> dependency of different DBus units (that other existing tools seem to 
> be focusing on.)
> 
> The changes for the first commit of dbus-vis is listed below; any 
> comment is greatly appreciated.
> https://gerrit.openbmc-project.xyz/c/openbmc/openbmc-tools/+/34263
> 

This sounds really interesting, thanks for sharing your work! I've added myself as a reviewer (as the author of dbus-pcap).

I've taken a brief look at your patch and think there's a bit we could do to improve dbus-pcap for your needs (e.g. adding timestamps to the json output). I'd also like to work out how we can better integrate dbus-pcap with dbus-vis so we're not maintaining a fork of the code. Maybe if we package things properly they could both be more easily installed onto a system. That way we could describe the relationship in terms of package dependencies rather than forking or using wget for the job.

I'm also thinking it might be time to start (an) independent repo(s) where we can develop the two, what we have is starting to grow a bit beyond the intended scope of openbmc-tools. Looping Brad and Andrew Geissler in here to get their thoughts.

Cheers,

Andrew