Call for Gardening Tasks

[krtaylor]

On 4/21/20 6:18 PM, Richard Hanley wrote:
> 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.

That would work, but I would also suggest a wiki page. Docs have a 
tendency to get stale quickly, where a wiki page has a lower pain point 
for a small changes. I can get that started if it would help.

Kurt Taylor (krtaylor)


>    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 
> <mailto:suichen6 at gmail.com>> wrote:
> 
>     > On Apr 11, 2020, at 8:15 AM, Andrew Geissler <geissonator at gmail.com <http://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____
>