From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.81]) by mx.groups.io with SMTP id smtpd.web11.7760.1579507597494725189 for ; Mon, 20 Jan 2020 00:06:37 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=MpYlvuq9; spf=pass (domain: redhat.com, ip: 207.211.31.81, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579507596; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4T5/0yUV1WDoXsuwS6KezICms19NnvB3wFQVO/zXmiw=; b=MpYlvuq92g2Qqd1wJiBsBE7je7FMugA6W855I9xowuY8akd2GOr7+au2bUB/82IGXk3VIO uf/+PBS159Ba8ufEglJAdhEMKDlwOvm/YGmwnFFTuJYPu9styVeHve9uXdlUYILz8YwRi+ MWeswZfctPLP+r/uCo6TWUksAFf9SJU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-315-s5iwJTXsO7iqwugQG5py0A-1; Mon, 20 Jan 2020 03:06:35 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6E9028017CC; Mon, 20 Jan 2020 08:06:33 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-50.ams2.redhat.com [10.36.117.50]) by smtp.corp.redhat.com (Postfix) with ESMTP id F17551BC6D; Mon, 20 Jan 2020 08:06:28 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH 06/13] OvmfPkg/Tcg2PhysicalPresenceLib: Use pcd for user response wait time To: "Gao, Zhichao" , "devel@edk2.groups.io" Cc: "Yao, Jiewen" , "Wang, Jian J" , "Zhang, Chao B" , "Justen, Jordan L" , Ard Biesheuvel , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , Stefan Berger References: <20200103030428.28176-1-zhichao.gao@intel.com> <20200103030428.28176-7-zhichao.gao@intel.com> From: "Laszlo Ersek" Message-ID: Date: Mon, 20 Jan 2020 09:06:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-MC-Unique: s5iwJTXsO7iqwugQG5py0A-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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