<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 12:46 PM, Alistair Popple
      wrote:<br>
    </div>
    <blockquote cite="mid:1563711.C1JEQYCva8@mexican" type="cite">
      <pre wrap="">Hi,

On Fri, 26 Jun 2015 12:11:38 Neelesh Gupta wrote:

<snip>

</pre>
      <blockquote type="cite">
        <pre wrap="">Why should client forget doing it ? If it does so, then of course 
programming error
and should be fixed.
</pre>
      </blockquote>
      <pre wrap="">Yes, but there are no circumstances that I know of in which the client should 
not dequeue the message so why introduce the possibility of these types of 
errors?</pre>
    </blockquote>
    <br>
    <small>May be client wants to do something different with
      ipmi_cmd_done() -> msg->error()<br>
      case, like giving a 'retry'... but my point was more from the
      interface point of view that<br>
      looked nicer to me..<br>
    </small><br>
    <blockquote cite="mid:1563711.C1JEQYCva8@mexican" type="cite">
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">In line with, when client does alloc(), it has to free() and when it 
does queue_msg(),
it should be doing dequeue_msg() after completion or whenever it thinks 
doing so..
IMO backend should not decide when to dequeue the message.

Moreover, backend may want to do more that just list_del() in 
dequeue_msg() ..
like updating the state or number of outstanding requests etc.. that all 
can nicely
be exposed though an interface.
</pre>
      </blockquote>
      <pre wrap="">Why can't you do that with the current interface? You can just call 
ipmi_cmd_done() to notify the client and once that returns the backend can 
update whatever flags, etc. it needs...

</pre>
      <blockquote type="cite">
        <blockquote 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>
        <pre wrap="">I think that's what I added as part of this patch in core/ipmi.c
</pre>
      </blockquote>
      <pre wrap="">Yes, that bit is fine and should be submitted as a separate patch adding just 
that.</pre>
    </blockquote>
    <br>
    <small>It contradicts.. in one hand backend dequeing the message its
      own, on the other<br>
      hand providing a client interface to dequeue the message ...<br>
      so we should rather delete the existing dequeue_msg() callback for
      the sake of<br>
      client not having any impression of dequeuing the message and that
      will be taken<br>
      care by all the backend drivers..<br>
      <br>
      Regards,<br>
      Neelesh.<br>
    </small><br>
    <blockquote cite="mid:1563711.C1JEQYCva8@mexican" type="cite">
      <pre wrap="">
Regards,

Alistair

</pre>
      <blockquote type="cite">
        <pre wrap="">Thanks,
Neelesh.

</pre>
        <blockquote type="cite">
          <pre wrap="">- Alistair

On Wed, 24 Jun 2015 22:40:32 Neelesh Gupta wrote:

</pre>
        </blockquote>
      </blockquote>
    </blockquote>
    <br>
  </body>
</html>