Initial MCTP design proposal

[Tanous, Ed]

> On Dec 10, 2018, at 5:15 PM, Stewart Smith <stewart at linux.ibm.com> wrote:
> 
> 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 :)

Rust seems like an interesting language, but when I last evaluated it for BMC use while looking at the redfish implementation, it suffered from a few killer problems that would prevent its use on a current-generation BMC

1. The binaries are really big.  Just an application with the basics (DBus, sockets, io loop) ends up at several megabytes last time I attempted it.  Most of our c++ equivalents consume less than half that.  I know rust as a community has worked on the size issue, and is making progress, but given the size constraints that we’re under, I don’t think 2MB minimum applications are worth the space they take.  For reference, the project is working to make it possible to build an image without python to save ~3MB from the final image.
2. Rust is relatively new.  Finding “seasoned” rust developers, especially ones that have that in combination with embedded skills is difficult.  I don’t believe we have anyone active on the project today that has built rust applications at the scale the OpenBMC project is at these days.  At this point there are a few commercial products that use rust, so at least someone has ripped of that band aid, but I don’t know if any high reliability, embedded products that have taken the plunge yet.  If we want to be the first, we should evaluate what that’s going to cost for the project.
3. The supposed safety in rust is only guaranteed if you never call into a c library or native code.  While there’s pure rust based equivalents for a lot of the things we use, most of our code is stitching together calls between libraries, and northbound interfaces.  There might be one or two examples of where we could use rust without any c libraries, but I’m going to guess there’s only that .  Given that, are we better off having a given application written in one language or two?

In short, I’m interested to see how the rust ecosystem progresses, and I wait with baited breath for something to emerge that’s better than C/C++, but today, I don’t think rust applications in OpenBMC would have my support.