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

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

[Wang, Kuiying]

[-- Attachment #1: Type: text/plain, Size: 2753 bytes --]

Hi Kun,
Current implementation of phosphor-host-postd just publish one POST code to DBus, but no caching/buffering logic.
So other module cannot get a list of POST code for current/previous boot process.
So there is a proposal to do that which could benefit issue debugging and analysis.


1.      Define 2 properties in Raw.interface.yaml (https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/State/Boot/Raw.interface.yaml )
properties:
    - name: Value
      type: uint64
      description: >
          The POST code value.
    - name: PrePostCodes
      type: variant[uint32, uint64]
      description: >
          The POST code list of previous boot process.
          The fist uint32 is the time stamp the post code;
          the second uint64 is the post code value.
    - name: CurrPostCodes
      type: variant[uint32, uint64]
      description: >
          The POST code list of current boot process.
          The fist uint32 is the time stamp the post code;
          the second uint64 is the post code value.

2.      Save post code to CurrPostCodes list together w/ timestamp in PostCodeEventHandler function.

https://github.com/openbmc/phosphor-host-postd/blob/master/main.cpp#L99

3.      When detect host power off, copy CurrPostCodes to PrePostCodes and clean CurrPostCodes in host state manager

https://github.com/openbmc/phosphor-state-manager/blob/master/host_state_manager.cpp#L225

BTW: we could implement an IPMI command to get current/previous post codes remotely.

Thanks,
Kuiying.

From: Kun Yi [mailto:kun.yi.731@gmail.com]
Sent: Wednesday, August 22, 2018 12:36 AM
To: Wang, Kuiying <kuiying.wang@intel.com>
Cc: Li, Yong B <yong.b.li@intel.com>
Subject: Re: about post code

Hi Kuiying,

Yes, only the current POST code is published on DBus. The idea of caching/buffering more POST codes on the DBus server side is definitely interesting. It would require some thoughts on the DBus interface. If you have some thoughts, you are welcome to email the openbmc mailing list for a discussion.

With that said, it's not hard to implement a listener client that caches the POST codes received and stream them to log/file/network. The listener can also talk to the host Power control interface to interpret which POST codes these are for.

Thanks,
Kun

On Mon, Aug 20, 2018 at 2:51 AM Wang, Kuiying <kuiying.wang@intel.com<mailto:kuiying.wang@intel.com>> wrote:
Hi Kunyi,
According to the Raw.interface.yaml definition, and existing implementation, only current one post code is posted to dbus, right?
Do you plan to save all the post codes(and the timestamp for each) for previous boot process and current process?


Thanks,
Kuiying.


[-- Attachment #2: Type: text/html, Size: 14518 bytes --]

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

[Tanous, Ed]

Would it make more sense to simply include multiple post code paths on dbus?

/xyz/openbmc_project/host/post/current
/xyz/openbmc_project/host/post/1
/xyz/openbmc_project/host/post/2

This would allow the interface itself to define an arbitrary number of post code collections, rather than just previous and current.  Initially, previous and current is likely all we need, but in the future, it might be good to store more.

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

[Patrick Venture]

On Fri, Aug 24, 2018 at 9:13 AM Tanous, Ed <ed.tanous@intel.com> wrote:
>
> Would it make more sense to simply include multiple post code paths on dbus?
>
> /xyz/openbmc_project/host/post/current
> /xyz/openbmc_project/host/post/1
> /xyz/openbmc_project/host/post/2
>
> This would allow the interface itself to define an arbitrary number of post code collections, rather than just previous and current.  Initially, previous and current is likely all we need, but in the future, it might be good to store more.

I like this approach, but one would need to enumerate the tree to know
how many there are cached available.  Albeit, maybe that's trivial :D

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

[Tanous, Ed]

> 
> I like this approach, but one would need to enumerate the tree to know how
> many there are cached available.  Albeit, maybe that's trivial :D

A DBus call to Objectmapper  would tell you how many objects you have.
GetSubtree  path:/xyz/openbmc_project/host/post depth: 0 interfaces ["xyz.openbmc_project.Host.State.Boot.Raw"] would get you a list of all Post code interfaces
Depending on the context you might also be able to get away with just GetSubtreePaths.

I wouldn't call it trivial, but it falls in the category of doable.

Alternatively, if you know you need all of them for whatever response you're building, GetManagedObjects to the Post code daemon directly would save you a round trip through DBus.

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

[chunhui.jia]

[-- Attachment #1: Type: text/plain, Size: 2169 bytes --]

Ed, Venture, 

Could you confirm if the "/xyz/openbmc_project/host/post/1" that we talked here contains a list of post code for one cycle? 

From my understanding, it should be like:
/xyz/openbmc_project/host/post/current (objpath)
->xyz.openbmc_project.Host.State.Boot.Raw (intf)
---->Value (a list of POST code for current POST) (property)
/xyz/openbmc_project/host/post/1
->xyz.openbmc_project.Host.State.Boot.Raw
---->Value (a list of POST code for previous POST)
/xyz/openbmc_project/host/post/2
->xyz.openbmc_project.Host.State.Boot.Raw
---->Value (a list of POST code for the time before previous)

Is that correct?

The reason I am asking is that the orginal post code interface only keep *one* post code. Even if one DC cycle could generate 30~40 post code, it just keep latest and previous one. 
I assume the objpath /xyz/openbmc_project/host/post/1 contains a list.   Otherwise, it will just represent one post code in one cycle.  In the latter case, we will have /xyz/openbmc_project/host/post/[0~40] objects for one cycle and it looks ugly. 



chunhui.jia
 
From: Tanous, Ed
Date: 2018-08-25 03:33
To: Patrick Venture
CC: Wang, Kuiying; Mihm, James; Nguyen, Hai V; Feist, James; Jia, Chunhui; OpenBMC Maillist; Li, Yong B; Yang, Cheng C; Brad Bishop; Xu, Qiang; kun.yi.731@gmail.com; geissonator@yahoo.com
Subject: RE: Proposal for caching/buffering POST codes list for one boot process.
> 
> I like this approach, but one would need to enumerate the tree to know how
> many there are cached available.  Albeit, maybe that's trivial :D
 
A DBus call to Objectmapper  would tell you how many objects you have.
GetSubtree  path:/xyz/openbmc_project/host/post depth: 0 interfaces ["xyz.openbmc_project.Host.State.Boot.Raw"] would get you a list of all Post code interfaces
Depending on the context you might also be able to get away with just GetSubtreePaths.
 
I wouldn't call it trivial, but it falls in the category of doable.
 
Alternatively, if you know you need all of them for whatever response you're building, GetManagedObjects to the Post code daemon directly would save you a round trip through DBus.
 
 

[-- Attachment #2: Type: text/html, Size: 7388 bytes --]

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

[Tanous, Ed]

> 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

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

[Kun Yi]

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1425 bytes --]

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

[Kun Yi]

[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2201 bytes --]

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

[Kun Yi]

[-- Attachment #1: Type: text/plain, Size: 1690 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2675 bytes --]

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

[Tanous, Ed]

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

I would be really surprised if POST codes were ever a performance bottleneck even in with the worst implementation possible.  Hundreds of post codes in a minute is still orders of magnitude less data than the sensors are already pushing over DBus.

>On Mon, Aug 27, 2018 at 4:52 PM Kun Yi <kun.yi.731@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
This would mean that partial boots, or boots that have over current issues wouldn't be persisted at all.  It's a bit of an implementation detail at this point, but I suspect we're going to want to persist post codes more often than just every boot.

> 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.
I think we also need to consider that the POST code saving mechanism should be up as soon as possible after boot to make sure that in the case where power restore policy is set to ON, we can capture as many post codes as possible from the host booting.  In previous implementations, this meant buffering in the kernel driver, and making the application a lightweight system for persisting POST codes, rather than actually capture them itself.

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

[Wang, Kuiying]

Thanks a lot for you all comments and suggestions.
Let me summary and update my solution now.
1. Define an interface to post code list "CodeList.yaml" in " phosphor-dbus-interfaces" repo.
     Under folder " xyz/openbmc_project/Post /"
2. Define a property "PostCodeList" w/ type "array[uint64]" (std::vector<uint64_t>)
3. Developing a post code client to monitor and collect all the post codes.
        a). define a "MAX_BOOT_CYCLE_NUM" to limit how many boot cycle post codes can be buffered.
        b). when a post code comes, push back to the end of CodeList array.
        c). when a boot cycle ends, push end flag like "0xffff *** ffff " to the end of CodeList array.
        d). when hit to max boot cycle number, delete one cycle post code set at the beginning of CodeList array.
        e). save CodeList property into file system " /var/lib/phosphor-state-manager/postCodeList"
4. create a new repo for post code client " phosphor-host-post-code-client".

Thanks,
Kuiying.


-----Original Message-----
From: Tanous, Ed 
Sent: Tuesday, August 28, 2018 2:10 PM
To: kunyi731@gmail.com
Cc: chunhui.jia@linux.intel.com; venture@google.com; Wang, Kuiying <kuiying.wang@intel.com>; Mihm, James <james.mihm@intel.com>; Nguyen, Hai V <hai.v.nguyen@intel.com>; Feist, James <james.feist@intel.com>; Jia, Chunhui <chunhui.jia@intel.com>; openbmc@lists.ozlabs.org; Li, Yong B <yong.b.li@intel.com>; Yang, Cheng C <cheng.c.yang@intel.com>; bradleyb@fuzziesquirrel.com; Xu, Qiang <qiang.xu@intel.com>; geissonator@yahoo.com; Kun Yi <kunyi@google.com>
Subject: RE: RE: Proposal for caching/buffering POST codes list for one boot process.

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

I would be really surprised if POST codes were ever a performance bottleneck even in with the worst implementation possible.  Hundreds of post codes in a minute is still orders of magnitude less data than the sensors are already pushing over DBus.

>On Mon, Aug 27, 2018 at 4:52 PM Kun Yi <kun.yi.731@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
This would mean that partial boots, or boots that have over current issues wouldn't be persisted at all.  It's a bit of an implementation detail at this point, but I suspect we're going to want to persist post codes more often than just every boot.

> 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.
I think we also need to consider that the POST code saving mechanism should be up as soon as possible after boot to make sure that in the case where power restore policy is set to ON, we can capture as many post codes as possible from the host booting.  In previous implementations, this meant buffering in the kernel driver, and making the application a lightweight system for persisting POST codes, rather than actually capture them itself.

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

[Brad Bishop]

> On Aug 29, 2018, at 12:44 AM, Wang, Kuiying <kuiying.wang@intel.com> wrote:
> 
> Thanks a lot for you all comments and suggestions.
> Let me summary and update my solution now.
> 1. Define an interface to post code list "CodeList.yaml" in " phosphor-dbus-interfaces" repo.
>     Under folder " xyz/openbmc_project/Post /“

I suggest /xyz/openbmc_project/State/Boot

This is where Patrick put the existing post code interface (Raw).

> 2. Define a property "PostCodeList" w/ type "array[uint64]" (std::vector<uint64_t>)

How about just List?  or History?  Something without “Post” in it please.
We have a similar concept on POWER and I can implement this interface
but we don’t call them post codes.

> 3. Developing a post code client to monitor and collect all the post codes.
>        a). define a "MAX_BOOT_CYCLE_NUM" to limit how many boot cycle post codes can be buffered.
>        b). when a post code comes, push back to the end of CodeList array.
>        c). when a boot cycle ends, push end flag like "0xffff *** ffff " to the end of CodeList array.

Can we just create a new dbus object in this situation?  Rather than shoving
multiple boots into a single object with ffff delimeters?

>        d). when hit to max boot cycle number, delete one cycle post code set at the beginning of CodeList array.
>        e). save CodeList property into file system " /var/lib/phosphor-state-manager/postCodeList”

This would be whatever we call this new application.  /var/lib/phosphor-state-manager
is for the phosphor-state-manager program's state data.

> 4. create a new repo for post code client " phosphor-host-post-code-client”.

Why is it a client?  Is it also a server?

> 
> Thanks,
> Kuiying.

Thank you!

> 
> 
> -----Original Message——

This is called top posting, please try to avoid when using the mail-list.
It makes threaded conversation hard to follow and respond to.  thx.

> From: Tanous, Ed 
> Sent: Tuesday, August 28, 2018 2:10 PM
> To: kunyi731@gmail.com
> Cc: chunhui.jia@linux.intel.com; venture@google.com; Wang, Kuiying <kuiying.wang@intel.com>; Mihm, James <james.mihm@intel.com>; Nguyen, Hai V <hai.v.nguyen@intel.com>; Feist, James <james.feist@intel.com>; Jia, Chunhui <chunhui.jia@intel.com>; openbmc@lists.ozlabs.org; Li, Yong B <yong.b.li@intel.com>; Yang, Cheng C <cheng.c.yang@intel.com>; bradleyb@fuzziesquirrel.com; Xu, Qiang <qiang.xu@intel.com>; geissonator@yahoo.com; Kun Yi <kunyi@google.com>
> Subject: RE: RE: Proposal for caching/buffering POST codes list for one boot process.
> 
>> 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.
> 
> I would be really surprised if POST codes were ever a performance bottleneck even in with the worst implementation possible.  Hundreds of post codes in a minute is still orders of magnitude less data than the sensors are already pushing over DBus.
> 
>> On Mon, Aug 27, 2018 at 4:52 PM Kun Yi <kun.yi.731@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
> This would mean that partial boots, or boots that have over current issues wouldn't be persisted at all.  It's a bit of an implementation detail at this point, but I suspect we're going to want to persist post codes more often than just every boot.
> 
>> 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.
> I think we also need to consider that the POST code saving mechanism should be up as soon as possible after boot to make sure that in the case where power restore policy is set to ON, we can capture as many post codes as possible from the host booting.  In previous implementations, this meant buffering in the kernel driver, and making the application a lightweight system for persisting POST codes, rather than actually capture them itself.
> 

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

[Wang, Kuiying]

Hi Brad,
1. Accept your suggestion.
     Define an interface PostCodeList.yaml under "/xyz/openbmc_project/State/Boot "
2. Accept your suggestion
    Define a property "List" w/ type "array[uint64]"
3.  Accept your suggestion
    To create a new dbus object for different boot cycle but not using end flag
4. compare w/ "phosphor-host-postd", it is suitable for client. But for other module like IPMI command tool, it is kind of server.
    How about "phosphor-post-code-manager"? do you think it is ok?


Thanks,
Kuiying.


-----Original Message-----
From: Brad Bishop [mailto:bradleyb@fuzziesquirrel.com] 
Sent: Wednesday, August 29, 2018 8:20 PM
To: Wang, Kuiying <kuiying.wang@intel.com>
Cc: Tanous, Ed <ed.tanous@intel.com>; kunyi731@gmail.com; Xu, Qiang <qiang.xu@intel.com>; Mihm, James <james.mihm@intel.com>; Nguyen, Hai V <hai.v.nguyen@intel.com>; Feist, James <james.feist@intel.com>; Jia, Chunhui <chunhui.jia@intel.com>; venture@google.com; openbmc@lists.ozlabs.org; chunhui.jia@linux.intel.com; Yang, Cheng C <cheng.c.yang@intel.com>; Li, Yong B <yong.b.li@intel.com>; geissonator@yahoo.com
Subject: Re: Proposal for caching/buffering POST codes list for one boot process.



> On Aug 29, 2018, at 12:44 AM, Wang, Kuiying <kuiying.wang@intel.com> wrote:
> 
> Thanks a lot for you all comments and suggestions.
> Let me summary and update my solution now.
> 1. Define an interface to post code list "CodeList.yaml" in " phosphor-dbus-interfaces" repo.
>     Under folder " xyz/openbmc_project/Post /“

I suggest /xyz/openbmc_project/State/Boot

This is where Patrick put the existing post code interface (Raw).

> 2. Define a property "PostCodeList" w/ type "array[uint64]" 
> (std::vector<uint64_t>)

How about just List?  or History?  Something without “Post” in it please.
We have a similar concept on POWER and I can implement this interface but we don’t call them post codes.

> 3. Developing a post code client to monitor and collect all the post codes.
>        a). define a "MAX_BOOT_CYCLE_NUM" to limit how many boot cycle post codes can be buffered.
>        b). when a post code comes, push back to the end of CodeList array.
>        c). when a boot cycle ends, push end flag like "0xffff *** ffff " to the end of CodeList array.

Can we just create a new dbus object in this situation?  Rather than shoving multiple boots into a single object with ffff delimeters?

>        d). when hit to max boot cycle number, delete one cycle post code set at the beginning of CodeList array.
>        e). save CodeList property into file system " /var/lib/phosphor-state-manager/postCodeList”

This would be whatever we call this new application.  /var/lib/phosphor-state-manager is for the phosphor-state-manager program's state data.

> 4. create a new repo for post code client " phosphor-host-post-code-client”.

Why is it a client?  Is it also a server?

> 
> Thanks,
> Kuiying.

Thank you!

> 
> 
> -----Original Message——

This is called top posting, please try to avoid when using the mail-list.
It makes threaded conversation hard to follow and respond to.  thx.

> From: Tanous, Ed
> Sent: Tuesday, August 28, 2018 2:10 PM
> To: kunyi731@gmail.com
> Cc: chunhui.jia@linux.intel.com; venture@google.com; Wang, Kuiying 
> <kuiying.wang@intel.com>; Mihm, James <james.mihm@intel.com>; Nguyen, 
> Hai V <hai.v.nguyen@intel.com>; Feist, James <james.feist@intel.com>; 
> Jia, Chunhui <chunhui.jia@intel.com>; openbmc@lists.ozlabs.org; Li, 
> Yong B <yong.b.li@intel.com>; Yang, Cheng C <cheng.c.yang@intel.com>; 
> bradleyb@fuzziesquirrel.com; Xu, Qiang <qiang.xu@intel.com>; 
> geissonator@yahoo.com; Kun Yi <kunyi@google.com>
> Subject: RE: RE: Proposal for caching/buffering POST codes list for one boot process.
> 
>> 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.
> 
> I would be really surprised if POST codes were ever a performance bottleneck even in with the worst implementation possible.  Hundreds of post codes in a minute is still orders of magnitude less data than the sensors are already pushing over DBus.
> 
>> On Mon, Aug 27, 2018 at 4:52 PM Kun Yi <kun.yi.731@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
> This would mean that partial boots, or boots that have over current issues wouldn't be persisted at all.  It's a bit of an implementation detail at this point, but I suspect we're going to want to persist post codes more often than just every boot.
> 
>> 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.
> I think we also need to consider that the POST code saving mechanism should be up as soon as possible after boot to make sure that in the case where power restore policy is set to ON, we can capture as many post codes as possible from the host booting.  In previous implementations, this meant buffering in the kernel driver, and making the application a lightweight system for persisting POST codes, rather than actually capture them itself.
> 

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

[Brad Bishop]

> On Aug 30, 2018, at 3:23 AM, Wang, Kuiying <kuiying.wang@intel.com> wrote:
> 
> Hi Brad,
> 1. Accept your suggestion.
>     Define an interface PostCodeList.yaml under "/xyz/openbmc_project/State/Boot “
> 2. Accept your suggestion
>    Define a property "List" w/ type "array[uint64]”
> 3.  Accept your suggestion
>    To create a new dbus object for different boot cycle but not using end flag
> 4. compare w/ "phosphor-host-postd", it is suitable for client. But for other module like IPMI command tool, it is kind of server.
>    How about "phosphor-post-code-manager"? do you think it is ok?

phosphor-post-code-manager sounds fine, thanks.

> 
> 
> Thanks,
> Kuiying.
> 
> 
> -----Original Message-----
> From: Brad Bishop [mailto:bradleyb@fuzziesquirrel.com] 
> Sent: Wednesday, August 29, 2018 8:20 PM
> To: Wang, Kuiying <kuiying.wang@intel.com>
> Cc: Tanous, Ed <ed.tanous@intel.com>; kunyi731@gmail.com; Xu, Qiang <qiang.xu@intel.com>; Mihm, James <james.mihm@intel.com>; Nguyen, Hai V <hai.v.nguyen@intel.com>; Feist, James <james.feist@intel.com>; Jia, Chunhui <chunhui.jia@intel.com>; venture@google.com; openbmc@lists.ozlabs.org; chunhui.jia@linux.intel.com; Yang, Cheng C <cheng.c.yang@intel.com>; Li, Yong B <yong.b.li@intel.com>; geissonator@yahoo.com
> Subject: Re: Proposal for caching/buffering POST codes list for one boot process.
> 
> 
> 
>> On Aug 29, 2018, at 12:44 AM, Wang, Kuiying <kuiying.wang@intel.com> wrote:
>> 
>> Thanks a lot for you all comments and suggestions.
>> Let me summary and update my solution now.
>> 1. Define an interface to post code list "CodeList.yaml" in " phosphor-dbus-interfaces" repo.
>>    Under folder " xyz/openbmc_project/Post /“
> 
> I suggest /xyz/openbmc_project/State/Boot
> 
> This is where Patrick put the existing post code interface (Raw).
> 
>> 2. Define a property "PostCodeList" w/ type "array[uint64]" 
>> (std::vector<uint64_t>)
> 
> How about just List?  or History?  Something without “Post” in it please.
> We have a similar concept on POWER and I can implement this interface but we don’t call them post codes.
> 
>> 3. Developing a post code client to monitor and collect all the post codes.
>>       a). define a "MAX_BOOT_CYCLE_NUM" to limit how many boot cycle post codes can be buffered.
>>       b). when a post code comes, push back to the end of CodeList array.
>>       c). when a boot cycle ends, push end flag like "0xffff *** ffff " to the end of CodeList array.
> 
> Can we just create a new dbus object in this situation?  Rather than shoving multiple boots into a single object with ffff delimeters?
> 
>>       d). when hit to max boot cycle number, delete one cycle post code set at the beginning of CodeList array.
>>       e). save CodeList property into file system " /var/lib/phosphor-state-manager/postCodeList”
> 
> This would be whatever we call this new application.  /var/lib/phosphor-state-manager is for the phosphor-state-manager program's state data.
> 
>> 4. create a new repo for post code client " phosphor-host-post-code-client”.
> 
> Why is it a client?  Is it also a server?
> 
>> 
>> Thanks,
>> Kuiying.
> 
> Thank you!
> 
>> 
>> 
>> -----Original Message——
> 
> This is called top posting, please try to avoid when using the mail-list.
> It makes threaded conversation hard to follow and respond to.  thx.
> 
>> From: Tanous, Ed
>> Sent: Tuesday, August 28, 2018 2:10 PM
>> To: kunyi731@gmail.com
>> Cc: chunhui.jia@linux.intel.com; venture@google.com; Wang, Kuiying 
>> <kuiying.wang@intel.com>; Mihm, James <james.mihm@intel.com>; Nguyen, 
>> Hai V <hai.v.nguyen@intel.com>; Feist, James <james.feist@intel.com>; 
>> Jia, Chunhui <chunhui.jia@intel.com>; openbmc@lists.ozlabs.org; Li, 
>> Yong B <yong.b.li@intel.com>; Yang, Cheng C <cheng.c.yang@intel.com>; 
>> bradleyb@fuzziesquirrel.com; Xu, Qiang <qiang.xu@intel.com>; 
>> geissonator@yahoo.com; Kun Yi <kunyi@google.com>
>> Subject: RE: RE: Proposal for caching/buffering POST codes list for one boot process.
>> 
>>> 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.
>> 
>> I would be really surprised if POST codes were ever a performance bottleneck even in with the worst implementation possible.  Hundreds of post codes in a minute is still orders of magnitude less data than the sensors are already pushing over DBus.
>> 
>>> On Mon, Aug 27, 2018 at 4:52 PM Kun Yi <kun.yi.731@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
>> This would mean that partial boots, or boots that have over current issues wouldn't be persisted at all.  It's a bit of an implementation detail at this point, but I suspect we're going to want to persist post codes more often than just every boot.
>> 
>>> 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.
>> I think we also need to consider that the POST code saving mechanism should be up as soon as possible after boot to make sure that in the case where power restore policy is set to ON, we can capture as many post codes as possible from the host booting.  In previous implementations, this meant buffering in the kernel driver, and making the application a lightweight system for persisting POST codes, rather than actually capture them itself.
>> 

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

[Wang, Kuiying]

Ok, great.
Brad, please help create a repo "phosphor-post-code-manager"
I will upstream a patch based on our discusstion and let you all to review.

Thanks,
Kuiying.

-----Original Message-----
From: Brad Bishop [mailto:bradleyb@fuzziesquirrel.com] 
Sent: Wednesday, September 05, 2018 4:12 AM
To: Wang, Kuiying <kuiying.wang@intel.com>
Cc: kunyi731@gmail.com; Mihm, James <james.mihm@intel.com>; Tanous, Ed <ed.tanous@intel.com>; Li, Yong B <yong.b.li@intel.com>; Feist, James <james.feist@intel.com>; Jia, Chunhui <chunhui.jia@intel.com>; venture@google.com; openbmc@lists.ozlabs.org; Xu, Qiang <qiang.xu@intel.com>; Yang, Cheng C <cheng.c.yang@intel.com>; chunhui.jia@linux.intel.com; geissonator@yahoo.com; Nguyen, Hai V <hai.v.nguyen@intel.com>
Subject: Re: Proposal for caching/buffering POST codes list for one boot process.



> On Aug 30, 2018, at 3:23 AM, Wang, Kuiying <kuiying.wang@intel.com> wrote:
> 
> Hi Brad,
> 1. Accept your suggestion.
>     Define an interface PostCodeList.yaml under 
> "/xyz/openbmc_project/State/Boot “ 2. Accept your suggestion
>    Define a property "List" w/ type "array[uint64]”
> 3.  Accept your suggestion
>    To create a new dbus object for different boot cycle but not using 
> end flag 4. compare w/ "phosphor-host-postd", it is suitable for client. But for other module like IPMI command tool, it is kind of server.
>    How about "phosphor-post-code-manager"? do you think it is ok?

phosphor-post-code-manager sounds fine, thanks.

> 
> 
> Thanks,
> Kuiying.
> 
> 
> -----Original Message-----
> From: Brad Bishop [mailto:bradleyb@fuzziesquirrel.com]
> Sent: Wednesday, August 29, 2018 8:20 PM
> To: Wang, Kuiying <kuiying.wang@intel.com>
> Cc: Tanous, Ed <ed.tanous@intel.com>; kunyi731@gmail.com; Xu, Qiang 
> <qiang.xu@intel.com>; Mihm, James <james.mihm@intel.com>; Nguyen, Hai 
> V <hai.v.nguyen@intel.com>; Feist, James <james.feist@intel.com>; Jia, 
> Chunhui <chunhui.jia@intel.com>; venture@google.com; 
> openbmc@lists.ozlabs.org; chunhui.jia@linux.intel.com; Yang, Cheng C 
> <cheng.c.yang@intel.com>; Li, Yong B <yong.b.li@intel.com>; 
> geissonator@yahoo.com
> Subject: Re: Proposal for caching/buffering POST codes list for one boot process.
> 
> 
> 
>> On Aug 29, 2018, at 12:44 AM, Wang, Kuiying <kuiying.wang@intel.com> wrote:
>> 
>> Thanks a lot for you all comments and suggestions.
>> Let me summary and update my solution now.
>> 1. Define an interface to post code list "CodeList.yaml" in " phosphor-dbus-interfaces" repo.
>>    Under folder " xyz/openbmc_project/Post /“
> 
> I suggest /xyz/openbmc_project/State/Boot
> 
> This is where Patrick put the existing post code interface (Raw).
> 
>> 2. Define a property "PostCodeList" w/ type "array[uint64]" 
>> (std::vector<uint64_t>)
> 
> How about just List?  or History?  Something without “Post” in it please.
> We have a similar concept on POWER and I can implement this interface but we don’t call them post codes.
> 
>> 3. Developing a post code client to monitor and collect all the post codes.
>>       a). define a "MAX_BOOT_CYCLE_NUM" to limit how many boot cycle post codes can be buffered.
>>       b). when a post code comes, push back to the end of CodeList array.
>>       c). when a boot cycle ends, push end flag like "0xffff *** ffff " to the end of CodeList array.
> 
> Can we just create a new dbus object in this situation?  Rather than shoving multiple boots into a single object with ffff delimeters?
> 
>>       d). when hit to max boot cycle number, delete one cycle post code set at the beginning of CodeList array.
>>       e). save CodeList property into file system " /var/lib/phosphor-state-manager/postCodeList”
> 
> This would be whatever we call this new application.  /var/lib/phosphor-state-manager is for the phosphor-state-manager program's state data.
> 
>> 4. create a new repo for post code client " phosphor-host-post-code-client”.
> 
> Why is it a client?  Is it also a server?
> 
>> 
>> Thanks,
>> Kuiying.
> 
> Thank you!
> 
>> 
>> 
>> -----Original Message——
> 
> This is called top posting, please try to avoid when using the mail-list.
> It makes threaded conversation hard to follow and respond to.  thx.
> 
>> From: Tanous, Ed
>> Sent: Tuesday, August 28, 2018 2:10 PM
>> To: kunyi731@gmail.com
>> Cc: chunhui.jia@linux.intel.com; venture@google.com; Wang, Kuiying 
>> <kuiying.wang@intel.com>; Mihm, James <james.mihm@intel.com>; Nguyen, 
>> Hai V <hai.v.nguyen@intel.com>; Feist, James <james.feist@intel.com>; 
>> Jia, Chunhui <chunhui.jia@intel.com>; openbmc@lists.ozlabs.org; Li, 
>> Yong B <yong.b.li@intel.com>; Yang, Cheng C <cheng.c.yang@intel.com>; 
>> bradleyb@fuzziesquirrel.com; Xu, Qiang <qiang.xu@intel.com>; 
>> geissonator@yahoo.com; Kun Yi <kunyi@google.com>
>> Subject: RE: RE: Proposal for caching/buffering POST codes list for one boot process.
>> 
>>> 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.
>> 
>> I would be really surprised if POST codes were ever a performance bottleneck even in with the worst implementation possible.  Hundreds of post codes in a minute is still orders of magnitude less data than the sensors are already pushing over DBus.
>> 
>>> On Mon, Aug 27, 2018 at 4:52 PM Kun Yi <kun.yi.731@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
>> This would mean that partial boots, or boots that have over current issues wouldn't be persisted at all.  It's a bit of an implementation detail at this point, but I suspect we're going to want to persist post codes more often than just every boot.
>> 
>>> 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.
>> I think we also need to consider that the POST code saving mechanism should be up as soon as possible after boot to make sure that in the case where power restore policy is set to ON, we can capture as many post codes as possible from the host booting.  In previous implementations, this meant buffering in the kernel driver, and making the application a lightweight system for persisting POST codes, rather than actually capture them itself.
>> 

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

[Brad Bishop]

> On Sep 5, 2018, at 3:25 AM, Wang, Kuiying <kuiying.wang@intel.com> wrote:
> 
> Ok, great.
> Brad, please help create a repo "phosphor-post-code-manager”

done!