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

[Sui Chen]

Hello,

(To Andrew Jeffery)
Yes I had been using the original dbus-pcap since the start of dbus-vis;
dbus-pcap was run twice to obtain both timestamps and JSON outputs. This
approach had been working until I encountered truncated messages, where
dbus-pcap had to be modified a bit so that those truncated messages do not
get discarded.
So far the only modification I need is to keep truncated messages (just
like Wireshark does) and appending timestamps in JSON outputs (so we need
to run dbus-pcap only once.)

(To Andrew Geissler)
In my understanding, the "IPMI" part is OpenBMC-specific, as it's not very
likely that someone runs the IPMI daemon on a regular computer.
This tool was initially intended only for IPMI, so there are functions that
look for text-encoded IPMI-related DBus calls in ipmi_parse.js . dbus-pcap
was added later and it's this addition that enables more generic use.

The question of generic use is an interesting one -- dbus-vis could be used
outside of OpenBMC, and it may complement existing tools due to a few
differences: It started something that resembles a performance analysis
tool, so it focused on showing large amounts of events/information to focus
in a compact way, with limited ability to inspect individual events. DBus
traffic on the OpenBMC can easily reach hundreds of messages per second,
whereas on desktop systems this number is generally a lot lower (based on
my limited experience.) This seems to affect the design of tools as well,
as existing tools like GNU Bustle seem to be designed for showing fewer
messages per second and are more focused on finding the dependency between
DBus function calls.

Thanks,
Sui


On Tue, Jul 28, 2020 at 6:06 AM Andrew Geissler <geissonator at gmail.com>
wrote:

>
>
> > On Jul 24, 2020, at 10:01 PM, Andrew Jeffery <andrew at aj.id.au> wrote:
> >
> <snip>
> >
> > 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.
>
> Unless there’s a pressing need to move it, I’d vote we just keep it where
> it is. Once it’s matured a bit, y’all could propose on a move to a separate
> repo. I wonder if this even needs to be under the openbmc namespace? Seems
> like a fairly generic D-Bus tool that could be useful outside of openbmc?
>
> >
> > Cheers,
> >
> > Andrew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200805/9651bfba/attachment.htm>