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.1668.1572946434691377492 for ; Tue, 05 Nov 2019 01:33:54 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Ob6Opg/K; 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=1572946434; 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=5oAzmqz1W+mY3k0cuQqEluX7OVlSb1OyEUot9mzGUQk=; b=Ob6Opg/KwHCjDgeQjsI9ga08hAEa7QnxjxQssieHGcaSeyuSM93k1fa0Thh+NDcXi3k0+B lTIClVmeDVILjBuZ1teTavSofrw6v+w3U1mzu3zWPsQv/gBhLSkDrNRnjLD8mlzMpTrgAG N0XncPaLFOL9+dtwG8mF+i3jBp9C1kc= 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-259-kcTzq5IHPs-ovUQth2LyAg-1; Tue, 05 Nov 2019 04:33:50 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 816B9477; Tue, 5 Nov 2019 09:33:48 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-96.ams2.redhat.com [10.36.117.96]) by smtp.corp.redhat.com (Postfix) with ESMTP id B34271001B00; Tue, 5 Nov 2019 09:33:46 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration To: Ashish Singhal , "Ni, Ray" , "devel@edk2.groups.io" , "Wang, Jian J" , "Wu, Hao A" , "Gao, Zhichao" Cc: "Kinney, Michael D" References: <1b91c052-f64c-1dca-98ff-a2777afd7f77@redhat.com> <734D49CCEBEEF84792F5B80ED585239D5C34F98A@SHSMSX104.ccr.corp.intel.com> From: "Laszlo Ersek" Message-ID: <7d8a36b2-a052-1d30-e5e2-72af00d67034@redhat.com> Date: Tue, 5 Nov 2019 10:33:45 +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.84 on 10.5.11.22 X-MC-Unique: kcTzq5IHPs-ovUQth2LyAg-1 X-Mimecast-Spam-Score: 0 Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11/05/19 04:24, Ashish Singhal wrote: > Hi Ray, >=20 > I did not see any example with which one can tell BDS not to > enumerate a boot option. Can you please point me to an example where > a protocol (Block IO, Simple FS or Load File) does not get enumerated > as a boot option? (I'm going to state the same thing that's been said in this thread already, just maybe with a different formulation.) In order for you to end up with a particular auto-generated option in the boot manager, two "kinds" of things are necessary. (1) Producing the protocol instance: (1a) Your PlatformBootManagerLib instance must actively *connect* the device in question to a suitable UEFI driver that follows to the UEFI driver model, such that the UEFI driver produce the LoadFile protocol instance. For example, you could be calling the EfiBootManagerConnectAll() API, from UefiBootManagerLib. (1b) Alternatively, if the device is a platform device, then you might need a DXE driver, built into your platform firmware, that produces LoadFile on top of the device, running (directly or indirectly) in the driver's entry point function. (2) Creating a boot option for the protocol instance: (2a) With the LoadFile protocol instance existing, your PlatformBootManagerLib instance must actively call a UefiBootManagerLib API -- such as EfiBootManagerRefreshAllBootOption() -- that scans the UEFI protocol database for various "bootable" protocols, and auto-generates UEFI Boot#### variables for them (and updates BootOrder too)= . (2b) Alternatively, your PlatformBootManagerLib instance may be auto-setting Boot#### / BootOrder, in response to the LoadFile instance in question, in some different manner. ---- The point is that *all* of the above actions are under your control. If you want to prevent the auto-generation of a particular boot option, then break the dependency chain in any one spot above, and then the option will not be auto-generated. - do not connect the device to a driver in your PlatformBootManagerLib, - or remove the platform DXE driver, if you have that, or: - do not call EfiBootManagerRefreshAllBootOption(), - or stop manually creating Boot#### / BootOrder for the subject LoadFile (if you do that currently). ( I did not point out all this when I first responded to your posting, because I assumed your next question would be: OK, but then what do I call *instead of* EfiBootManagerRefreshAllBootOption()? I do need the auto-generation of boot options, speaking generally, except for this one LoadFile instance. I don't want to rewrite all of EfiBootManagerRefreshAllBootOption() as a platform function, just for the sake of this one exception. Anticipating that counter-argument, I was tempted to suggest a different approach (which we've done in the past): namely, making some lower-level functions in UefiBootManagerLib public, so that PlatformBootManagerLib instances can reuse those utility functions with finer granularity. However, that approach is not extremely far from controlling UefiBootManagerLib by different means, and in this particular case, I couldn't suggest any obvious low-level functions from UefiBootManagerLib, for making public, and to call in place of EfiBootManagerRefreshAllBootOption(). For that, I think quite a bit of refactoring would be necessary too. And so I figured I'd let Ray and others respond first, to your proposal. ) Thanks Laszlo