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 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 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 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 >>> >>