From: "Laszlo Ersek" <lersek@redhat.com>
To: "Gao, Zhichao" <zhichao.gao@intel.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: "Yao, Jiewen" <jiewen.yao@intel.com>,
"Wang, Jian J" <jian.j.wang@intel.com>,
"Zhang, Chao B" <chao.b.zhang@intel.com>,
"Justen, Jordan L" <jordan.l.justen@intel.com>,
"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Stefan Berger" <stefanb@linux.ibm.com>
Subject: Re: [edk2-devel] [PATCH 06/13] OvmfPkg/Tcg2PhysicalPresenceLib: Use pcd for user response wait time
Date: Mon, 20 Jan 2020 09:06:28 +0100 [thread overview]
Message-ID: <e51fc56f-3957-594f-d378-cbf226c18e8f@redhat.com> (raw)
In-Reply-To: <a882f490924141d2a2b04b2ec43949bf@intel.com>
On 01/19/20 08:03, Gao, Zhichao wrote:
> Hi Laszlo,
>
> Sorry for misunderstanding the logic in read key function. That makes the incorrect analysis.
> The read key function is waiting for "specific" key press not a key press. We should drop all the other pressing-key.
> That means we should create a hotkey service like BDS one. It is not simple. I think that is why the original use the busy loop.
> I don't think it makes sense to port the function from BDS for such a simple function. If there is a requirement for the hot key service to be public and common, it makes sense.
> So I prefer to keep the original busy loop instead of porting hot key service.
I don't understand why the fact that we're interested in a specific key
only, changes *how* we should wait for keys. In both approaches (wait
for event, vs. busy wait), we should consume and drop keys until we find
what we need. Yes, the wait-for-event approach needs another loop around
it, but that still doesn't make it a "busy" loop -- it only runs when
there's an event to process (keypress or timeout). This is a standard
event loop mechanism; block/sleep in the loop body until something
occurs, then process the event; lather, rinse, repeat.
Anyway, I don't feel strongly about this. If your original approach is
accepted for SecurityPkg, I can live with it in OvmfPkg too.
Thanks
Laszlo
next prev parent reply other threads:[~2020-01-20 8:06 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-03 3:04 [PATCH 00/13] Extend and fix the TCG/TCG2 Physical Presence Interface Gao, Zhichao
2020-01-03 3:04 ` [PATCH 01/13] SecurityPkg/Tcg2PpVerndorLib: Add two Ex function to handle PPdata Gao, Zhichao
2020-01-03 3:04 ` [PATCH 02/13] SecurityPkg/Tcg2PpVendorLib: Add implementation of new Ex function Gao, Zhichao
2020-01-03 3:04 ` [PATCH 03/13] SecurityPkg/Tcg2PhysicalPresenceLib: Use the " Gao, Zhichao
2020-01-03 3:04 ` [PATCH 04/13] SecurityPkg/SmmTcg2PhysicalPresenceLib: " Gao, Zhichao
2020-01-03 3:04 ` [PATCH 05/13] SecurityPkg/dec: Add a pcd for user response wait time Gao, Zhichao
2020-01-03 3:04 ` [PATCH 06/13] OvmfPkg/Tcg2PhysicalPresenceLib: Use " Gao, Zhichao
2020-01-03 14:21 ` [edk2-devel] " Laszlo Ersek
2020-01-15 8:03 ` Gao, Zhichao
2020-01-19 7:03 ` Gao, Zhichao
2020-01-20 8:06 ` Laszlo Ersek [this message]
2020-01-03 3:04 ` [PATCH 07/13] SecurityPkg/Tcg2PhysicalPresenceLib: Use Pcd for user resp " Gao, Zhichao
2020-01-03 3:04 ` [PATCH 08/13] SecurityPkg/TcgPyhsicalPresenceLib: " Gao, Zhichao
2020-01-03 3:04 ` [PATCH 09/13] SecurityPkg/Tcg2PhysicalPresenceData.h: Add FunctionIndex for PPdata Gao, Zhichao
2020-01-03 3:04 ` [PATCH 10/13] SecurityPkg/Tcg2PhysicalPresenceLib: Extend the submit preOS func Gao, Zhichao
2020-01-03 3:04 ` [PATCH 11/13] SecurityPkg: Move the Tcg2ConfigNvData.h to Include folder Gao, Zhichao
2020-01-03 3:04 ` [PATCH 12/13] SecurityPkg/TcgPhysicalPresenceLib: Replace the ASSERT with error code Gao, Zhichao
2020-01-03 3:04 ` [PATCH 13/13] SecurityPkg/TcgPhysicalPresenceLib: Fix the operation of 11 Gao, Zhichao
2020-01-03 3:09 ` [PATCH 00/13] Extend and fix the TCG/TCG2 Physical Presence Interface Yao, Jiewen
2020-01-03 5:07 ` Gao, Zhichao
2020-01-03 5:30 ` Yao, Jiewen
2020-01-09 9:05 ` Gao, Zhichao
2020-01-09 9:22 ` Yao, Jiewen
[not found] ` <15E649625DE7E06B.2038@groups.io>
2020-01-03 5:59 ` [edk2-devel] " Yao, Jiewen
2020-01-07 8:05 ` Gao, Zhichao
2020-01-07 8:31 ` Yao, Jiewen
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-list 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=e51fc56f-3957-594f-d378-cbf226c18e8f@redhat.com \
--to=devel@edk2.groups.io \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox