libMCTP

[Jeremy Kerr]

Hi Ed,

[+Brad, Emily, Deepak - there are a couple of areas below that could
benefit from your input]

> I'm a lot less worried about the formatting.  Whatever everyone else
> wants is fine.  Clang-format is really useful, so it's not great to
> lose, it for this repo, but there isn't that much code there, so it's
> not a big concern for me.

... I've also realised that we're applying the C++ coding standards to C
code here, which OpenBMC is defined to use kernel-style
(https://github.com/openbmc/docs/blob/master/CONTRIBUTING.md#c).

So, I'll drop this patch as it is. However, as you mention, using clang-
format is a good idea, so I'll add a .clang-format definition for C
here.

If (or when) when we implement the C++ interface, we can add a separate
clang-format definition for that.

> Let me get some of the commits cleaned up, and I'll send out pull
> requests.  We could ask Ronnie if he's ok with a relicense, but it's
> not that difficult to just rebuild it.  95% of that is an auto
> generated file. I just the first implementation I found, mostly as
> part of trying to verify the multi-packet stuff was working
> correctly.  It needs cleaned up a bit.

OK, I'll leave that to you. Let me know when you're OK to get it merged.

At the moment, we're definitely at proof-of-concept stage, so aren't
doing formal reviews, using gerrit etc. When we reach a point where the
proof-of-concept changes into something we're sure we'll end up using,
I'll get the process started to properly integrate into OpenBMC. I'm
after your thoughts on when that should happen. Brad & Emily, yours too.

> > The NVME & smbus backends look good - let me know when you think
> > they're OK for merging to master and I will do so.
> 
> This was something I wasn't sure about;  Does it make sense to have
> nvme-mi in libmctp, or should we be creating libnvme?  I'm kinda
> thinking one library would be nice, I'm not aware of any other
> transports that NVME-mi can use, and it doesn't end up being a lot
> more code.

I think a libnvme would be best, but that does raise a good design
decision.

Previous discussions have tended towards in-process MCTP handlers,
rather than an MCTP daemon that forwards reassembled messages to dbus
(for other processes to handle). This would mean that the MCTP daemon,
for current functionality, would have both handlers for PLDM and NVME-mi 
message types. While the code there could be separated on whatever
scheme we like (say, libmctp + libpldm + libnvme + a main loop), does it
still make sense to have all of that in one process?

I can see the preference for efficiency having the one process, but it
would also be nice to keep things modular (eg, for systems with no NVME
stack, or no PLDM handlers). Deepak, any thoughts?

Cheers,


Jeremy