Can we improve the experience of working on OpenBMC?

Andrew Jeffery andrew at aj.id.au
Tue Aug 9 13:42:38 AEST 2022



On Tue, 2 Aug 2022, at 07:09, Ed Tanous wrote:
> On Mon, Aug 1, 2022 at 2:27 PM Alexander Amelkin <a.amelkin at yadro.com> wrote:
>>
>> 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.

Yep, fixing this requires addressing specific concerns. Patches or 
design docs would be helpful, or even just a list of specific things 
that we think are a concern.

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

u-bmc might be something to look at here?

Andrew


More information about the openbmc mailing list