Can we improve the experience of working on OpenBMC?

[Ed Tanous]

On Mon, Aug 1, 2022 at 2:27 PM Alexander Amelkin <a.amelkin at yadro.com> wrote:
>
> Hi Andrew!
>
> 27.07.2022 04:22, Andrew Jeffery пишет:
> > # Problems
> >
> > 1. Yocto is hard
> >      1. Managing patch stacks is hard
> >      2. Yocto-specific tooling is hard
> >      3. Finding the right recipe file to inspect/modify is hard
> >      4. Yocto has too much documentation
> > 2. OpenBMC has too much documentation
> > 3. Querying design/implementation/bug properties across the project is hard
> > 4. Coordinating breaking changes is hard
> > 5. Coordinating tree-wide changes is hard
> > 6. Identifying the right repo to file a bug against is hard
> > 7. Transferring bugs between repos is hard
> > 8. Bug reports are duplicated across repos
> > 9. Bug reports are ignored
> > 10. Working out where to submit a patch is hard
> > 11. Getting patches reviewed is hard
> > 12. New repo requests are bottle-necked
>
> To the list of the problems I would add:
>
> 13. D-Bus is hard for newcomers not familiar with it, best practices are
> not described,
> inter-process synchronization when accessing large d-bus objects (like
> network interfaces)
> is not inherent to d-bus, and auxiliary synchronization using standard
> POSIX means is neither
> explicitly requested/advised, nor controlled/enforced.
> All that may lead
> (and have previously led) to
> races and various other problems. Add to that the long and inconvenient
> prefixing that we've
> discussed earlier in another thread where Brad has supported my point of
> those being useless
> to the project.
>
> 14. D-Bus may become a bottleneck or a slowing factor (due to the
> context switching overhead) for
> the situations when two processes are communicating actively. A standard
> POSIX IPC like pipes,
> mq or shm could become a solution (with d-bus or any other method used
> as an aid to negotiate
> names, keys, or whatever other credentials needed to access a common IPC).

FWIW, in the original context of "a single repo would help with these
things" I don't think either of these would be helped with a
rearrangement of code.

With that said, lots of people dislike dbus.  There are performance
critical things (SOL, KVM, Virtual media) that have completely avoided
it.  If you have a proposal for something better, I'd highly recommend
writing up a design doc.

>
> WBR, Alexander
>
> P.S. All in all, I think d-bus wasn't a good choice of IPC for a system
> running on a low-performance single-core ARM chip.
>

So propose something better that solves the same problem within
OpenBMC?  Or, alternatively, there's u-bmc that from the sounds of
reading your above is closer to your ideal in terms of trade offs (no,
IPC, efficient point to point comms with grpc), it might be worth
looking into for either using directly, or porting some of the ideas
it encompases into OpenBMC.