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

[Kun Yi]

Duh previous messages were filtered because of dots in my email address I
think..

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

> 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/72556edc/attachment-0001.html>