1. rfc@edk2.groups.io
  2. Messages
   Date   
Re: Proposal to add support for PCIe enumeration protocols in PEI

Abner Chang
 

-----Original Message-----
From: rfc@edk2.groups.io [mailto:rfc@edk2.groups.io] On Behalf Of Ni, Ray
Sent: Thursday, November 11, 2021 9:00 AM
To: rfc@edk2.groups.io; Johnson, Brian (EXL - Bloomington, MN)
<brian.johnson@hpe.com>; Albecki, Mateusz <mateusz.albecki@intel.com>;
Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
Subject: Re: [edk2-rfc] Proposal to add support for PCIe enumeration
protocols in PEI

The CAR size concern caused two additional design requirements:
1. separate FV being loaded after mem is ready
2. pre-scan in pre-mem and full-scan in post-mem

So, I am wondering if pre-mem scan is really needed?
if not, let's just say: one full-scan in post-mem

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Brian J.
Johnson
Sent: Thursday, November 11, 2021 7:22 AM
To: rfc@edk2.groups.io; Albecki, Mateusz <mateusz.albecki@intel.com>;
Chang, Abner <abner.chang@hpe.com>
Subject: Re: [edk2-rfc] Proposal to add support for PCIe enumeration
protocols in PEI

Mateusz,

Unfortunately, the continued migration of DXE code into PEI
(specifically, into PEI code running before RAM is available) is putting
a huge crunch on BIOS size. Server processors have a limited amount of
cache-as-RAM (CAR) space available, and extremely complex code for
initializing memory and the system fabric. Space is at a premium today,
and adding PCIe initialization to CAR will make the problem worse.

Servers also tend to have very large, complex PCIe hierarchies, most of
which isn't needed for S3 or the other flows you mentioned. (Not that
servers do much with S3 anyway....) Spending CAR space on it doesn't
seem like a good tradeoff.
Agree that would be tough for server platform having PCI enum in CAR phase.


Can PCIe enumeration and the things that depend on it (S3, capsules,
recovery, etc.) isolate their code to a compressed FD placed outside of
the CAR region, and not run until RAM is available?

Or can you think of another way to reduce the amount of code and data in
CAR?

Thanks,

Brian J. Johnson
HPE

-------- Original Message --------
From: Albecki, Mateusz [mailto:mateusz.albecki@intel.com]
Sent: Wednesday, November 10, 2021, 6:54 AM
To: Abner Chang <abner.chang@hpe.com>, rfc@edk2.groups.io
Subject: [edk2-rfc] Proposal to add support for PCIe enumeration
protocols in PEI

Hi Abner,

The way I see it is that platform should be in control of starting the
enumeration and which devices it wants enumerated(by enumerated I
mean
resources assigned and PPI installed). Right now our idea is to simply
have our own PEIM implementation that will hold Intel specific logic
inside of it and in the next step propose a common enumeration PEIM to
EDK2 with several hooks that will allow platform configurability.

As for second part of your mail I see 2 points to unpack. First is the
optimization that would eliminate the need for 2 resource assignment
passes during boot(PEI + DXE). It should be possible to install HOB in
enumeration PEIM that would later on be consumed by DXE PCI bus driver
which would inform it that resources are assigned and it should only
scan the hierarchy and install required protocols which would save us
some boot time. The problem with this solution is that while it probably
could work quite well on system on which both PEI and DXE are either
32-bit or 64-bit it is hard to achieve on what I think is right now the
most popular configuration which is 32-bit PEI and 64-bit DXE. Due to
limited system addresses in 32-bit PEI enumerator PEIM might be forced
to make suboptimal decisions in resource assignment or might even decide
to skip some devices altogether if it starts running out of memory.
I think this could be fixed if we can have the record in HOB for the 32-bit/64-bit mixed boot phases.
DXE PCI enumeration can reassign the resource for 64-bit boot phase if necessary.


Second point is about PCI device information that, if I understood you
correctly, would contain PCI device information that we can get from PCI
config of a device organized in a table and probably installed into a
HOB. I can see some value in such table as it could be used by DXE code
that runs before DXE enumeration however I don't really see why DXE
code
would prefer to use it over locating protocols. Note that protocols are
required to be installed anyway to make DXE device drivers work so I
don't really see how we could skip them.
I know this subject could be apart from your proposal. I add this suggestion to your proposal because I notice that we may need to carry some PCI information which discovered during PEI PCI enum to DXE phase in order to reduce the duplicate effort of PCI enum in DXE. We still can have that PCI device information even the PEI PCI enum is not enabled on platform. Some information is not able to be retrieved from the existing EFI protocol defined in UEFI spec, such as the PCI port number, slot number, embedded or slot, bifurcation, topology, device type and etc. We can either enhance the EFI device path to accommodate this information or install the additional protocol that points to the information on the PCI EFI handle. The use case could be in either DXE phase (with PEI PCI enum enabled) or in BDS phase.

Thanks
Abner



Thanks,
Mateusz







--

Brian

--------------------------------------------------------------------

"As an adolescent I aspired to lasting fame, I craved factual
certainty, and I thirsted for a meaningful vision of human life - so
I became a scientist. This is like becoming an archbishop so you
can meet girls."
-- M. Cartmill, sociologist
Re: Proposal to add support for PCIe enumeration protocols in PEI

Ni, Ray
 

The CAR size concern caused two additional design requirements:
1. separate FV being loaded after mem is ready
2. pre-scan in pre-mem and full-scan in post-mem

So, I am wondering if pre-mem scan is really needed?
if not, let's just say: one full-scan in post-mem

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Brian J. Johnson
Sent: Thursday, November 11, 2021 7:22 AM
To: rfc@edk2.groups.io; Albecki, Mateusz <mateusz.albecki@intel.com>; Chang, Abner <abner.chang@hpe.com>
Subject: Re: [edk2-rfc] Proposal to add support for PCIe enumeration protocols in PEI

Mateusz,

Unfortunately, the continued migration of DXE code into PEI
(specifically, into PEI code running before RAM is available) is putting
a huge crunch on BIOS size. Server processors have a limited amount of
cache-as-RAM (CAR) space available, and extremely complex code for
initializing memory and the system fabric. Space is at a premium today,
and adding PCIe initialization to CAR will make the problem worse.

Servers also tend to have very large, complex PCIe hierarchies, most of
which isn't needed for S3 or the other flows you mentioned. (Not that
servers do much with S3 anyway....) Spending CAR space on it doesn't
seem like a good tradeoff.

Can PCIe enumeration and the things that depend on it (S3, capsules,
recovery, etc.) isolate their code to a compressed FD placed outside of
the CAR region, and not run until RAM is available?

Or can you think of another way to reduce the amount of code and data in
CAR?

Thanks,

Brian J. Johnson
HPE

-------- Original Message --------
From: Albecki, Mateusz [mailto:mateusz.albecki@intel.com]
Sent: Wednesday, November 10, 2021, 6:54 AM
To: Abner Chang <abner.chang@hpe.com>, rfc@edk2.groups.io
Subject: [edk2-rfc] Proposal to add support for PCIe enumeration
protocols in PEI

Hi Abner,

The way I see it is that platform should be in control of starting the
enumeration and which devices it wants enumerated(by enumerated I mean
resources assigned and PPI installed). Right now our idea is to simply
have our own PEIM implementation that will hold Intel specific logic
inside of it and in the next step propose a common enumeration PEIM to
EDK2 with several hooks that will allow platform configurability.

As for second part of your mail I see 2 points to unpack. First is the
optimization that would eliminate the need for 2 resource assignment
passes during boot(PEI + DXE). It should be possible to install HOB in
enumeration PEIM that would later on be consumed by DXE PCI bus driver
which would inform it that resources are assigned and it should only
scan the hierarchy and install required protocols which would save us
some boot time. The problem with this solution is that while it probably
could work quite well on system on which both PEI and DXE are either
32-bit or 64-bit it is hard to achieve on what I think is right now the
most popular configuration which is 32-bit PEI and 64-bit DXE. Due to
limited system addresses in 32-bit PEI enumerator PEIM might be forced
to make suboptimal decisions in resource assignment or might even decide
to skip some devices altogether if it starts running out of memory.

Second point is about PCI device information that, if I understood you
correctly, would contain PCI device information that we can get from PCI
config of a device organized in a table and probably installed into a
HOB. I can see some value in such table as it could be used by DXE code
that runs before DXE enumeration however I don't really see why DXE code
would prefer to use it over locating protocols. Note that protocols are
required to be installed anyway to make DXE device drivers work so I
don't really see how we could skip them.


Thanks,
Mateusz







--

Brian

--------------------------------------------------------------------

"As an adolescent I aspired to lasting fame, I craved factual
certainty, and I thirsted for a meaningful vision of human life - so
I became a scientist. This is like becoming an archbishop so you
can meet girls."
-- M. Cartmill, sociologist
Re: Proposal to add support for PCIe enumeration protocols in PEI

Brian J. Johnson
 

Mateusz,

Unfortunately, the continued migration of DXE code into PEI (specifically, into PEI code running before RAM is available) is putting a huge crunch on BIOS size. Server processors have a limited amount of cache-as-RAM (CAR) space available, and extremely complex code for initializing memory and the system fabric. Space is at a premium today, and adding PCIe initialization to CAR will make the problem worse.

Servers also tend to have very large, complex PCIe hierarchies, most of which isn't needed for S3 or the other flows you mentioned. (Not that servers do much with S3 anyway....) Spending CAR space on it doesn't seem like a good tradeoff.

Can PCIe enumeration and the things that depend on it (S3, capsules, recovery, etc.) isolate their code to a compressed FD placed outside of the CAR region, and not run until RAM is available?

Or can you think of another way to reduce the amount of code and data in CAR?

Thanks,

Brian J. Johnson
HPE

-------- Original Message --------
From: Albecki, Mateusz [mailto:mateusz.albecki@intel.com]
Sent: Wednesday, November 10, 2021, 6:54 AM
To: Abner Chang <abner.chang@hpe.com>, rfc@edk2.groups.io
Subject: [edk2-rfc] Proposal to add support for PCIe enumeration protocols in PEI

Hi Abner,

The way I see it is that platform should be in control of starting the enumeration and which devices it wants enumerated(by enumerated I mean resources assigned and PPI installed). Right now our idea is to simply have our own PEIM implementation that will hold Intel specific logic inside of it and in the next step propose a common enumeration PEIM to EDK2 with several hooks that will allow platform configurability.

As for second part of your mail I see 2 points to unpack. First is the optimization that would eliminate the need for 2 resource assignment passes during boot(PEI + DXE). It should be possible to install HOB in enumeration PEIM that would later on be consumed by DXE PCI bus driver which would inform it that resources are assigned and it should only scan the hierarchy and install required protocols which would save us some boot time. The problem with this solution is that while it probably could work quite well on system on which both PEI and DXE are either 32-bit or 64-bit it is hard to achieve on what I think is right now the most popular configuration which is 32-bit PEI and 64-bit DXE. Due to limited system addresses in 32-bit PEI enumerator PEIM might be forced to make suboptimal decisions in resource assignment or might even decide to skip some devices altogether if it starts running out of memory.

Second point is about PCI device information that, if I understood you correctly, would contain PCI device information that we can get from PCI config of a device organized in a table and probably installed into a HOB. I can see some value in such table as it could be used by DXE code that runs before DXE enumeration however I don't really see why DXE code would prefer to use it over locating protocols. Note that protocols are required to be installed anyway to make DXE device drivers work so I don't really see how we could skip them.


Thanks,
Mateusz







--

Brian

--------------------------------------------------------------------

"As an adolescent I aspired to lasting fame, I craved factual
certainty, and I thirsted for a meaningful vision of human life - so
I became a scientist. This is like becoming an archbishop so you
can meet girls."
-- M. Cartmill, sociologist
Re: Proposal to add support for PCIe enumeration protocols in PEI

Albecki, Mateusz
 

Hi Abner,

The way I see it is that platform should be in control of starting the enumeration and which devices it wants enumerated(by enumerated I mean resources assigned and PPI installed). Right now our idea is to simply have our own PEIM implementation that will hold Intel specific logic inside of it and in the next step propose a common enumeration PEIM to EDK2 with several hooks that will allow platform configurability.

As for second part of your mail I see 2 points to unpack. First is the optimization that would eliminate the need for 2 resource assignment passes during boot(PEI + DXE). It should be possible to install HOB in enumeration PEIM that would later on be consumed by DXE PCI bus driver which would inform it that resources are assigned and it should only scan the hierarchy and install required protocols which would save us some boot time. The problem with this solution is that while it probably could work quite well on system on which both PEI and DXE are either 32-bit or 64-bit it is hard to achieve on what I think is right now the most popular configuration which is 32-bit PEI and 64-bit DXE. Due to limited system addresses in 32-bit PEI enumerator PEIM might be forced to make suboptimal decisions in resource assignment or might even decide to skip some devices altogether if it starts running out of memory.

Second point is about PCI device information that, if I understood you correctly, would contain PCI device information that we can get from PCI config of a device organized in a table and probably installed into a HOB. I can see some value in such table as it could be used by DXE code that runs before DXE enumeration however I don't really see why DXE code would prefer to use it over locating protocols. Note that protocols are required to be installed anyway to make DXE device drivers work so I don't really see how we could skip them.


Thanks,
Mateusz
Re: [edk2-devel] Update NASM to stable release 2.15.05

Andrew Fish <afish@...>
 

On Nov 9, 2021, at 10:39 AM, Michael D Kinney <michael.d.kinney@intel.com> wrote:

Hi Andrew,

It looks like the EDK II CI agents were updated to use NASM 2.15.05 back in March of this year.

https://github.com/tianocore/edk2/blob/0ecdcb6142037dd1cdd08660a2349960bcf0270a/BaseTools/Bin/nasm_ext_dep.yaml

So I think the only remaining task is to update the developer documentation to require NASM 2.15.05 as the new minimum required version.

Do you agree?
Yes sounds good.

Thanks,

Andrew Fish


Mike

-----Original Message-----
From: Andrew Fish <afish@apple.com>
Sent: Wednesday, October 20, 2021 11:05 AM
To: edk2-devel-groups-io <devel@edk2.groups.io>; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: rfc@edk2.groups.io
Subject: Re: [edk2-devel] Update NASM to stable release 2.15.05

Mike,

Sounds like a good plan.

Thanks,

Andrew Fish

On Oct 20, 2021, at 9:51 AM, Michael D Kinney <michael.d.kinney@intel.com> wrote:

Hello,

I would like to propose that we update to a newer version of NASM.

https://www.nasm.us/

The most recent stable version is 2.15.05.

https://www.nasm.us/pub/nasm/releasebuilds/2.15.05/

NASM 2.15.05 Documentation:

https://nasm.us/xdoc/2.15.05/html/
https://nasm.us/xdoc/2.15.05/nasmdoc.pdf


The reason to update is to use a version of NASM that supports
newer instructions that will allow the .nasm files with
DB statements for instructions to be updated to use
instruction names. This improves the readability/maintenance
of the .nasm source files:

https://nasm.us/xdoc/2.15.05/html/nasmdocb.html#section-B.1.41

Also, the work on tools such as uncrustify to format source files
require tests to make sure the source format changes do not cause
any functional changes. Compilers support flags for reproducible
builds. NASM 2.15.05 added the --reproducible flag that provides
the same feature for OBJ files produces by NASM.

https://nasm.us/xdoc/2.15.05/html/nasmdoc2.html#section-2.1.34


2.1.34 The --reproducible Option

If this option is given, NASM will not emit information that is
inherently dependent on the NASM version or different from run to
run (such as timestamps) into the output file.

Please let me know if there are any concerns with doing this tool update.
If there are no concerns, I will work on patches required to update
EDK II CI to use NASM 2.15.05 and to update the developer documentation
to require NASM 2.15.05 as the new minimum version.

Thanks,

Mike
Re: [edk2-devel] Update NASM to stable release 2.15.05

Michael D Kinney
 

Hi Andrew,

It looks like the EDK II CI agents were updated to use NASM 2.15.05 back in March of this year.

https://github.com/tianocore/edk2/blob/0ecdcb6142037dd1cdd08660a2349960bcf0270a/BaseTools/Bin/nasm_ext_dep.yaml

So I think the only remaining task is to update the developer documentation to require NASM 2.15.05 as the new minimum required version.

Do you agree?

Mike

-----Original Message-----
From: Andrew Fish <afish@apple.com>
Sent: Wednesday, October 20, 2021 11:05 AM
To: edk2-devel-groups-io <devel@edk2.groups.io>; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: rfc@edk2.groups.io
Subject: Re: [edk2-devel] Update NASM to stable release 2.15.05

Mike,

Sounds like a good plan.

Thanks,

Andrew Fish

On Oct 20, 2021, at 9:51 AM, Michael D Kinney <michael.d.kinney@intel.com> wrote:

Hello,

I would like to propose that we update to a newer version of NASM.

https://www.nasm.us/

The most recent stable version is 2.15.05.

https://www.nasm.us/pub/nasm/releasebuilds/2.15.05/

NASM 2.15.05 Documentation:

https://nasm.us/xdoc/2.15.05/html/
https://nasm.us/xdoc/2.15.05/nasmdoc.pdf


The reason to update is to use a version of NASM that supports
newer instructions that will allow the .nasm files with
DB statements for instructions to be updated to use
instruction names. This improves the readability/maintenance
of the .nasm source files:

https://nasm.us/xdoc/2.15.05/html/nasmdocb.html#section-B.1.41

Also, the work on tools such as uncrustify to format source files
require tests to make sure the source format changes do not cause
any functional changes. Compilers support flags for reproducible
builds. NASM 2.15.05 added the --reproducible flag that provides
the same feature for OBJ files produces by NASM.

https://nasm.us/xdoc/2.15.05/html/nasmdoc2.html#section-2.1.34


2.1.34 The --reproducible Option

If this option is given, NASM will not emit information that is
inherently dependent on the NASM version or different from run to
run (such as timestamps) into the output file.

Please let me know if there are any concerns with doing this tool update.
If there are no concerns, I will work on patches required to update
EDK II CI to use NASM 2.15.05 and to update the developer documentation
to require NASM 2.15.05 as the new minimum version.

Thanks,

Mike
Re: Proposal to add support for PCIe enumeration protocols in PEI

Abner Chang
 

Hi Mateusz,
Is the PEI PCI enumeration on demand according to the platform configuration? Or you are proposing the PCI enumeration is mandatory for each boot?
No matter which one, that would be good if the PCI device information that enumerated in PEI phase can be passed to DXE phase, then we don’t need the second time PCI enumeration in DXE phase if the device is ever enumerated in PEI.

Another benefit of PCI device information:
The PCI device information (e.g. PCI Device Table) can provide the information such as PCI BDF, device class, device type, embedded or on slot, IRQ routing, and etc.(maybe incorporate with platform libraries). This table can be leveraged by other upper layer EFI drivers (DXE/PEI/SMM) for other purposes without accessing PCI registers through PCI I/O protocol. (for example, create the SMBIOS table, ACPI table, ACPI methods and etc.).

Thanks
Abner

-----Original Message-----
From: rfc@edk2.groups.io [mailto:rfc@edk2.groups.io] On Behalf Of Albecki,
Mateusz
Sent: Friday, October 29, 2021 9:02 PM
To: Ni@mx0b-002e3701.pphosted.com; Ray <ray.ni@intel.com>;
rfc@edk2.groups.io
Subject: Re: [edk2-rfc] Proposal to add support for PCIe enumeration
protocols in PEI

That's my bad on the extra resource assignment. While I believe it is possible
to use less memory-efficient algorithm to assign resources on second pass
there should be no need for such behavior on majority of systems. What the
flow should look like is:

-> enumerator PEIM scans the PCI tree and assigns resources to all
controllers and installs EDKII_PCI_DEVICE_PPI for UFS controller
-> on another pass enumerator PEIM will install corresponding
EDKII_PCI_DEVICE_PPI for AHCI controller

The reason why platform might want to do multiple passes is to save CAR
space and only install EDKII_PCI_DEVICE_PPI for required devices in pre-
mem and that is what I wanted to emphasize with this flow. Of course for
small configurations with few controllers that need to be enumerated it
should be possible to do one pass and install PPI for every device.
Re: [edk2-announce] Inclusive Language RFC

Teng, Lynn L
 

Hello Sean,

You make a good point.

I will remove both steps 3.1 and 4.1 from the plan for now so we can focus on the main proposal.
We can open a discussion later on to determine how best to maintain inclusive language once the codebase has been updated.

Here is the updated proposal:

***

## Overview

To promote a more inclusive and open ecosystem, TianoCore is dedicated to removing archaic terminology that holds negative connotation.
In collaboration with UEFI, we will be following the same [Inclusive Language Implementation Guidelines](https://uefi.org/sites/default/files/resources/UEFI_Inclusive%20Language.pdf) as stated on UEFI.org](https://uefi.org/).


## Plan

1. Announcement of intent, and all check-ins from here onwards will need to abide by Inclusive Language Implementation Guidelines
2. Scrubbing of all comments, documentation, and Wiki pages
3. Scrubbing of all non-legacy code
4. Working with UEFI to scrub legacy code


## Implementation Guidelines

### Master/Slave to not be used together nor alone.
Alternatives:
Master | Slave
-------|-------
Main | Secondary, Subordinate
Primary | Secondary, Replica
Host | Target
Leader | Follower
Orchestrator | Worker
Initiator | Responder

Or similar descriptive terminology

### Blacklist/Whitelist to not be used together nor alone.
Alternatives:
Blacklist | Whitelist
----------|----------
Blocklist | Passlist
Denylist | Allowlist
Refused, Denied | Permitted

Or similar descriptive terminology

-----Original Message-----
From: announce@edk2.groups.io <announce@edk2.groups.io> On Behalf Of Sean
Sent: Monday, November 1, 2021 1:16 PM
To: Teng, Lynn L <lynn.l.teng@intel.com>; announce@edk2.groups.io
Subject: Re: [edk2-announce] Inclusive Language RFC

Content looks great except "Plan 4.1."
I don't see a commit hook as a solution that works for this community.
I would think the plan would leverage pr-gate/ci to enforce this?
Otherwise, it is yet another rule and place to cause code-review and contribution friction.

Thanks
Sean




On 10/25/2021 11:57 AM, Teng, Lynn L wrote:
Hello all,

Please provide your feedback and comments to the Inclusive Language Plan below over the next two weeks (10/25-11/05). Thank you in advance for your contributions.


***

## Overview

To promote a more inclusive and open ecosystem, TianoCore is dedicated to removing archaic terminology that holds negative connotation.
In collaboration with UEFI, we will be following the same [Inclusive Language Implementation Guidelines](https://uefi.org/sites/default/files/resources/UEFI_Inclusive%20Language.pdf) as stated on [UEFI.org](https://uefi.org/).


## Plan

1. Announcement of intent, and all check-ins from here onwards will
need to abide by Inclusive Language Implementation Guidelines 2.
Scrubbing of all comments, documentation, and Wiki pages 3. Scrubbing
all non-legacy code 3.1. Integrate open-source commit hook that will
warn submitter of violations 4. Working with UEFI to scrub legacy code
4.1. Update commit hook to block submissions with violations


## Implementation Guidelines

### Master/Slave to not be used together nor alone.
Alternatives:
Master | Slave
-------|-------
Main | Secondary, Subordinate
Primary | Secondary, Replica
Host | Target
Leader | Follower
Orchestrator | Worker
Initiator | Responder

Or similar descriptive terminology

### Blacklist/Whitelist to not be used together nor alone.
Alternatives:
Blacklist | Whitelist
----------|----------
Blocklist | Passlist
Denylist | Allowlist
Refused, Denied | Permitted

Or similar descriptive terminology
Re: RFC: Static Analysis in edk2 CI

Michael D Kinney
 

Hi Felix,

I think this is a great idea to add this to edk2 CI.

I recommend we focus initially on a full scan once a week to get started.

If we see lots of escapes, we can evaluate how to enable the scan on a submitted PR.

What do you need with from the community to move this proposal forward?

Thanks,

Mike

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Felix Polyudov via groups.io
Sent: Wednesday, September 1, 2021 5:53 PM
To: rfc@edk2.groups.io
Subject: [edk2-rfc] RFC: Static Analysis in edk2 CI

I would like to start a discussion regarding integration of the static analysis (SA) into the edk2 workflow.
I assume the SA benefits are well understood, so I'll get straight to the point; however, if anybody doubts the cause,
feel free to disagree.
Here is the high level overview on how we can integrate SA into edk2 CI.
Once we agree on a large picture, we can discuss the details.

- Use Open Coverity SA service. The service is free for open source projects. edk2 Open Coverity project already exists:
https://scan.coverity.com/projects/tianocore-edk2
- Update edk2 CI scripts to run analysis once a week
(I'm not proposing running SA on every pull request since the process is time consuming)
- Perform analysis on all the edk2 packages using package DSC files that are used for CI build tests
(Coverity analysis is executed in the course of a specially instrumented project build).
- SA results are uploaded to scan.coverity.com. To access them one would need to register on the site and request
tianocore-edk2 project access. The site can be used to triage the reported issues. Confirmed issues can be addressed using
a standard edk2 process (Bugzilla, mailing list).

Side notes:
- Another SA option is a CLANG CodeChecker (https://codechecker.readthedocs.io/en/latest/). However, as far as I'm aware,
no hosted CodeChecker service is available and it will be on edk2 community to deploy one.
- It is potentially possible to run incremental Open Coverity scans on each pull request. However, to do so we would need
to preserve build process and analyzer output files (essentially, the build folder) across the scans.
-The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This
communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the
reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any
form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then
delete or destroy all copies of the transmission.
[edk2-devel] RFC: Replace FMMT Tool from C to Python Version

Yuwei Chen
 

Hi everyone,

I would like to propose the new FMMT Python tool, which is used to replace the origin C version tool.
Currently the FMMT C tool is saved in edk2-staging repo, but its quality and coding style can't meet the Edk2 quality, which is hard to maintain (Hard/Duplicate Code; Regression bugs; Restrict usage).
The new Python version keeps same functions with origin C version. It has higher quality and better coding style, and it is much easier to extend new functions and to maintain.

You can get the FMMT Python tool through below link.

https://github.com/tianocore/edk2-staging/tree/PyFMMT

If you are interested in that, pls have a try.
Looking forward to your feedback~

Thanks,
Christine (Yuwei)
Re: [edk2-discuss] [edk2-rfc] Inclusive Language RFC

Teng, Lynn L
 

Hello Marvin,

Your concerns have been heard, but providing a list of every alternative for every scenario and how/when to use them would be unreasonable.
We would expect developers to use their understanding of each term and the context of how it is being used, and to find an appropriate alternative. The lists provided are by no means exhaustive, and are not definitive in how they are combined.

Similar to [the UEFI guidelines](https://uefi.org/sites/default/files/resources/UEFI_Inclusive%20Language.pdf), [the Linux community](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst), and [IEEE](https://mentor.ieee.org/myproject/Public/mytools/draft/styleman.pdf), our intent is simply to inform the community that we are going to be moving towards using Inclusive Language and are providing the list of words that are no longer permitted and possible alternatives for those words.

Best regards,
Lynn Teng

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Marvin Häuser
Sent: Wednesday, October 27, 2021 12:42 AM
To: rfc@edk2.groups.io; Teng, Lynn L <lynn.l.teng@intel.com>; devel@edk2.groups.io; discuss@edk2.groups.io
Subject: Re: [edk2-discuss] [edk2-rfc] Inclusive Language RFC

Hey,

On 25.10.21 20:47, Teng, Lynn L wrote:
Hello all,

Please provide your feedback and comments to the Inclusive Language Plan below over the next two weeks (10/25-11/05). Thank you in advance for your contributions.


***

## Overview

To promote a more inclusive and open ecosystem, TianoCore is dedicated to removing archaic terminology that holds negative connotation.
In collaboration with UEFI, we will be following the same [Inclusive Language Implementation Guidelines](https://uefi.org/sites/default/files/resources/UEFI_Inclusive%20Language.pdf) as stated on [UEFI.org](https://uefi.org/).


## Plan

1. Announcement of intent, and all check-ins from here onwards will need to abide by Inclusive Language Implementation Guidelines
2. Scrubbing of all comments, documentation, and Wiki pages
3. Scrubbing all non-legacy code
3.1. Integrate open-source commit hook that will warn submitter of violations
4. Working with UEFI to scrub legacy code
4.1. Update commit hook to block submissions with violations


## Implementation Guidelines

### Master/Slave to not be used together nor alone.
Alternatives:
Master | Slave
-------|-------
Main | Secondary, Subordinate
Primary | Secondary, Replica
Host | Target
Leader | Follower
Orchestrator | Worker
Initiator | Responder
Some of these combinations sound very awkward because they are not
strictly or strongly related language-wise. Examples:
- In my opinion, a replica can very well be a main, it just cannot be an
original.
- "Responder" is very generic - "slave" conveys work, not just any sort
of reaction
- "Primary" and "secondary" are clearly related, "main" and "secondary"
are not.
...

The combination "leader"/"follower" could be interpreted politically if
you just try hard enough, who knows what language revision proposals may
look like in 10 years from now. Maybe drop it entirely. :)

Or similar descriptive terminology

### Blacklist/Whitelist to not be used together nor alone.
Alternatives:
Blacklist | Whitelist
----------|----------
Blocklist | Passlist
Denylist | Allowlist
Refused, Denied | Permitted
I think this should be made stricter to "refused"/"permitted" and
"granted"/"denied" to stay consistent with common usage.

My biggest issues with such proposals is they tell me which words to not
use, but not which to use instead. Yes, there are plenty of alternatives
given, but when do I use which? E.g. "host" / "target" already is a very
common combination for debugging, but nobody would think of naming their
main git branch "host". If you deprecate widely conventional
terminology, in my opinion you should also provide clear and detailed
guidelines for which sub-areas they are deprecated by which exact
alternatives (e.g. "version control - main; debugging - host"). I don't
think a terminology zoo where everybody picks their preference by gut
feeling is in anyone's best interest.

Thanks!

Best regards,
Marvin


Or similar descriptive terminology
Re: [edk2-devel] RFC: Replace FMMT Tool from C to Python Version

Bob Feng
 

Marvin,

The PyGen*** tools I mentioned below are not implemented yet. But we want to convert the BaseTools C tools to python tools so we can move all basetools from edk2 repo to edk2-basetools repo.

For the edk2-basetools repo, please refer to the discussion https://edk2.groups.io/g/devel/topic/73069134#57482

Thanks,
Bob

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Marvin Häuser
Sent: Friday, October 29, 2021 9:27 PM
To: devel@edk2.groups.io; Feng, Bob C <bob.c.feng@intel.com>; gaoliming@byosoft.com.cn; Chen, Christine <yuwei.chen@intel.com>; rfc@edk2.groups.io
Cc: Kinney, Michael D <michael.d.kinney@intel.com>
Subject: Re: [edk2-rfc] [edk2-devel] RFC: Replace FMMT Tool from C to Python Version

Good day,

Is there any information available on PyGenFv? It also handles ELF to PE conversion (who knows why...), is that planned to be ported to Python as well? For Project Amaranth, we are currently implementing a tool to replace the ELF to PE conversion (among other things) and decided to write it in C to leverage the existing EDK II libraries for PE and ELF parsing, rather than re-implementing parsing in a different language.
We'd like to stay compatible with upstream EDK II for as long as possible, and plan to send patches for a tool proposal whenever it is ready (do not expect it before mid next year, if at all).

Best regards,
Marvin

On 29.10.21 12:43, Bob Feng wrote:

Liming,

Correct. PyFMMT does not depend on GenSec, GenFfs and GenFv.  Yes. the
future PyGenSec, PyGenFfs and PyGenFv can reuse code from PyFMMT.

Thanks,

Bob

*From:* devel@edk2.groups.io <devel@edk2.groups.io> *On Behalf Of
*gaoliming
*Sent:* Friday, October 29, 2021 10:16 AM
*To:* Chen, Christine <yuwei.chen@intel.com>; devel@edk2.groups.io;
rfc@edk2.groups.io
*Cc:* Feng, Bob C <bob.c.feng@intel.com>; Kinney, Michael D
<michael.d.kinney@intel.com>
*Subject:* 回复: [edk2-devel] RFC: Replace FMMT Tool from C to Python
Version

Christine:

 This is a good news. Thanks for your great work. With this change,
FMMT doesn’t depend on GenSec, GenFfs and GenFv C tool. Right? If yes,
can those logic be reused to replace GenSec, GenFfs and GenFv C tools?

Thanks

Liming

*发件人**:*Chen, Christine <yuwei.chen@intel.com>
*发送时间:* 2021年10月29日 8:33
*收件人:* devel@edk2.groups.io; rfc@edk2.groups.io
*抄送:* Feng, Bob C <bob.c.feng@intel.com>; Kinney, Michael D
<michael.d.kinney@intel.com>; Liming Gao <gaoliming@byosoft.com.cn>
*主题:* [edk2-devel] RFC: Replace FMMT Tool from C to Python Version

Hi everyone,

I would like to propose the new FMMT Python tool, which is used to
replace the origin C version tool.

Currently the FMMT C tool is saved in edk2-staging repo, but its
quality and coding style can’t meet the Edk2 quality, which is hard to
maintain (Hard/Duplicate Code; Regression bugs; Restrict usage).

The new Python version keeps same functions with origin C version. It
has higher quality and better coding style, and it is much easier to
extend new functions and to maintain.

You can get the FMMT Python tool through below link.

https://github.com/tianocore/edk2-staging/tree/PyFMMT
<https://github.com/tianocore/edk2-staging/tree/PyFMMT>

If you are interested in that, pls have a try.

Looking forward to your feedback~

Thanks,

Christine (Yuwei)
Re: [edk2-devel] RFC: Replace FMMT Tool from C to Python Version

Marvin Häuser <mhaeuser@...>
 

Good day,

Is there any information available on PyGenFv? It also handles ELF to PE conversion (who knows why...), is that planned to be ported to Python as well? For Project Amaranth, we are currently implementing a tool to replace the ELF to PE conversion (among other things) and decided to write it in C to leverage the existing EDK II libraries for PE and ELF parsing, rather than re-implementing parsing in a different language. We'd like to stay compatible with upstream EDK II for as long as possible, and plan to send patches for a tool proposal whenever it is ready (do not expect it before mid next year, if at all).

Best regards,
Marvin

On 29.10.21 12:43, Bob Feng wrote:

Liming,

Correct. PyFMMT does not depend on GenSec, GenFfs and GenFv.  Yes. the future PyGenSec, PyGenFfs and PyGenFv can reuse code from PyFMMT.

Thanks,

Bob

*From:* devel@edk2.groups.io <devel@edk2.groups.io> *On Behalf Of *gaoliming
*Sent:* Friday, October 29, 2021 10:16 AM
*To:* Chen, Christine <yuwei.chen@intel.com>; devel@edk2.groups.io; rfc@edk2.groups.io
*Cc:* Feng, Bob C <bob.c.feng@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
*Subject:* 回复: [edk2-devel] RFC: Replace FMMT Tool from C to Python Version

Christine:

 This is a good news. Thanks for your great work. With this change, FMMT doesn’t depend on GenSec, GenFfs and GenFv C tool. Right? If yes, can those logic be reused to replace GenSec, GenFfs and GenFv C tools?

Thanks

Liming

*发件人**:*Chen, Christine <yuwei.chen@intel.com>
*发送时间:* 2021年10月29日 8:33
*收件人:* devel@edk2.groups.io; rfc@edk2.groups.io
*抄送:* Feng, Bob C <bob.c.feng@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Liming Gao <gaoliming@byosoft.com.cn>
*主题:* [edk2-devel] RFC: Replace FMMT Tool from C to Python Version

Hi everyone,

I would like to propose the new FMMT Python tool, which is used to replace the origin C version tool.

Currently the FMMT C tool is saved in edk2-staging repo, but its quality and coding style can’t meet the Edk2 quality, which is hard to maintain (Hard/Duplicate Code; Regression bugs; Restrict usage).

The new Python version keeps same functions with origin C version. It has higher quality and better coding style, and it is much easier to extend new functions and to maintain.

You can get the FMMT Python tool through below link.

https://github.com/tianocore/edk2-staging/tree/PyFMMT <https://github.com/tianocore/edk2-staging/tree/PyFMMT>

If you are interested in that, pls have a try.

Looking forward to your feedback~

Thanks,

Christine (Yuwei)
Re: Proposal to add support for PCIe enumeration protocols in PEI

Albecki, Mateusz
 

That's my bad on the extra resource assignment. While I believe it is possible to use less memory-efficient algorithm to assign resources on second pass there should be no need for such behavior on majority of systems. What the flow should look like is:

-> enumerator PEIM scans the PCI tree and assigns resources to all controllers and installs EDKII_PCI_DEVICE_PPI for UFS controller
-> on another pass enumerator PEIM will install corresponding EDKII_PCI_DEVICE_PPI for AHCI controller

The reason why platform might want to do multiple passes is to save CAR space and only install EDKII_PCI_DEVICE_PPI for required devices in pre-mem and that is what I wanted to emphasize with this flow. Of course for small configurations with few controllers that need to be enumerated it should be possible to do one pass and install PPI for every device.
Re: [edk2-devel] RFC: Replace FMMT Tool from C to Python Version

Bob Feng
 

Liming,

Correct. PyFMMT does not depend on GenSec, GenFfs and GenFv. Yes. the future PyGenSec, PyGenFfs and PyGenFv can reuse code from PyFMMT.

Thanks,
Bob

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of gaoliming
Sent: Friday, October 29, 2021 10:16 AM
To: Chen, Christine <yuwei.chen@intel.com>; devel@edk2.groups.io; rfc@edk2.groups.io
Cc: Feng, Bob C <bob.c.feng@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: 回复: [edk2-devel] RFC: Replace FMMT Tool from C to Python Version

Christine:
This is a good news. Thanks for your great work. With this change, FMMT doesn’t depend on GenSec, GenFfs and GenFv C tool. Right? If yes, can those logic be reused to replace GenSec, GenFfs and GenFv C tools?

Thanks
Liming
发件人: Chen, Christine <yuwei.chen@intel.com<mailto:yuwei.chen@intel.com>>
发送时间: 2021年10月29日 8:33
收件人: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
抄送: Feng, Bob C <bob.c.feng@intel.com<mailto:bob.c.feng@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Liming Gao <gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>>
主题: [edk2-devel] RFC: Replace FMMT Tool from C to Python Version

Hi everyone,

I would like to propose the new FMMT Python tool, which is used to replace the origin C version tool.
Currently the FMMT C tool is saved in edk2-staging repo, but its quality and coding style can’t meet the Edk2 quality, which is hard to maintain (Hard/Duplicate Code; Regression bugs; Restrict usage).
The new Python version keeps same functions with origin C version. It has higher quality and better coding style, and it is much easier to extend new functions and to maintain.

You can get the FMMT Python tool through below link.

https://github.com/tianocore/edk2-staging/tree/PyFMMT

If you are interested in that, pls have a try.
Looking forward to your feedback~

Thanks,
Christine (Yuwei)
回复: [edk2-devel] RFC: Replace FMMT Tool from C to Python Version

gaoliming
 

Christine:

This is a good news. Thanks for your great work. With this change, FMMT
doesn’t depend on GenSec, GenFfs and GenFv C tool. Right? If yes, can those
logic be reused to replace GenSec, GenFfs and GenFv C tools?



Thanks

Liming

发件人: Chen, Christine <yuwei.chen@intel.com>
发送时间: 2021年10月29日 8:33
收件人: devel@edk2.groups.io; rfc@edk2.groups.io
抄送: Feng, Bob C <bob.c.feng@intel.com>; Kinney, Michael D
<michael.d.kinney@intel.com>; Liming Gao <gaoliming@byosoft.com.cn>
主题: [edk2-devel] RFC: Replace FMMT Tool from C to Python Version



Hi everyone,



I would like to propose the new FMMT Python tool, which is used to replace
the origin C version tool.

Currently the FMMT C tool is saved in edk2-staging repo, but its quality and
coding style can’t meet the Edk2 quality, which is hard to maintain
(Hard/Duplicate Code; Regression bugs; Restrict usage).

The new Python version keeps same functions with origin C version. It has
higher quality and better coding style, and it is much easier to extend new
functions and to maintain.



You can get the FMMT Python tool through below link.



<https://github.com/tianocore/edk2-staging/tree/PyFMMT>
https://github.com/tianocore/edk2-staging/tree/PyFMMT



If you are interested in that, pls have a try.

Looking forward to your feedback~



Thanks,

Christine (Yuwei)
Re: Proposal to add support for PCIe enumeration protocols in PEI

Ni, Ray
 

1. Background - why we need access to PCIe devices in PEI
I agree. It also matches today's SBL and coreboot behavior that enums PCI in early stage.


-> enumerator PEIM scans the PCI tree and assigns resources to UFS controller, EDKII_PCI_DEVICE_PEIM is installed
...
-> on another pass enumerator PEIM will assign resources to AHCI devices and install corresponding EDKII_PCI_DEVICE_PPI
Can you please explain how the enumerator PEIM firstly only assigns resources to UFS, and then another pass it assigns resources to AHCI?
Usually, one pass of enumeration assigns resources to all PCI devices.

Thanks,
Ray
Proposal to add support for PCIe enumeration protocols in PEI

Albecki, Mateusz
 

Hi All,

I would like to propose a new protocol which would standardize a way a device driver PEIM communicates with PEIM that discovers PCI devices and manages their resources(later called enumerator PEIM).


1. Background - why we need access to PCIe devices in PEI

As I understand it, historically PEI was supposed to do only minimum required initialization to bring up RAM and as soon as that completed it was supposed to transition to DXE phase which offered much more robust services and a working driver model. With introduction of S3 resume which would skip DXE phase we had to push more and more responsibilities into PEI. Current features supported in PEI which require access to PCI devices are:
* S3 resume opal unlock (bios needs to unlock storage with the saved password)
* Capsule update flows (capsule is located on mass storage)
* Boot from block devices (EFI variables are stored on those)


1. Current solution



To meet those use cases EDK2 maintains a set of PEI drivers for mass storage devices such as UFS(Bus/Pci/UfsPciHcPei), AHCI(Bus/Ata/AhciPei), NVMe(Bus/Pci/NvmExpressPei) etc. Each of those PEIMs uses custom PPI interfaces to interact with HW. For instance AHCI PEIM uses EDKII_ATA_AHCI_HOST_CONTROLLER_PPI while NVMe uses EDKII_NVM_EXPRESS_HOST_CONTROLLER_PPI. Both PPIs offer the same functionalities(get BAR, get device path) just with different names. It is the platform code responsibility to install those PPIs and ensure the proper PEIM dispatch sequence. For instance in case of multiple AHCI controllers platform code needs to ensure that all PPIs are installed before AhciPei PEIM is allowed to execute as it won't register for notification on new devices discovered on the system.


1. Problems with current solution.

Enumerator PEIM needs to track the class code of the discovered PCI device and select appropriate PPI to install. Not only is that cumbersome for the enumerator PEIM, it also makes it harder to scale the system with support for new device classes. For instance if in the future we want to support another device class in PEI we will need to define yet another PPI in EDK2 and modify the enumerator PEIM to support it. This makes rollout of new features in PEI harder and is not in-line with what DXE PCI stack offers. Current solution also lacks a model on what the sequence of events in PCI enumeration should look like.

2. Solution

Given that we can't get rid of PEI or replace PPIs with protocols in PEI easily, the solution I would like to propose is to introduce a EDKII_PCI_DEVICE_PPI which would leverage EFI_PCI_IO_PROTOCOL(to allow access to hardware) and EFI_DEVICE_PATH_PROTOCOL (used by opal unlock to match the password with the device). This new PPI could be used by device PEIMs instead of the old device class specific PPIs. This would bring the PEI solution more in line with DXE stack and would allow to seamlessly extend the system with support for new device classes. Definition of the PPI can be found below. Protocols from DXE are used intentionally to reduce unnecessary delta between 2 environments.

On the sequencing side I propose the device PEIMs should install a notify for EDKII_PCI_DEVICE_PPI installation. This would ensure that every time we discover new device an appropriate device PEIM is loaded on it. Device PEIMs also should have EDKII_DEVICE_PPI in it's depex section.

For example let's assume a system which boots from UFS and has the EFI variable store located on it, the system also has SATA drive which is locked with opal and needs to be unlocked on S3 resume. Platform BIOS writers are aware of this configuration and have put UFS block io device PEIM and PCI enumeration PEIM into pre-mem firmware volumes while AHCI device PEIM is put into post mem firmware volume.

enumerator PEIM and UFS device PEIM are dispatched in pre-memory -> assuming that UFS PEIM runs first it checks in its entry point if EDKII_PCI_DEVICE_PPI is inatalled and if not it simply installs notify and exits -> enumerator PEIM scans the PCI tree and assigns resources to UFS controller, EDKII_PCI_DEVICE_PEIM is installed -> UFS PEIM notify is invoked it checks if PPI matches its device class and proceeds with UFS PPIs installation which makes EFI varstore available -> platform proceeds with boot and memory training -> post-mem modules are dispatched -> AHCI device PEIM executes and installs its notify -> enumerator PEIM is invoked again through a platform specific mechanism -> on another pass enumerator PEIM will assign resources to AHCI devices and install corresponding EDKII_PCI_DEVICE_PPI -> both UFS and AHCI device PEIMs notifies are invoked -> AHCI device PEIM finds its device and proceeds with opal unlock.

If we can agree that such a PPI is a good addition I would proceed with the submit of this PPI into EDK2 followed by patches to add support for this PPI in device PEIMs in the near future.

Patch:

From c573594b4d3adf3c750f63f5f7ac333549dbc1de Mon Sep 17 00:00:00 2001
From: Mateusz Albecki mateusz.albecki@intel.com<mailto:mateusz.albecki@intel.com>
Date: Thu, 28 Oct 2021 14:31:10 +0200
Subject: [PATCH 1/1] MdeModulePkg: Add EDKII_PCI_DEVICE_PPI definition

New PPI will allow developers to easily add new device PEIMs.
---
MdeModulePkg/Include/Ppi/PciDevicePpi.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
create mode 100644 MdeModulePkg/Include/Ppi/PciDevicePpi.h

diff --git a/MdeModulePkg/Include/Ppi/PciDevicePpi.h b/MdeModulePkg/Include/Ppi/PciDevicePpi.h
new file mode 100644
index 0000000000..ab2e5c6b07
--- /dev/null
+++ b/MdeModulePkg/Include/Ppi/PciDevicePpi.h
@@ -0,0 +1,12 @@
+#ifndef _EDKII_PCI_DEVICE_PPI_H_
+#define _EDKII_PCI_DEVICE_PPI_H_
+
+#include <Protocol/PciIo.h>
+#include <Protocol/DevicePath.h>
+
+typedef struct {
+ EFI_PCI_IO_PROTOCOL PciIo;
+ EFI_DEVICE_PATH_PROTOCOL *DevicePath;
+} EDKII_PCI_DEVICE_PPI;
+
+#endif



Thanks,
Mateusz
---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
Re: Inclusive Language RFC

Marvin Häuser <mhaeuser@...>
 

Hey,

On 25.10.21 20:47, Teng, Lynn L wrote:
Hello all,

Please provide your feedback and comments to the Inclusive Language Plan below over the next two weeks (10/25-11/05). Thank you in advance for your contributions.


***

## Overview

To promote a more inclusive and open ecosystem, TianoCore is dedicated to removing archaic terminology that holds negative connotation.
In collaboration with UEFI, we will be following the same [Inclusive Language Implementation Guidelines](https://uefi.org/sites/default/files/resources/UEFI_Inclusive%20Language.pdf) as stated on [UEFI.org](https://uefi.org/).


## Plan
1. Announcement of intent, and all check-ins from here onwards will need to abide by Inclusive Language Implementation Guidelines
2. Scrubbing of all comments, documentation, and Wiki pages
3. Scrubbing all non-legacy code
3.1. Integrate open-source commit hook that will warn submitter of violations
4. Working with UEFI to scrub legacy code
4.1. Update commit hook to block submissions with violations
## Implementation Guidelines
### Master/Slave to not be used together nor alone.
Alternatives:
Master | Slave
-------|-------
Main | Secondary, Subordinate
Primary | Secondary, Replica
Host | Target
Leader | Follower
Orchestrator | Worker
Initiator | Responder
Some of these combinations sound very awkward because they are not strictly or strongly related language-wise. Examples:
- In my opinion, a replica can very well be a main, it just cannot be an original.
- "Responder" is very generic - "slave" conveys work, not just any sort of reaction
- "Primary" and "secondary" are clearly related, "main" and "secondary" are not.
...

The combination "leader"/"follower" could be interpreted politically if you just try hard enough, who knows what language revision proposals may look like in 10 years from now. Maybe drop it entirely. :)

Or similar descriptive terminology
### Blacklist/Whitelist to not be used together nor alone.
Alternatives:
Blacklist | Whitelist
----------|----------
Blocklist | Passlist
Denylist | Allowlist
Refused, Denied | Permitted
I think this should be made stricter to "refused"/"permitted" and "granted"/"denied" to stay consistent with common usage.

My biggest issues with such proposals is they tell me which words to not use, but not which to use instead. Yes, there are plenty of alternatives given, but when do I use which? E.g. "host" / "target" already is a very common combination for debugging, but nobody would think of naming their main git branch "host". If you deprecate widely conventional terminology, in my opinion you should also provide clear and detailed guidelines for which sub-areas they are deprecated by which exact alternatives (e.g. "version control - main; debugging - host"). I don't think a terminology zoo where everybody picks their preference by gut feeling is in anyone's best interest.

Thanks!

Best regards,
Marvin


Or similar descriptive terminology
Inclusive Language RFC

Teng, Lynn L
 

Hello all,

Please provide your feedback and comments to the Inclusive Language Plan below over the next two weeks (10/25-11/05). Thank you in advance for your contributions.


***

## Overview

To promote a more inclusive and open ecosystem, TianoCore is dedicated to removing archaic terminology that holds negative connotation.
In collaboration with UEFI, we will be following the same [Inclusive Language Implementation Guidelines](https://uefi.org/sites/default/files/resources/UEFI_Inclusive%20Language.pdf) as stated on [UEFI.org](https://uefi.org/).


## Plan

1. Announcement of intent, and all check-ins from here onwards will need to abide by Inclusive Language Implementation Guidelines
2. Scrubbing of all comments, documentation, and Wiki pages
3. Scrubbing all non-legacy code
3.1. Integrate open-source commit hook that will warn submitter of violations
4. Working with UEFI to scrub legacy code
4.1. Update commit hook to block submissions with violations


## Implementation Guidelines

### Master/Slave to not be used together nor alone.
Alternatives:
Master | Slave
-------|-------
Main | Secondary, Subordinate
Primary | Secondary, Replica
Host | Target
Leader | Follower
Orchestrator | Worker
Initiator | Responder

Or similar descriptive terminology

### Blacklist/Whitelist to not be used together nor alone.
Alternatives:
Blacklist | Whitelist
----------|----------
Blocklist | Passlist
Denylist | Allowlist
Refused, Denied | Permitted

Or similar descriptive terminology
21 - 40 of 753