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
> Cc: 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]
> Sent: Wednesday, December 05, 2012 8:50 AM
> To: edk2-devel@lists.sourceforge.net
> Cc: 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
> Cc: 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
> Cc: 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 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
> 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
