From: Kun Yi <kun.yi.731@gmail.com>
To: ed.tanous@intel.com
Cc: chunhui.jia@linux.intel.com, venture@google.com,
kuiying.wang@intel.com, james.mihm@intel.com,
hai.v.nguyen@intel.com, james.feist@intel.com,
chunhui.jia@intel.com, openbmc@lists.ozlabs.org,
yong.b.li@intel.com, cheng.c.yang@intel.com,
bradleyb@fuzziesquirrel.com, 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.
Date: Mon, 27 Aug 2018 16:52:41 -0700 [thread overview]
Message-ID: <CADNDqJzNhd_ApA83F8BubFUaGfrc2+W8TPw6_9PZCPwUvxH-+Q@mail.gmail.com> (raw)
In-Reply-To: <7E9441B1E5EFFD4681F54958E821699345835CCF@ORSMSX114.amr.corp.intel.com>
[-- 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 --]
next prev parent reply other threads:[~2018-08-27 23:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-24 7:28 Proposal for caching/buffering POST codes list for one boot process Wang, Kuiying
2018-08-24 16:12 ` Tanous, Ed
2018-08-24 18:07 ` Patrick Venture
2018-08-24 19:33 ` Tanous, Ed
2018-08-27 7:59 ` chunhui.jia
2018-08-27 15:45 ` Tanous, Ed
2018-08-27 23:52 ` Kun Yi [this message]
2018-08-27 23:55 ` Kun Yi
2018-08-27 23:58 ` Kun Yi
2018-08-28 6:09 ` Tanous, Ed
2018-08-29 4:44 ` Wang, Kuiying
2018-08-29 12:19 ` Brad Bishop
2018-08-30 7:23 ` Wang, Kuiying
2018-09-04 20:12 ` Brad Bishop
2018-09-05 7:25 ` Wang, Kuiying
2018-09-05 12:17 ` Brad Bishop
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CADNDqJzNhd_ApA83F8BubFUaGfrc2+W8TPw6_9PZCPwUvxH-+Q@mail.gmail.com \
--to=kun.yi.731@gmail.com \
--cc=bradleyb@fuzziesquirrel.com \
--cc=cheng.c.yang@intel.com \
--cc=chunhui.jia@intel.com \
--cc=chunhui.jia@linux.intel.com \
--cc=ed.tanous@intel.com \
--cc=geissonator@yahoo.com \
--cc=hai.v.nguyen@intel.com \
--cc=james.feist@intel.com \
--cc=james.mihm@intel.com \
--cc=kuiying.wang@intel.com \
--cc=kunyi@google.com \
--cc=openbmc@lists.ozlabs.org \
--cc=qiang.xu@intel.com \
--cc=venture@google.com \
--cc=yong.b.li@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.