<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<small>Hi Alistair,</small><br>
<br>
<div class="moz-cite-prefix">On 06/26/2015 11:33 AM, Alistair Popple
wrote:<br>
</div>
<blockquote cite="mid:13436038.tI3HIXefrT@mexican" type="cite">
<pre wrap="">Hi Naalesh,
I'm having trouble understanding what's wrong with the current interface that
requires it to be changed. Why should it be up to the client to dequeue
messages? They're dequeued automatically on completion. Relying on the client
to always do this seems like it would just introduce another source of
programming errors when the client forgets to.</pre>
</blockquote>
<br>
<small>Why should client forget doing it ? If it does so, then of
course programming error<br>
and should be fixed.<br>
<br>
In line with, when client does alloc(), it has to free() and when
it does queue_msg(),<br>
it should be doing dequeue_msg() after completion or whenever it
thinks doing so..<br>
IMO backend should not decide when to dequeue the message. <br>
<br>
Moreover, backend may want to do more that just list_del() in
dequeue_msg() ..<br>
like updating the state or number of outstanding requests etc..
that all can nicely<br>
be exposed though an interface.<br>
</small><br>
<blockquote cite="mid:13436038.tI3HIXefrT@mexican" type="cite">
<pre wrap="">
I agree that there is currently no API to dequeue an ipmi message (mainly
because no one has needed it yet) but it should just be a thin wrapper in
core/ipmi.c that calls backend->dequeue_msg().</pre>
</blockquote>
<br>
<small>I think that's what I added as part of this patch in
core/ipmi.c</small><br>
<br>
<small>Thanks,<br>
Neelesh.<br>
</small><br>
<blockquote cite="mid:13436038.tI3HIXefrT@mexican" type="cite">
<pre wrap="">
- Alistair
On Wed, 24 Jun 2015 22:40:32 Neelesh Gupta wrote:
</pre>
<br>
</blockquote>
<br>
</body>
</html>