Jaben -- For the record, I think that continuing to add meta-build information to the .inf files is counter-productive. As a company that has written tools that conform to the grammar, these extensions to an .ini style file format are becoming more and more arcane to parse and process. Some comments are important, others are not. Some apply to statements that come after, others to statements on the same line. Files that once contains only build information (.uni) now have meta-build information.
Why not just add an xml-formatted extension to [ExtraFiles] and put these meta-build rules there. Yes, I know that XML existed in the EDK2 past and was rejected, mostly tied to ANT. Moving the meta-build information to a separate files allows those who are working with build systems to focus on these and those on meta-tools to focus on the extensions. Glancing ahead to the publicly released "Intel" User Extensions found in Firmware Engine, I would say that it appears that even Intel is finding the.ini style extensions somewhat cumbersome (for ACPI and I2C, for example), as are the PCD documentation extensions for .uni. For what it's worth, XML or JSON would handle these better. Tim -----Original Message----- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Carsey, Jaben Sent: Friday, June 10, 2016 4:04 PM To: edk2-devel@lists.01.org Cc: Carsey, Jaben <jaben.car...@intel.com> Subject: [edk2] propose 3 new UserExtensions in the INF specification All, I would like to propose 3 new UserExtensions in the INF specification. These would be optional sections that can be used to convey additional information about the module. This additional meta data is not expected to be used by the build. This is used by additional tools to help verify DSC functionality and completeness. Modules that will not function based on the contents of the flash image could for example be easily identified. Please respond with comments/objections/suggestions by next Friday June 17th. 1) BY_START / TO_START interaction Currently the Protocols that are produced or consumed by the driver are marked as such in the INF file [Protocols] section, but there is no information on the interactions between these protocols. This extension would allow the conveying of complex interactions to fully describe the meaning behind the TO_START and BY_START tags in the [Protocols] section. The syntax for this section is proposed as: [UserExtensions.TianoCore."ByStartExpressions"] <BY_START Protocol Id> "|" <Expression> Where Expression uses Protocols marked TO_START, PCDs from the [Pcd] section of this INF file, and standard operators per the EDKII Expression Syntax document. Each entry evaluates to TRUE or FALSE and if any expression evaluates to TRUE, then that Protocol will be produced in the DriverBinding Start(). Here is a valid example for a file system driver. The additional information that is conveyed here is that BlockIo and DiskIo are both required, but only one of UnicodeCollation and UnicodeCollation2 are required. Otherwise, the meta data requires both UC and UC2 for DriverBinding Start() to be successful. [Protocols] gEfiDiskIoProtocolGuid ## TO_START gEfiBlockIoProtocolGuid ## TO_START gEfiSimpleFileSystemProtocolGuid ## BY_START gEfiUnicodeCollationProtocolGuid ## TO_START gEfiUnicodeCollation2ProtocolGuid ## TO_START [UserExtensions.TianoCore."ByStartExpressions"] gEfiSimpleFileSystemProtocolGuid | gEfiBlockIoProtocolGuid AND gEfiDiskIoProtocolGuid AND (gEfiUnicodeCollationProtocolGuid OR gEfiUnicodeCollation2ProtocolGuid) 2) SOMETIMES_CONSUMES additional information. Currently Protocols/PPI/GUIDs are marked as UNDEFINED or SOMETIMES_CONSUMES with no way to know whether these will be consumed (thus required). This section would have information to define which would be consumed based on other data. The syntax for this section is proposed as: [UserExtensions.TianoCore."ConsumesExpressions"] <Expression> Where Expression uses items marked UNDEFINED or SOMETIMES_CONSUMES, PCDs from the [Pcd] section of this INF file, and standard operators per the EDKII Expression Syntax document. Each entry is evaluated individually as a Boolean and if any one evaluate to FALSE, then the module will not function due to missing dependencies. Here is an example. The additional information that is conveyed here is that one of Performance and PerformanceEx is required, but not both. [Guids] gPerformanceProtocolGuid ## SOMETIMES_CONSUMES gPerformanceExProtocolGuid ## SOMETIMES_CONSUMES [UserExtensions.TianoCore."ConsumesExpressions"] gPerformanceProtocolGuid OR gPerformanceExProtocolGuid 3) SOMETIMES_PRODUCES additional information. Currently Protocols/PPI/GUIDs are marked as SOMETIMES_PRODUCES with no way to know when these will be produced. This section would have information to define which would be produced based on other data. The syntax for this section is proposed as: [UserExtensions.TianoCore."ProducesExpressions"] <PRODUCES Id> "|" <Expression> Where Expression uses items marked SOMETIMES_PRODUCES, PCDs from the [Pcd] section of this INF file, and standard operators per the EDKII Expression Syntax document. Each entry evaluates to TRUE or FALSE and if any expression evaluates to TRUE, then that item will be produced. Here is an example. The additional information that is conveyed here is that one of gEfiDiskInfoIdeInterfaceGuid is produced if gEfiDiskInfoProtocolGuid is present (or produced). [Guids] gEfiDiskInfoIdeInterfaceGuid ## SOMETIMES_PRODUCES [Protocols] gEfiDiskInfoProtocolGuid ## BY_START [UserExtensions.TianoCore."ProducesExpressions"] gEfiDiskInfoIdeInterfaceGuid | gEfiDiskInfoProtocolGuid _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
