libMCTP

[Tanous, Ed]

> 
> However, it does make reformatting a little tricky, as clang-format doesn't
> handle that. I don't want to bikeshed this too much, but is that OK with you?
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 put the proposed changes up in a 'format' branch:
> 
>   https://github.com/jk-ozlabs/libmctp/commits/format
> 
> If that's all OK then I'll fast-forward master to there.

Yep, those look fine for the moment.

> 
> I can't merge your NVME change as it is at the moment, as the crc32 file is
> licenced as LGPLv2+. While I am working with our folks to get approval for my
> work libmctp to be licenced as dual GPL+Apache-2, this still wouldn't cover
> including crc32.c there. Ronnie might be fine to relicense it though - do you
> want me to ask him?

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.

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

-Ed