<div dir="ltr">I think the choice of *where* to put such buffering warrants some thoughts and design. Going through what I have thought:<div><br></div><div>1. It's possible to implement host state detection and host POST code buffering all in a client daemon, which is a long-lived process that</div><div>- keeps listening to POST codes published</div><div>- keeps polling host state</div><div>- when host power state toggled, write the POST codes received to a file on disk</div><div><br></div><div>Pros of this approach is that server daemons are kept simple. POST code server doesn't need to talk to host state daemon or even assume its existence.</div><div>Pros of buffering on server side: potentially there will be more than one identities needing the list of POST codes. IPMI? Logging? It would really help if we can identify some concrete use cases.</div><div><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 27, 2018 at 8:47 AM Tanous, Ed <<a href="mailto:ed.tanous@intel.com">ed.tanous@intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Could you confirm if the "/xyz/openbmc_project/host/post/1" that we talked here contains a list of post code for one cycle? <br>
<br>
Correct.  Each one would contain a list of POST codes for that boot.<br>
<br>
-Ed<br>
</blockquote></div></div></div>