phosphor-host-ipmid and phosphor-net-ipmid architecture

[Vernon Mauery <vernon.mauery@linux.intel.com>]

I am working on an ipmi provider library and had a few questions and 
observations.

1) Why are there separate ipmi message queues for the host and network? 
   It seems awkward that for the host, the ipmi request comes from a 
   different process (btbridge, or in our case kcsbridge), while for the 
   network (RMCP+), the messages are handled directly in the same 
   process.

   It seems that the network handler could just as easily package the 
   command up and send it to ipmid the same way that btbridge does.

2) Can we modify the signature of the handlers so that they can behave 
   in a more intelligent manner? It would be nice if they were handed a 
   gsl::span<uint8_t> instead of a void* and a length. This allows for  
   a no-copy, bounds-checked way of passing buffers.

   It would be nice to know what channel something came in on. We might 
   want to be able to change behavior based on the incoming channel (as 
   some channels are more secure than others).

   It would be nice to know what IPMI privilege the command came in 
   with (ADMIN for session-less commands) so that the command handler 
   can behave appropriately based on the user.
   
3) When registering commands, it would be nice of the list also 
   maintained a priority so that commands could be easily overridden. 
   Currently the only way to override a command is to make sure that 
   your library gets loaded first (and this is done via the library 
   name). If we had default ipmi commands loaded at DEFAULT_PRIO and 
   then had some higher priorities such as MFR_PRIO, and OEM_PRIO, or 
   something like that, we could have integrators further on down the 
   line able to easily add a new provider library and piecemeal override 
   individual command. An alternate (or addition) might be the addition 
   of a unregister command method to remove an existing command so it 
   could be replaced with a new one (or just straight up removed).


I am happy to work on changes that I would like to see and submit 
patches for review, but I wanted to know if there was some sort of 
historical or other reason that would prevent my work from getting 
rejected before I actually do the work.

--Vernon