Re: Initial MCTP design proposal

[Stewart Smith <stewart@linux.ibm.com>]

"Tanous, Ed" <ed.tanous@intel.com> writes:
>> On Dec 10, 2018, at 5:15 PM, Stewart Smith <stewart@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.

Interesting. This is different than for host firmware as we'd be
building nostdlib and providing our own base language support environment.

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

I'd agree, and that's certainly a concern I share. Firefox is probably
the biggest Rust user out there and one that's been integrating Rust
code into a long living large C++ codebase.

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

For our host firmware, all packages have at least two languages:
assembler, C or C++. Even small amounts of Rust are going to increase
safety of a bunch of these critical components.

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

I think the arguments for/against Rust usage in OpenBMC are pretty
different to those for host firmware - I'm hoping to spend some time
better getting a PoC up for our firmware stack at some point in the
future though.


-- 
Stewart Smith
OPAL Architect, IBM.