Can we improve the experience of working on OpenBMC?

[Alexander Amelkin]

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).

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.