Andrew:
Another risk is that GuidCName may have the different value in pre-build
workspace and current workspace. If so, the binary EFI image and its Depex
doesn't match, which may cause unexpected issue.
Thanks
Liming
From: Andrew Fish [mailto:af...@apple.com]
Sent: Thursday, December 06, 2012 4:32 AM
To: Hauch, Larry
Cc: edk2-devel@lists.sourceforge.net;
edk2-buildtools-de...@lists.sourceforge.net
Subject: Re: [edk2-buildtools] [edk2] binary-only modules and [depex] sections
Larry,
If I was receiving a binary from some vendor and an depex I would rather get
the Depex in text form so I could modify it if needed. For example what if I
only want to load the binary in certain circumstances? I might want to AND in a
platform specific protocol that means load the binary driver.
I understand the basic issue: It is possible to inherit depex expressions from
libraries so the INF file that built the binary driver does not contain the
full depex. The build logs contain the correct information so this data could
be sent in place of the binary depex file.
Thanks,
Andrew Fish
On Dec 5, 2012, at 12:03 PM, Hauch, Larry wrote:
Hi Tim,
You are correct in what the INF specification states. Unfortunately, this line
was added accidentally.
As a future enhancement, we had planned on adding the depex statements "in
comments" underneath the [Depex] section in the "As Built" INF file generated
by the build system. We have not implemented the depex content in comments
during "As Built" INF file generation yet.
So, for now, the paragraph should be remove from the INF specification.
I apologize for the confusion this may have caused.
Hi Justin,
The reason the build system does not re-generate the depex from [Depex] content
in a Binary INF file is that it is assumed that the efi file was linked with
specific library instances which may also have depex statements, so modifying
any depex statements after the fact could result in an invalid driver that
would be almost impossible to debug. It would require the binary module
provider to ensure that every depex statement from every library instance
linked against the module be AND'd with the depex statements from the driver -
not a simple task.
By listing the efi and depex files in the [Binaries] section, it was assumed
that the binary depex was created at the same time that the efi module was
linked (by the build system) and therefore included all required depex
statements.
Cheers,
Larry
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, December 05, 2012 8:59 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Cc:
edk2-buildtools-de...@lists.sourceforge.net<mailto:edk2-buildtools-de...@lists.sourceforge.net>
Subject: Re: [edk2] [edk2-buildtools] binary-only modules and [depex] sections
Larry -
I will go further: The current .inf specification, section 3.14, says: "For a
binary INF file, the [Depex] section will contain the full dependency
expression, including the dependencies from the linked libraries." There is
nothing in the spec which says that [Depex] is illegal in this case.
Tim
From: justin_johns...@dell.com<mailto:justin_johns...@dell.com>
[mailto:justin_johns...@dell.com]<mailto:[mailto:justin_johns...@dell.com]>
Sent: Wednesday, December 05, 2012 8:50 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Cc:
edk2-buildtools-de...@lists.sourceforge.net<mailto:edk2-buildtools-de...@lists.sourceforge.net>
Subject: Re: [edk2] [edk2-buildtools] binary-only modules and [depex] sections
Hi Larry,
Thanks for your detailed response. What you say correctly describes the current
behavior. I'm asking why that behavior is desired, and suggesting that it is
not desired. I believe there may be situations where you want a binary
distributed driver, but a human-readable dependency expression.
Removing the python code I mentioned in my original message (ignoring [Depex]
sections when only [Binaries] sections are present) allows a dependency section
to be generated on the fly. An appropriate FDF statement will include the
correct section.
- Justin
From: Hauch, Larry [mailto:larry.ha...@intel.com]
Sent: Tuesday, December 04, 2012 3:40 PM
To: Andrew Fish;
edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Cc:
edk2-buildtools-de...@lists.sourceforge.net<mailto:edk2-buildtools-de...@lists.sourceforge.net>
Subject: Re: [edk2-buildtools] [edk2] binary-only modules and [depex] sections
Hi Justin,
The EDK II tools should support a binary INF file that has both the drive and
the compiled depex file in the [Binaries] section.
Using the PcAtChipsetPkg/PcatRealTimeClockRuntimeDex.inf as an example, a valid
INF for the binary would looks like:
[Defines]
INF_VERSION = 0x00010016
BASE_NAME = PcRtc
FILE_GUID = 378D7B65-8DA9-4773-B6E4-A47826A833E1
MODULE_TYPE = DXE_RUNTIME_DRIVER
VERSION_STRING = 1.0
[Binaries.IA32]
PE32|Ia32/PcRtc.efi
DXE_DEPEX|Ia32/PcRtc.depex
The tools do not support building a source depex file without building the
module from source.
The tools will ignore the sources section if a [Binaries] section does exist;
so the following is not valid:
[Defines]
INF_VERSION = 0x00010016
BASE_NAME = PcRtc
FILE_GUID = 378D7B65-8DA9-4773-B6E4-A47826A833E1
MODULE_TYPE = DXE_RUNTIME_DRIVER
VERSION_STRING = 1.0
DPX_SOURCE = myDepexSrc.depex
[Binaries.IA32]
PE32|Ia32/PcRtc.efi
Nor can you specify a [Depex] section in an INF file that has the binary efi
file. The following is also not valid
[Defines]
INF_VERSION = 0x00010016
BASE_NAME = PcRtc
FILE_GUID = 378D7B65-8DA9-4773-B6E4-A47826A833E1
MODULE_TYPE = DXE_RUNTIME_DRIVER
VERSION_STRING = 1.0
[Binaries.IA32]
PE32|Ia32/PcRtc.efi
[Depex]
gEfiVariableArchProtocolGuid AND gEfiVariableWriteArchProtocolGuid
Cheers,
Larry
From: Andrew Fish [mailto:af...@apple.com]
Sent: Monday, December 03, 2012 3:25 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Cc:
edk2-buildtools-de...@lists.sourceforge.net<mailto:edk2-buildtools-de...@lists.sourceforge.net>
Subject: Re: [edk2-buildtools] [edk2] binary-only modules and [depex] sections
Sounds like a bug to me.
Thanks,
Andrew
On Dec 3, 2012, at 3:00 PM,
justin_johns...@dell.com<mailto:justin_johns...@dell.com> wrote:
Hi all,
I have some binary-only drivers with dependency expressions that are not being
processed. These drivers are not UEFI model drivers.
I see in WorkspaceDatabase.py:
# If the module has only Binaries and no Sources, then ignore [Depex]
if self.Sources == None or self.Sources == []:
if self.Binaries != None and self.Binaries != []:
return self._Depex
The intent being obvious from the comment (comes from SVN revision 2135 of
edk2-buildtools repo). My question is, why are the [Depex] sections ignored
from INFs with only binaries? I don't see in any of the EDKII documentation
where this is stated. Is this a behavior that could be changed?
--
Justin Johnson
Platform Software Engineer
Dell, Inc.
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d_______________________________________________
edk2-buildtools-devel mailing list
edk2-buildtools-de...@lists.sourceforge.net<mailto:edk2-buildtools-de...@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
