ipmi transport size returns

[Patrick Venture]

In the future, the IPMI command handler will know the channel over
which the command is received, and therefore can ask what the maximum
reply size is --

Here's a caveat though.  The 64-byte buffer hard-coded in ipmid could
be fix, but at it currently stands, it's too large for BT.  Per the
IPMI spec, KCS requires 3 bytes on request, and 4 on replies of
header, and BT requires 4 bytes on request, and 5 on reply.  So the 64
byte built-in buffer, which was aimed at just aspeed (IPMI over BT)
really should have been 59 bytes at most so it could add the reply
header pieces.  But nevertheless, I'm looking at the max channel size
field.  And the transport used will need to account for this header
somehow.

When one asks, what's the maximum transport size for BT on aspeed,
it's 64 bytes. But the IPMI command needs to know it's really 59. And
if it's OEM it'll add additional information, but that's per command.

I'm curious what thought has gone into this.

Also, currently, there's no code for an IPMI client to ask the
question of transport size, so they can know how large a request they
can send.  The getChannelInfo doesn't return that field, and I don't
see an IPMI spec way to do it, other than using the OEM specific
bytes. -- which our plan for downstream.

Is there an overall cleaner or more general approach in mind for this?
 A linux kernel header will tell the client the host's maximum
transport size, but not the BMC's which could be smaller.

Patrick