Can we improve the experience of working on OpenBMC?

[Alexander Amelkin]

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

Well, I don't think a single repo would help actually if we want to
keep the system modular and versatile as it is (and what is definitely 
good).

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

Yes, you're right that I'm not currently proposing anything specific, 
and that it
would surely require a start with a design document.

However, I thought the idea of Andrew's message was to outline the problems,
and it looks to me like you more or less agree that those are problems, 
don't you?

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

Thanks for the hint, I will look into that.

WBR, Alexander.

P.S. I feel like I must apologize for maybe sounding rude or somehow 
inappropriate sometimes.
As you may know, English is not my native language and I, despite the 
vocabulary and the ability
to construct more-or-less proper sentences, may often lack the ability 
to properly/politely express
my ideas or understand the tone and/or subtle meaning of what other 
people say or write.
Please forgive me for that, no offense or disrespect is ever implied on 
my side.