Can we improve the experience of working on OpenBMC?

[Andrew Jeffery]

On Tue, 2 Aug 2022, at 06:57, Alexander Amelkin 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).

So to confirm I've understood your concerns and to distill it down to 
specific things people can agree or disagree with, I have:

* DBus concepts are hard
* Designing for DBus is hard
* DBus use is awkward
* DBus is slow
* Unconventional, OpenBMC-specific DBus patterns are mostly tribal knowledge

Is that fair?

Andrew