From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) by mx.groups.io with SMTP id smtpd.web11.2178.1572999643734603514 for ; Tue, 05 Nov 2019 16:20:44 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=RD7gPXik; spf=pass (domain: apple.com, ip: 17.171.2.72, mailfrom: afish@apple.com) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id xA60HkiR063678; Tue, 5 Nov 2019 16:20:42 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=wfifTQ7CLJP94xiKaeXdG06F5p6YqXNq9Ad5kF2YZ3M=; b=RD7gPXikNt3eFgkYSmweOFH+D+vvFrP+R21D7uPlg8iXDvIDTXh8kGeDqBzNfQs6c/O9 qgCh91+MVx3RyeVLZodoHHNjbXR8Z/w/ajlTyhSOE0Zxrggm1f50C2W3DN0PZ1CLYGn8 LFYXcpbS8EnN5y76PA8g/LpvkaECzEzqt4+T1svmBrKQhMiA2VJT++f9tu4kA/cTfFme I2b1pDWXM0Y73/LC6HaCrybE0C9Qmrx7hNn/uYV3vlrzrOcQozA3CgL7xAApjIyJkSfW OdXEKmdvnSpKQ/yA6XGiUdu2+H6Lw21vMANUCQrz0c9Z/GJ4V0dgCs5dYiZIPP6AMtif gg== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2w18swerdj-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 05 Nov 2019 16:20:42 -0800 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q0I001MXUACWM30@ma1-mtap-s02.corp.apple.com>; Tue, 05 Nov 2019 16:20:39 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q0I00A00U0GJE00@nwk-mmpp-sz12.apple.com>; Tue, 05 Nov 2019 16:20:37 -0800 (PST) X-Va-A: X-Va-T-CD: dd832fa7197a7045cc604b66a4d528ed X-Va-E-CD: be490e393b9a0fc46442780b7330e634 X-Va-R-CD: 080c83ebb59fdc40182a21f863857514 X-Va-CD: 0 X-Va-ID: cbaa3041-6626-4a32-94a1-0902b64aa84e X-V-A: X-V-T-CD: dd832fa7197a7045cc604b66a4d528ed X-V-E-CD: be490e393b9a0fc46442780b7330e634 X-V-R-CD: 080c83ebb59fdc40182a21f863857514 X-V-CD: 0 X-V-ID: 1f38348c-460e-4528-9a53-cc175b921299 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-05_09:,, signatures=0 Received: from [17.235.77.209] (unknown [17.235.77.209]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q0I00E0PUABE270@nwk-mmpp-sz12.apple.com>; Tue, 05 Nov 2019 16:20:37 -0800 (PST) Sender: afish@apple.com From: "Andrew Fish" Message-id: <1EE5C030-448D-4C91-A06E-2455ABF55887@apple.com> MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration Date: Tue, 05 Nov 2019 18:20:35 -0600 In-reply-to: <27337.1572995980617823578@groups.io> Cc: Laszlo Ersek To: devel@edk2.groups.io, jbrasen@nvidia.com References: <72ce1d71-2a65-a6c0-1dd8-7628429c5a3c@redhat.com> <27337.1572995980617823578@groups.io> X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-05_09:,, signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_0B0943D0-A16E-41F5-B194-E5BF6BE46101" --Apple-Mail=_0B0943D0-A16E-41F5-B194-E5BF6BE46101 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 5, 2019, at 5:19 PM, Jeff Brasen wrote: >=20 > Wouldn't having a variable that we create and delete on every boot put u= nnecessary stress on the SPI-NOR that the variable store lives on? > What about the alternative approach where we allow the platform code to = modify the attributes of the auto created variable to disable it with hidde= n/!active but still match for detection purposes so that it doesn't delete = and recreate the modified variable each boot? That way all the logic on wha= t to disable can still be in the platform code and all the existing logic i= n the boot manager can stay basically the same? >=20 What changes every boot that forces the variable to need to get modified?= =20 I would assume the NOR driver is smart enough to not update a variable tha= t is not changing.=20 The custom BDS could could only create the variable for this device if it = does not exist.=20 Thanks, Andrew Fish >=20 > Thanks, >=20 > Jeff > >=20 >=20 --Apple-Mail=_0B0943D0-A16E-41F5-B194-E5BF6BE46101 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Nov 5,= 2019, at 5:19 PM, Jeff Brasen <jbrasen@nvidia.com> wrote:

Wouldn't having a variable that = we create and delete on every boot put unnecessary stress on the SPI-NOR th= at the variable store lives on?
What about the alternative ap= proach where we allow the platform code to modify the attributes of the aut= o created variable to disable it with hidden/!active but still match for de= tection purposes so that it doesn't delete and recreate the modified variab= le each boot? That way all the logic on what to disable can still be in the= platform code and all the existing logic in the boot manager can stay basi= cally the same?

What changes every boot that for= ces the variable to need to get modified? 

I would assume the NOR driver is smart enough to not update a vari= able that is not changing. 

The cu= stom BDS could could only create the variable for this device if it does no= t exist. 

Thanks,

Andrew Fish
<= div class=3D"">


Thanks,

Jeff 


--Apple-Mail=_0B0943D0-A16E-41F5-B194-E5BF6BE46101--