[PATCH linux dev-4.7 7/8] ipmi: maintain a request expiry list

[Patrick Williams]

On Thu, Nov 03, 2016 at 07:46:28PM +0100, Cédric Le Goater wrote:
> On 11/03/2016 07:23 PM, Patrick Williams wrote:
> > On Thu, Nov 03, 2016 at 11:26:09AM +1100, Cyril Bur wrote:
> >> On Wed, 2016-10-26 at 08:57 +0200, Cédric Le Goater wrote:
> >>> Regarding the response expiration handling, the IPMI spec says :
> >>>
> >>>    The BMC must not return a given response once the corresponding
> >>>    Request-to-Response interval has passed. The BMC can ensure this
> >>>    by maintaining its own internal list of outstanding requests
> >>> through
> >>>    the interface. The BMC could age and expire the entries in the
> >>> list
> >>>    by expiring the entries at an interval that is somewhat shorter
> >>> than
> >>>    the specified Request-to-Response interval....
> >>>
> >>> To handle such case, we maintain list of received requests using the
> >>> seq number of the BT message to identify them. The list is updated
> >>> each time a request is received and a response is sent. The
> >>> expiration
> >>> of the reponses is handled at each updates but also with a timer.
> >>>
> >>
> >> I agree that the BMC kernel is most logical place to do this, at the
> >> moment btbridged does attempt something similar no?
> >>
> >> Should we patch btbridged to not? Should I least remove duplicated
> >> logic? 
> >>
> > 
> > Brendan,
> > 
> > Are you paying attention to this discussion?  I think you had some
> > opposition to the kernel doing any additional work in this space because
> > you wanted to run a non-IPMI protocol over the IPMI bridge.
> 
> We will then need a new kernel driver for the non-IPMI interface. 
> This one is for the iBT interface which is IPMI oriented. 
> 
> I am sure we can find some common points though. Hopefully, the 
> userspace interface would be the same. For the moment we only
> have an ioctl for the SMS ATN interrupt but we should be adding
> some more.
> 

I believe Brendan was keeping the IPMI protocol but implementing
different flow control on top of it.  That means, specifically, that
having the kernel track commands and timeouts would not be what he
wanted.

> Thanks,
> 
> C.  
> 

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161103/8d633740/attachment.sig>