Hi Andrej,

Hope it's a joke. Are you going to create a list with "forbidden" worlds?

No, this is not a joke. This is a development that is happening all over the industry, for example in Python (https://bugs.python.org/issue34605) or Git (https://sfconservancy.org/news/2020/jun/23/gitbranchname/) or MySQL (https://mysqlhighavailability.com/mysql-terminology-updates/). You can find a summary of the reasons in this IETF Memo (https://tools.ietf.org/html/rfc7704), and there's also some additional discussion and insight in the original patch submission that added this to Linux (https://lkml.org/lkml/2020/7/4/229).

I know this is a pretty US-centric topic, and those words don't have the same strongly charged connotations for everyone around the world as they do for people who have been directly affected by the US' unique history of slavery and ongoing racial injustice. But Trusted Firmware is an international project with a substantial amount of contributors from the US. So even though this issue may not affect everyone, it may affect some of our contributors (and especially also potential contributors) strongly enough that I think we owe it to them to at least discuss options for improving the situation. We should strive to be an inclusive and welcoming open-source project for everyone.

Just opened our chip User Manual: "master"- 1057 instances "slave" - 1011 instances We need to initialize "slave(s)" or "master(s)", so we have to use these words in our and Trusted Firmware code.

Yes, like I mentioned, I am well aware that there are practical concerns with this. A lot of Trusted Firmware code is about accessing hardware, and the terminology of that hardware was usually set in stone when it was designed. In some cases these terms are even tied to a common hardware standard, like for SPI or I2C busses. In those cases the standard needs to change first before the hardware can change (and there are attempts to do that for example for SPI: https://www.oshwa.org/a-resolution-to-redefine-spi-signal-names), and it will take years before those changes actually result in new hardware avoiding these terms. I am not saying that we should stop calling hardware registers by the name that's written in the manual in the meantime -- we should absolutely make exceptions where necessary to keep things practical. I am just proposing that we slowly get started on this issue, put it in the style guide, clearly list the remaining necessary exceptions, and maybe start looking for low-hanging fruit where existing code uses these terms in cases that are not tied to hardware or other external dependencies and could be changed easily.

The Linux rules codified this as "Exceptions for introducing new usage is to maintain a userspace ABI/API or when updating code for an existing (as of 2020) hardware or protocol specification that mandates those terms." -- I think we could aim for a similar guideline (minus the userspace ABI part which doesn't really apply to us). We should probably also consider exceptions for future hardware for a couple of years since these things take a long time to change. The hope is that over time companies will on their own start avoiding this terminology in hardware designs, with Linux leading the way as a forcing function that we can basically just follow (since it requires drivers for most of the stuff we access too, at least for TF-A).