public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Gao, Liming" <liming.gao@intel.com>
To: Laszlo Ersek <lersek@redhat.com>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Cc: "Justen, Jordan L" <jordan.l.justen@intel.com>
Subject: Re: [PATCH staging][BaseToolsOpt 0/4] Enable multiple driver combination
Date: Sat, 10 Jun 2017 13:49:50 +0000	[thread overview]
Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14D747A82@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <b02232e8-6aa2-ec67-05f1-2554bd2cf616@redhat.com>

Laszlo:
  I really create one example to show the combined driver usage. I don't plan to push this change into OvmfPkg master. If this patch brings confuse to you, I will create one SamplePkg to include it. 
  And, I don't want to limit this feature into the specific driver type. I would like platform developer make the decision. If user combines some PEIM or some DXE drivers in its Platform.dsc, it can specify the combined driver in APRIOR list to make sure it be dispatched correctly.

Thanks
Liming
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Friday, June 9, 2017 5:03 AM
> To: Gao, Liming <liming.gao@intel.com>; edk2-devel@lists.01.org
> Cc: Justen, Jordan L <jordan.l.justen@intel.com>
> Subject: Re: [edk2] [PATCH staging][BaseToolsOpt 0/4] Enable multiple driver combination
> 
> Hi Liming,
> 
> (CC Jordan)
> 
> On 06/08/17 08:55, Liming Gao wrote:
> > Combine more drivers into the single one can reduce the image size and
> > compile link time. This patch adds this support in BaseTools.
> >
> > Liming Gao (4):
> >   BaseTools: Merge multiple drivers into one for size and link
> >     performance
> >   OvmfPkg: Update QemuVideo and VirtioGpuDxe to use NULL as
> >     DriverBindingHandle
> >   OvmfPkg: Combine QemuVideoDxe and VirtioGpuDxe to one driver
> >   Update Readme.MD to include multiple driver combination.
> >
> >  BaseTools/Source/Python/AutoGen/GenC.py | 24 +++++++++++++++++++-----
> >  OvmfPkg/OvmfPkgIa32X64.dsc              |  6 ++++--
> >  OvmfPkg/OvmfPkgIa32X64.fdf              |  2 +-
> >  OvmfPkg/QemuVideoDxe/Driver.c           |  2 +-
> >  OvmfPkg/VirtioGpuDxe/DriverBinding.c    |  2 +-
> >  Readme.MD                               |  1 +
> >  6 files changed, 27 insertions(+), 10 deletions(-)
> >
> 
> I don't have a lot of hands-on practice with staging branches, but I
> believe that ultimately such changes are meant to be merged into the
> edk2 master branch. Is that right?
> 
> If that's the case, then I don't think we should do this in OvmfPkg (on
> the master branch). Instead, I think example usage should be shown in:
> 
> - the commit message (it's already there, so that's great),
> 
> - in the DSC specification.
> 
> If you absolutely need an in-tree platform to use this BaseTools
> feature, and you think OvmfPkg is better for this purpose than, say,
> EmulatorPkg or Nt32Pkg, then:
> 
> (1) Please make this dependent on a new build flag (-D), which should
> default to FALSE.
> 
> (2) Please make the same change to all three DSC files under OvmfPkg.
> 
> (3) Please introduce a new FeaturePCD which corresponds to the new build
> flag, and controls the handle value in the entry points of the affected
> drivers.
> 
> In particular I'm asking for (3) because the UEFI Driver Writer's Guide
> (Version 1.01, 03/08/2012) says:
> 
>   6.1.4 Device drivers with one driver binding protocol
> 
>   [...] The driver entry point is responsible for installing the Driver
>   Binding Protocol onto the driver’s image handle. [...]
> 
>   6.1.5 Device drivers with multiple driver binding protocols
> 
>   [...] The first instance of EFI_DRIVER_BINDING_PROTOCOL is installed
>   onto the driver’s image handle, and the additional instances of the
>   Driver Binding Protocol are installed onto newly created driver
>   binding handles. [...]
> 
> So, in order to follow these recommendations,
> - when the drivers are not combined, each driver should stick with its
> non-NULL image handle,
> - when the drivers are combined, one driver should stick with its image
> handle, and the rest should use NULL (based on the feature PCD)
> 
> 
> Regarding the BaseTools feature itself, I think it should be restricted
> to UEFI_DRIVER modules (maybe it is already restricted, but then the
> documentation should say it). I'm suggesting that becasue UEFI_DRIVERs
> are supposed to have identical DEPEXes. With DXE_DRIVER modules for
> example, their DEPEXes could be different, and I couldn't say how those
> should be combined.
> 
> Thanks,
> Laszlo

  reply	other threads:[~2017-06-10 13:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-08  6:55 [PATCH staging][BaseToolsOpt 0/4] Enable multiple driver combination Liming Gao
2017-06-08  6:55 ` [PATCH staging][BaseToolsOpt 1/4] BaseTools: Merge multiple drivers into one for size and link performance Liming Gao
2017-06-08  6:55 ` [PATCH staging][BaseToolsOpt 2/4] OvmfPkg: Update QemuVideo and VirtioGpuDxe to use NULL as DriverBindingHandle Liming Gao
2017-06-08  6:55 ` [PATCH staging][BaseToolsOpt 3/4] OvmfPkg: Combine QemuVideoDxe and VirtioGpuDxe to one driver Liming Gao
2017-06-08  6:55 ` [PATCH staging][BaseToolsOpt 4/4] Update Readme.MD to include multiple driver combination Liming Gao
2017-06-08 21:03 ` [PATCH staging][BaseToolsOpt 0/4] Enable " Laszlo Ersek
2017-06-10 13:49   ` Gao, Liming [this message]
2017-06-12 14:16     ` Laszlo Ersek
2017-06-12 14:48       ` Gao, Liming

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=4A89E2EF3DFEDB4C8BFDE51014F606A14D747A82@shsmsx102.ccr.corp.intel.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