Call for Gardening Tasks

[Richard Hanley]

Thank you everyone for your suggestions.

Scanning through this it's clear that documentation is one of the biggest
most generally agreed upon area to work on.

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.

There is also some use for DBus tooling for both improved code, and for
visualizations.

So here are my next steps:
  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.
  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.
  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.

-Richard



On Mon, Apr 20, 2020 at 10:19 AM Sui Chen <suichen6 at gmail.com> wrote:

> > On Apr 11, 2020, at 8:15 AM, Andrew Geissler <geissonator at gmail.com>
> wrote:
>
> > Systemd Visualization
>
> > 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.
>
>
>
> +1 to visualization, and I have a few thoughts on this ---
>
> 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.)
>
>
>
> 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.
>
>
>
> 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?
>
>
>
> 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.
>
>
>
> Thanks
>
> Sui
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200421/9cef48cf/attachment.htm>