<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Hello,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">(To Andrew Jeffery)</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.)</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">(To Andrew Geissler)</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Thanks,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Sui</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 28, 2020 at 6:06 AM Andrew Geissler <<a href="mailto:geissonator@gmail.com">geissonator@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Jul 24, 2020, at 10:01 PM, Andrew Jeffery <<a href="mailto:andrew@aj.id.au" target="_blank">andrew@aj.id.au</a>> wrote:<br>
> <br>
<snip><br>
> <br>
> 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.<br>
<br>
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?<br>
<br>
> <br>
> Cheers,<br>
> <br>
> Andrew<br>
<br>
</blockquote></div>