Proposal for caching/buffering POST codes list for one boot process.

[Kun Yi]

Obvious another thing we would need to consider is performance. A host
booting session could produce dozens or hundreds of POST codes depending on
how verbose the BIOS is, and we should be careful not to design something
that creates too much DBus traffic. These embedded processors are not
performance beasts by any means.

Kun


On Mon, Aug 27, 2018 at 4:52 PM Kun Yi <kun.yi.731 at gmail.com> wrote:

> I think the choice of *where* to put such buffering warrants some thoughts
> and design. Going through what I have thought:
>
> 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
> - keeps listening to POST codes published
> - keeps polling host state
> - when host power state toggled, write the POST codes received to a file
> on disk
>
> 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.
> 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.
>
> On Mon, Aug 27, 2018 at 8:47 AM Tanous, Ed <ed.tanous at intel.com> wrote:
>
>> > Could you confirm if the "/xyz/openbmc_project/host/post/1" that we
>> talked here contains a list of post code for one cycle?
>>
>> Correct.  Each one would contain a list of POST codes for that boot.
>>
>> -Ed
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180827/9473e165/attachment-0001.html>