>>> The 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....
>> This is clearly not handled in the driver.
>> For this purpose, we could maintain a request expiry list using the seq
>> field of the BT message. Update the list in the read and write operations
>> and arm a timer to garbage collect any left overs. As for the errno in
>> the write when a response had timeout'ed, may be ETIMEDOUT ?
> I think that would work, though I don't think you really need an
> error response in this case.
> I was thinking more just a timeout in the write function.  Ideally
> the timeout would be calculated at receive time and then be
> passed in on every write, to preserve the request-to-response
> time for slow messages.  I like the simplicity of the driver the
> way it is.
> The trouble is that there is no easy way to pass in a timeout
> in a write operation.  You could pass in a structure where the
> first part is a 32-bit timeout, or something like that.  Or
> maybe just a fixed timeout and assume every message is
> handled in a short enough time that it meets the spec
> requirement.  But that doesn't handle slowness on the
> host side.  You can send the message via an ioctl,  which
> again isn't terribly ideal.
> It would be nice if there was a write function which was
> able to pass metadata, but AFAIK that's only available on
> sockets.
>> For configuration of the maximum response time, a sysfs file would do
>> I think.
>> Do you want that in v3 also ? I have some experimental patches for it,
>> that I can send as follow ups.
> I'm fine either way.

OK. So I will send a v3 with minimal changes, as openbmc has been using 
this driver for a while now. We will discuss the response expiration on 
the next patchset.

I have pushed the patches here :




Openipmi-developer mailing list

Reply via email to