Initial MCTP design proposal

[Jeremy Kerr]

Hi Emily,

> I had a couple comments on the initial draft.

Super, thanks for taking a look.

>      > > A final important point is that this design is for the host <-->
>      > > BMC
>      > > channel *only*. Even if we do replace IPMI for the host interface,
>      > > we
>      > > will certainly need an IPMI interface available for external system
>      > > management.
> 
> 
> I'm not sure it's correct to demand external IPMI. Most of OpenBMC 
> community (ourselves excluded :( ) is turning towards Redfish for this 
> role.  The external-facing IPMI specification is insecure at the 
> standard level, so I don't think that we should be encouraging or 
> requiring it anywhere, even in an unrelated doc.
> tl;dr I think you should be more generic here and not specify IPMI for 
> external mgmt

OK. I didn't intend to introduce any requirement on IPMI there, even 
implied, so I'll reword.

However, I think there is still a lot of external dependence on an IPMI 
interface - it'll be a while before everyone rewrites all of those 
custom IPMI-based in-house provisioning systems that are out there.

> 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 (and others) have host firmware written in C.

We can always link C to C++, but not the other way around, and it'd be 
fairly straightforward to implement a C++ wrapper for this, which could 
even live in-tree.

Cheers,


Jeremy