public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Tim Lewis <tim.lewis@insyde.com>
To: Leif Lindholm <leif.lindholm@linaro.org>,
	Laszlo Ersek <lersek@redhat.com>
Cc: "michael.d.kinney@intel.com" <michael.d.kinney@intel.com>,
	Jordan Justen <jordan.l.justen@intel.com>,
	"edk2-devel@ml01.01.org" <edk2-devel@ml01.01.org>,
	Andrew Fish <afish@apple.com>
Subject: Re: [PATCH] add top-level .gitattributes file, dealing with .depex
Date: Fri, 29 Jul 2016 17:12:49 +0000	[thread overview]
Message-ID: <7236196A5DF6C040855A6D96F556A53F3D487A@msmail.insydesw.com.tw> (raw)
In-Reply-To: <20160729164433.GO31760@bivouac.eciton.net>

It appears that this file is not actually used. It is only referenced in the [Rule.Common.UEFI_DRIVER.NATIVE_BINARY] rule in PlatformPkg.fdf. A little further research shows that an alternate method was used for the actual GOP binary (see below). A grep of the entire tree shows that no one uses this rule NATIVE_BINARY. So it looks like it can just be cut out.

BTW, the downside of the method used for the binary version of the GOP driver, is that those drivers cannot use PCDs, since the PCD database is created based on references in the .inf. GOP works because it is pure UEFI and (therefore) doesn't use PCDs.

Tim

FILE DRIVER = FF0C8745-3270-4439-B74F-3E45F8C77064 {
  SECTION DXE_DEPEX_EXP = {gPlatformGOPPolicyGuid}
  SECTION PE32 = Vlv2MiscBinariesPkg/GOP/7.2.1011/RELEASE_VS2008x86/$(DXE_ARCHITECTURE)/IntelGopDriver.efi
  SECTION UI = "IntelGopDriver"
}

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Leif Lindholm
Sent: Friday, July 29, 2016 9:45 AM
To: Laszlo Ersek <lersek@redhat.com>
Cc: michael.d.kinney@intel.com; Jordan Justen <jordan.l.justen@intel.com>; edk2-devel@ml01.01.org; Andrew Fish <afish@apple.com>
Subject: Re: [edk2] [PATCH] add top-level .gitattributes file, dealing with .depex

On Thu, Jul 07, 2016 at 05:03:13PM +0200, Laszlo Ersek wrote:
> On 07/07/16 16:24, Leif Lindholm wrote:
> > Git tends to see .depex files as text, causing hideous patches being 
> > generated (and breaking PatchCheck.py).
> > 
> > Add a .gitattributes file instructing git to treat them as binary.
> > 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
> > ---
> >  .gitattributes | 1 +
> >  1 file changed, 1 insertion(+)
> >  create mode 100644 .gitattributes
> > 
> > diff --git a/.gitattributes b/.gitattributes new file mode 100644 
> > index 0000000..2d8a45b
> > --- /dev/null
> > +++ b/.gitattributes
> > @@ -0,0 +1 @@
> > +*.depex binary
> > 
> 
> What generates .depex files? I've never seen any.
> 
> Also, unless you add .depex files with "git add" to the set of tracked 
> files, no patches / diffs should cover them. What am I missing? :)
> 
> ... Hm, after
> 
> $ find . -iname "*.depex"
> 
> I see .depex files in Build/ (which should be ignored altogether), and
> 
> ./Vlv2TbltDevicePkg/IntelGopDepex/IntelGopDriver.depex
> 
> Why does that file exist in the tree? Let me see... git log says nothing relevant (the file dates back to commit 3cbfba02fef9, "Upload BSD-licensed Vlv2TbltDevicePkg and Vlv2DeviceRefCodePkg to").
> 
> Grepping the tree for the filename itself leads to:
> 
> Vlv2TbltDevicePkg/PlatformPkg.fdf:    DXE_DEPEX DXE_DEPEX Optional      $(WORKSPACE)/$(PLATFORM_PACKAGE)/IntelGopDepex/IntelGopDriver.depex
> Vlv2TbltDevicePkg/PlatformPkgGcc.fdf:    DXE_DEPEX DXE_DEPEX Optional      $(WORKSPACE)/$(PLATFORM_PACKAGE)/IntelGopDepex/IntelGopDriver.depex
> 
> Do these rules exist to override the DEPEX sections of binary-only modules? If so: that's horrible.
> 
> Anyway, given that edk2 contains at least one .depex file, and your patch is correct according to <https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes>:
> 
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>

Thanks!

I had hoped for comments from someone else on cc, since we don't have any Maintainers.txt entry for the top level directory :)

But if I don't hear anything before Monday, I'll push it then.

Regards,

Leif

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


  reply	other threads:[~2016-07-29 17:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1467901459-18840-1-git-send-email-leif.lindholm@linaro.org>
     [not found] ` <e43953db-6653-4f16-d7f4-36702a5ea8c3@redhat.com>
2016-07-29 16:44   ` [PATCH] add top-level .gitattributes file, dealing with .depex Leif Lindholm
2016-07-29 17:12     ` Tim Lewis [this message]
2016-07-30 18:33       ` Leif Lindholm
2016-07-31 22:58         ` Jordan Justen
2016-07-31 23:52           ` Kinney, Michael D
2016-08-01  7:03             ` Jordan Justen
2016-08-01  8:19               ` Leif Lindholm
2016-08-01 16:56                 ` Kinney, Michael D
2016-08-01 17:03               ` Tim Lewis
2016-08-02  1:59                 ` 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=7236196A5DF6C040855A6D96F556A53F3D487A@msmail.insydesw.com.tw \
    --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