Initial MCTP design proposal

[Stewart Smith]

Emily Shaffer <emilyshaffer at google.com> writes:
>> > > The reason for a library is to allow the same MCTP implementation
>> > > to be
>> > > used in both OpenBMC and host firmware; the library should be
>> > > bidirectional. To allow this, the library would be written in
>> > > portable C
>> > > (structured in a way that can be compiled as "extern C" in C++
>> > > codebases), and be able to be configured to suit those runtime
>> > > environments (for example, POSIX IO may not be available on all
>> > > platforms; we should be able to compile the library to suit). The
>> > > licence for the library should also allow this re-use; I'd suggest
>> > > a
>> > > dual Apache & GPL licence.
>>
>
> Love the idea of the implementation being bidirectional and able to be
> dropped onto the host side as well, but I must be missing why that requires
> we write it in C.  Are we targeting some platform missing a C++
> cross-compiler implementation? If we're implementing something new from
> scratch, I'd so much prefer to bump up the maintainability/modernity and
> write it in C++ if we can.  Or could be I'm missing some key reason that it
> follows we use C :)

We're certainly missing C++ runtime libraries and support, so that would
be an interesting set of limitations. Even as it is, our C libraries are
pretty limited.

If we were going to bring a not-C language into firmware, I'd prefer we
look at something modern like Rust, that's designed to not have
programmers marching around with guns pointed at their feet.
(I have C++ opinions, most of which can be summarised by NAK :)

-- 
Stewart Smith
OPAL Architect, IBM.