v4.0.1

What's Changed

• ci.yaml: add PrEval entry @Javagedes (#122)
  
  Change Details

    ## Description

  Adds a PrEval entry to all ci.yaml files to enable the new PrEval Policy 5.

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  N/A

  Integration Instructions

  N/A

    </blockquote>
    <hr>
  </details>
  

🐛 Bug Fixes

• DfciV1SupportLibNull: Assign actual library class @makubacki (#127)
  
  Change Details

    ## Description

  The library class is currently DfciSupportLib in the INF file. This
  name is not used anywhere else including consuming code and
  documenation. Therefore, some packages have used the library class
  name used elsewhere (DfciV1SupportLibNull) but that may give a
  warning since the library class does not match the INF.

  This changes updates the INF so the name is consistent.

  There's also minor other cleanup:

  • Fix BASE_NAME so it accurately identifies the instance

  • Move MdePkg.dec to the beginning of the package order to allow
    more specific definitions to override generic ones in MdePkg.

  • Remove empty sections cluttering the file.

  • Impacts functionality?

    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...

  • Impacts security?

    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...

  • Breaking change?

    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...

  • Includes tests?

    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...

  • Includes documentation?

    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  DfciPkg build and build of packages dependent on the library class.

  Integration Instructions

  If DfciSupportLib was being used before to reference this library class instance
  in a package, update it to DfciV1SupportLib.
  

  
  

  ---

  
  

Full Changelog: v4.0.0...v4.0.1