MCTP control messages handling in libmctp

[Andrew Jeffery]

Just reply as a note to say this is resolved.

On Sat, 21 Mar 2020, at 04:51, Wiktor Gołgowski wrote:
> Hi all, 
> 
> 
> 
> I am currently working on a base implementation for handling control
> 
> command requests in libmctp (relevant change here: [1]).  As I am not
> 
> sure which solution would be the best here, I would like to put a
> 
> quick summary of the different approaches that could be used for
> 
> further discussion on Monday PMCI WG meeting:
> 
> 
> 
> 1. External handling (as Andrew proposes)
> 
> All control messages are handled in the layer calling into
> 
> libmctp. The daemon is in control of how messages are handled.

After further thought the approach I was suggesting isn't viable,
mainly due to transport-specific commands. It would require violating
abstractions or abusing the routing table to push the messages back
down the stack (the latter being racy).

> 
> 
> 
> 2. Separate handlers (what [1] introduces)
> 
> There are separate callbacks for regular messages, control messages and
> 
> transport-specific control messages. The main reason for this behavior
> 
> is that I expect transport-specific commands to be executed in the
> 
> context of the specific binding (serial, VDM, SMBus). I also hope that
> 
> the daemon could be at least partially binding-agnostic.

This is the route we'll go. It's optional to install a control message handler
into the context, so a daemon could receive all control messages by default
by just doing nothing.

> 
> 
> 
> 3. Handling is split between the caller and the library
> 
> We could identify control command requests that libmctp (or its
> 
> specific binding) is able to fulfill independently from the daemon
> 
> (for example Get EID) and leave the implementation of the rest to the
> 
> actual caller.

We can achieve this with the suggestion in 2. if the installed callback
is structured correctly.

Thanks for posting the summary Wiktor.

Andrew