<div dir="ltr">Thank you everyone for your suggestions.<div><br></div><div>Scanning through this it's clear that documentation is one of the biggest most generally agreed upon area to work on.</div><div><br></div><div>Build tools and package management seems like another area with some agreed on improvements. I like the idea of moving to meson. Getting tidy files and revising our style guides also sound like good ideas. I also really agree that we could stand to do some consolidation of processes/repos.</div><div><br></div><div>There is also some use for DBus tooling for both improved code, and for visualizations.</div><div><br></div><div>So here are my next steps:</div><div>  1) Since we have some new people getting started, I've asked them to add documentation at the points they get stuck during on-boarding.</div><div>  2) I'm going to take the ideas in this thread and put together a .md doc with any relevant information I can find. I'll be adding it to openbmc/docs.</div><div>  3) I'll follow up in another thread about some of the ideas around DBus tooling and package consolidation. That seems to be an area where most people agree some improvements can be made, but I'm not sure there is an agreement on how we should do it.</div><div><br></div><div>-Richard</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 20, 2020 at 10:19 AM Sui Chen <<a href="mailto:suichen6@gmail.com">suichen6@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"><div lang="ZH-CN"><div class="gmail-m_-1448104613106764596WordSection1"><p class="MsoNormal"><span lang="EN-US">> On Apr 11, 2020, at 8:15 AM, Andrew Geissler <geissonator at <a href="http://gmail.com" target="_blank">gmail.com</a>> wrote:</span></p><p class="MsoNormal"><span lang="EN-US">> Systemd Visualization</span></p><p class="MsoNormal"><span lang="EN-US">> Another complicated area of OpenBMC is our systemd targets and services. Building on the upstream tools to visualize our systemd targets and services would be useful to new people.</span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:12pt"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:12pt">+1 to visualization, and I have a few thoughts on this ---<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:12pt">My lacking a mental model of how an OpenBMC system works had been my pain point in the first few months working with OpenBMC (I’m a bit new to this area), so after learning the minimal set of survival skills I did something similar to what you mentioned – visualizing the messages passed between different dbus peers (and conveniently, IPMI traffic, as IPMI-related dbus messages exposing all IPMI payload comprise most of the dbus traffic on that particular system I was working on.)<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:12pt"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:12pt">I think packet analysis tools such as Wireshark and graphics frame analysis tools such as RenderDoc, or system event-based Windows Performance tool like GPUView provide great examples of what people might expect to achieve with a visualization tool: capture, inspect and (sometimes) playback, across multiple layers in the software/hardware stack. Many similar existing tools process sequences of events, and in this case of BMCs, the events could be dbus messages. I found a prototype visualizer made at work greatly helpful in explaining to new team members some basic concepts and the IPMI stack on the BMC.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:12pt"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:12pt">The IPMI stack is interesting because it’s one noticeable workload on the particular BMC system I had been working on; in my current limited understanding, having lots of I/O capability to connect to hundreds of sensors is one of the many features that set apart a BMC chip and a similarly powerful smartphone chip, and the broad use of dbus is what sets apart OpenBMC and the desktop Linux distro I had been using. I heard optimization is best done workload by workload, perhaps this rationale applies to visualization too?<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:12pt"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:12pt">I realize I was mostly talking about visualizing the run-time state of the system rather than build-time, but we could visualize the run-time aspect of systemd units too since I have seen many times a dbus message eventually triggering a systemd target to acutate the system, so it would be good to consider both dbus and systemd (and maybe other parts of the system?) to have a more holistic view of the BMC’s operations.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:12pt"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:12pt">Thanks<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:12pt">Sui<u></u><u></u></span></p></div></div>
</blockquote></div>