Another note on this, GenerateReport.py does not comprehend the 'Binary only'
status of any modules, and will produce erroneous depex statements in the build
report based on the contents of the [Depex] sections. Consistency here would be
nice.
From: Andrew Fish [mailto:af...@apple.com]
Sent: Wednesday, December 05, 2012 9:41 PM
To: Gao, Liming
Cc: edk2-devel@lists.sourceforge.net;
edk2-buildtools-de...@lists.sourceforge.net
Subject: Re: [edk2-buildtools] [edk2] binary-only modules and [depex] sections
On Dec 5, 2012, at 6:52 PM, Gao, Liming wrote:
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.
I don't understand this point? Given it is my platform and some one hands me a
binary depex they still have to explain to me what protocols need to be
produced for the driver to dispatch. So I have to understand the depex at a
GuidCName level to make sure there is code in the platform that produces the
protocols needed to satisfy the depex.
I think you guys focused a little too much on the worse possible thing that
could happen, vs what steps need to be taken to make it work in the real world.
The platform has to produce the protocols, so they need to be described in some
other form than a binary blob of depex. If the GuidCName are already in edk2
then there should not be a GuidCName conflict, if the GuidCName is new I still
have to write code to produce the GuidCName and thus I need to define the
GuidCName properly to publish the protocol to satisfy the dependency. Thus it
seems to me the tool "helping me" by not allowing GuidCName is really just
making it harder to work with an less flexible.
Thanks,
Andrew
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<mailto:edk2-devel@lists.sourceforge.net>;
edk2-buildtools-de...@lists.sourceforge.net<mailto: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
