public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
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


  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