public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "David Woodhouse" <dwmw2@infradead.org>
To: "Ni, Ray" <ray.ni@intel.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>,
	 "lersek@redhat.com" <lersek@redhat.com>
Subject: Re: [edk2-devel] [PATCH 6/7] MdeModulePkg/UefiBootManagerLib: describe VirtIO devices correctly
Date: Tue, 25 Jun 2019 12:27:27 +0100	[thread overview]
Message-ID: <4f76f3ec330605027c933c616f4d385b417913b6.camel@infradead.org> (raw)
In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5C1EF4F5@SHSMSX104.ccr.corp.intel.com>

[-- Attachment #1: Type: text/plain, Size: 2782 bytes --]

On Tue, 2019-06-25 at 09:56 +0000, Ni, Ray wrote:
> David,
> Thanks for pointing that patch.
> 
> Now I understand it.
> Normally it's the CSM16 code that builds the boot descriptions for legacy boot options
> and LegacyBootManagerLib consumes that boot descriptions.
> 
> But in your case, LegacyBios driver builds the boot descriptions for VirtIo devices and
> LegacyBootManagerLib consumes that boot descriptions.
> 
> The flow is like below: (I understand there is no VirtIoBootOptionDescriptionHandler() in
> your current patch. But I think we could write such handler and register it through
> EfiBootManagerRegisterBootDescriptionHandler() API)
> 
>   *module*          *UefiBootManagerLib*
> LegacyBios -> GetBootOptionDescription() -> VirtIoBootOptionDescriptionHandler()
> BdsDxe -> GetBootOptionDescription() -> VirtIoBootOptionDescriptionHandler()
> 
> So instead of routing to *UefiBootManagerLib* GetBootOptionDescription(),
> why not you directly call VirtIoBootOptionDescriptionHandler() from LegacyBios?
> 
> I understand from functionality perspective, it makes no difference.
> But I care about that because it avoids LegacyBios unnecessarily depends on
> *UefiBootManagerLib*.
> 
> What do you think?

Forget VirtIO, look only at the previous two patches.

    MdeModulePkg/UefiBootManagerLib: export EfiBootManagerGetBootDescription()
    OvmfPkg/LegacyBiosDxe: Use EfiBootManagerGetBootDescription()

Their commit messages (attempt to) set this out fairly clearly.

In BmGetBootDescription() we already have a whole pile of special cases
for things including NVMe, USB, etc. to get descriptive strings that
match a given BlockIo handle.

It's bad enough that that functionality exists in that form already,
rather than being provided in a clean and generic fashion by the block
device driver itself somehow.

I absolutely did not want to reproduce it all, just to get meaningful
strings for the Legacy boot targets from the same block devices. Hence
a tweaking, renaming and exporting the existing BmGetBootDescription()
function so I can use it from LegacyBbs code.

Adding another special case for VirtIO alongside all the other special
cases that were already in BmGetBootDescription (now called
EfiBootManagerGetBootDescription()) is not really the important part
here.


Is there a particular problem with having LegacyBios depend on
UefiBootManagerLib? The code in BmDescription.c is actually fairly
standalone — should we move it out into its *own* library so that it
can be used from both places? That seems like overkill to me, when our
long term plan really ought to be to kill it with fire and let block
device drivers provide their own descriptive strings through a standard
protocol.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

  reply	other threads:[~2019-06-25 11:27 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-21 22:31 [PATCH 1/7] OvmfPkg/LegacyBios: set NumberBbsEntries to the size of BbsTable David Woodhouse
2019-06-21 22:31 ` [PATCH 2/7] OvmfPkg/LegacyBbs: Add boot entries for VirtIO and NVME devices David Woodhouse
2019-06-24 22:46   ` [edk2-devel] " Laszlo Ersek
2019-06-21 22:31 ` [PATCH 3/7] OvmfPkg: Don't build in QemuVideoDxe when we have CSM David Woodhouse
2019-06-21 22:31 ` [PATCH 4/7] MdeModulePkg/UefiBootManagerLib: export EfiBootManagerGetBootDescription() David Woodhouse
2019-06-24 22:36   ` [edk2-devel] " Laszlo Ersek
2019-06-25  2:00   ` Ni, Ray
2019-06-25  8:00     ` David Woodhouse
2019-06-21 22:31 ` [PATCH 5/7] OvmfPkg/LegacyBiosDxe: Use EfiBootManagerGetBootDescription() David Woodhouse
2019-06-24 23:03   ` [edk2-devel] " Laszlo Ersek
2019-06-21 22:31 ` [PATCH 6/7] MdeModulePkg/UefiBootManagerLib: describe VirtIO devices correctly David Woodhouse
2019-06-24 23:16   ` [edk2-devel] " Laszlo Ersek
2019-06-25  1:44     ` Ni, Ray
2019-06-25  7:40       ` David Woodhouse
2019-06-25  8:06         ` Ni, Ray
2019-06-25  8:28           ` David Woodhouse
2019-06-25  9:15             ` Ni, Ray
2019-06-25  9:28               ` David Woodhouse
2019-06-25  9:56                 ` Ni, Ray
2019-06-25 11:27                   ` David Woodhouse [this message]
2019-06-21 22:31 ` [PATCH 7/7] OvmfPkg: don't assign PCI BARs above 4GiB when CSM enabled David Woodhouse
2019-06-24 23:50   ` [edk2-devel] " Laszlo Ersek
2019-06-25 12:07     ` David Woodhouse

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=4f76f3ec330605027c933c616f4d385b417913b6.camel@infradead.org \
    --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