Attendees
Dan Handley (Arm)
Eric Finco (ST)
Kangkang (Futurewei)
Julius Werner (Google)
Joakim Bech (Linaro)
Kevin Townsend (Linaro)
Praneeth Bajjuri (TI)
David Brown (Linaro)
Bill Fletcher (Linaro Community Projects)
Don Harbin (Linaro Community Projects)
Andrej Butok (NXP)
Dave Cocca (Renesas)
Minutes
Inclusivity language
JW: Proposing to follow lead of other open source projects in removing some
terms seen as non inclusive. Same as Linux did recently. May have to make
exception for some dependencies
DB: Wait for documentation of a device to do it, or proceed with it and
risk coming up with different terms. Seems suggesting to wait for upstream
to come up with it. A lot of older protocols may not get changed.
JW: Lowest common denominator to not update before internal dependencies.
DB: If the community agrees on a consensus on new terminology worth moving
to it.
AP: No issue to declare intent on e.g. wiki page.
AB: Some specifications are fixed and can’t change. Seems America centric.
In NXP there are no emails on this.
DanH: Can set a baseline for new work. Retrospective action can be more
problematic in terms of specs but local documentation is easier. E.g.
branch names possible - but has impact.
AP: If some devices have named hardware registers changing it could be
problematic vs pure software. Also it’s a personal thing.
DanH: Have to consider company interest and also TF.org
JW: Don’t think this is going to go away. Look at the volume of projects
working on this. Believe we might as well get started now.
EF: Agree should be a difference between internal company and tf.org.
Similar situation in ST to NXP. No pressure from stakeholders.
AP: Believe we look to cover the spirit of this and then look at the
practicalities
JW: Internal terminology vs from outside. Don’t believe we should set
deadlines. Decide if want it for future submissions
DC: Makes sense going forward to implement the intention for anything new
and also to participate in arriving at some common new terminology in the
industry.
KS: Think this a political topic. If TF has a proposal then each members
can take it back to their company.
DC: I think we can accommodate better terminology moving forward.
AP: Propose to stop the agenda here and it will be on the agenda for the
next meeting.
DanH: Changes to coding guidelines will need to be in several places
AP: Wondering if have something similar to maintenance guideline on the wiki
KK: Many of the alternatives will translate back to the same words in
Chinese. Will take a proposal back to the company.
AP: Note TSC mailing list is a public archive
Project Release Strategy
JB: How to make TF the source of information for projects (releases,
roadmap etc)?
Groups.io
DanH: Expenditure approved in the Board
AP: Have information from e.g. Zephyr project that they moved their archive
to groups.io
Standard Hardware requirements
EF: Didn’t have the bandwidth to prepare something on this. Can close it
for now
Gitlab/Github
DanH: Raised Linaro Lab ticket for prototyping. Appears easy.
AP: Final decision based on a prototype?
DanH: Goal to provide more community friendly front end - simple pull
request mechanism. Everything would have a GitHub FE but Gerrit would be
the ‘truth’ with respect to reviews. Also gives integrated issue tracker.
AP: Current infrastructure seems ‘clunky’ to some people
DanH: Need to get a suitable GH organization account.
Website Improvements
BF: Have had several rounds of review from Shebu/Matteo. OK with the
current design. Want to synchronise the transition next week aligned with
Connect presentation.
BF: After it’s live, will be open for changes from members
BF: Preview is available for review now.
https://production-trustedfirmware-org-265.websitepreview.linaro.org/
Supporting X.519
AP: Proposal sent by Kevin at the start of the year.
DB: Also involvement with SDO work
AP: Generated a clear requirement on TF-M
--
[image: Linaro] <http://www.linaro.org/>
*Bill Fletcher* | *Field Engineering*
T: +44 7833 498336 <+44+7833+498336>
bill.fletcher(a)linaro.org | Skype: billfletcher2020
Hi All,
As Linaro Connect starts tomorrow, here are some pointers to sessions that
will be of interest related to trustedfirmware.org.
- *PSA Secure Partitions in OP-TEE*
- Tuesday, September 22nd (1:25-1:50pm UTC)
- Speaker: Miklos Balint
- Slides available here
<https://static.sched.com/hosted_files/lvc20/9a/LVC20-112_PSA_Secure_Partiti…>
- *Trusted Firmware Project update*
- Tuesday, Sept. 22nd (2:00-2:25pm UTC)
- Spreaders: Matteo Carlini, Shebu Kuriakose
- Slides available here
<https://static.sched.com/hosted_files/lvc20/1e/LVC20-113-Trusted-Firmware-p…>
- *Scalable Security Using Trusted Firmware-M Profiles*
- Wednesday September 23rd (11.45am – 12.10pm UTC)
- Speakers: Shebu Kuiakose, David Want
- Slides available here
<https://static.sched.com/hosted_files/lvc20/d0/ScalableSecurityUsingTrusted…>
- *Enable UEFI Secure Boot using OP-TEE as Secure Partition*
- Thursday September 24th (3.45-4.10pm UTC)
- Speakers: Sahil Malhotra, Ilias Apalodimas
- *Secure Partition Manager (SEL2 firmware) for Arm A-class devices*
- Thursday September 24th (4.15-4.40pm UTC)
- Speaker: Olivier Deprez
- Slides are available here
<https://static.sched.com/hosted_files/lvc20/09/LVC20-305-secure-partition-m…>
Some general pointers to sessions of potential interest:
- Security related topics can be viewed here
- Boot architecture topics can be viewed here
As a reminder, sign up for tomorrow's event is at Linaro Connect
Registration <https://connect.linaro.org/> and is free, so feel free to
forward this information on. :)
The overall schedule is available at the same link as registration in case
you may be interested in other sessions.
Best regards,
Don
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).
> Let's have the initial discussion in this week's meeting to create the context for everyone. Julius, hope you are ok to lead the discussion?
> We then add it to the agenda for next month's meeting which hopefully provides everyone enough time to look at the details, consult within their organizations and consider the implications for their teams.
Yes, sounds good. I totally understand that there may be practical
concerns about this, especially in areas where the existing
terminology is well-established. I don't intend to change the whole
codebase overnight or stop anyone's productivity dead in their tracks.
I just want to get a discussion started about first of all making a
decision whether we want this in general, and then trying to identify
the best ways to further that goal while keeping practicality in mind.
> Ideally, we would also have a summary of the current projects just to understand the amount of updates that may be required.
I grepped a few numbers from TF-A to get started:
- blacklist: 0
- whitelist: 1
- master: 403
- 242 in plat/
- 47 in plat/brcm
- 44 in plat/xilinx
- 35 in plat/imx
- 30 in plat/mediatek
- 28 in plat/arm
- 41 in docs/ (most of these talking about the Git branch, not
master/slave relationships)
- 62 in drivers/arm/ccn + includes
- 18 in drivers/arm/cci + includes
- 17 in drivers/brcm + includes
- slave: 246
- 155 in plat/
- 72 in plat/renesas
- 18 in plat/mediatek
- 15 in plat/xilinx
- 14 in plat/nvidia
- 14 in plat/rockchip
- 27 in drivers/arm/cci + includes
- 25 in drivers/mtd/spi_mem + includes
- 23 in drivers/renesas/rcar
Note that I don't necessarily expect we'd want to start a huge effort
to get all of those cleaned up, especially for old outdated platform
ports that understandably nobody wants to invest time in anymore.
Hardware support code naturally ages and becomes obsolete over time
anyway. I think establishing guidelines for future submissions is much
more important in the long run. If we do want to clean up existing
code, it would probably be most useful to focus on generic
(non-platform) code that can be expected to have a longer lifetime.
Hi Julius, All,
We are very supportive of the discussion related to inclusivity in the project.
At the same time, we don't know what would be the practical implications for contributors and users of the project so I suggest we take this discussion in stages.
Let's have the initial discussion in this week's meeting to create the context for everyone. Julius, hope you are ok to lead the discussion?
We then add it to the agenda for next month's meeting which hopefully provides everyone enough time to look at the details, consult within their organizations and consider the implications for their teams.
Ideally, we would also have a summary of the current projects just to understand the amount of updates that may be required.
Hope this is agreeable to everyone.
Thanks,
Abhishek
-----Original Message-----
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius Werner via TSC
Sent: 14 September 2020 23:50
To: tsc(a)lists.trustedfirmware.org
Subject: [TF-TSC] Avoiding noninclusive language in Trusted Firmware code
Hi all,
I'd like to propose a short discussion topic for the next TSC meeting on Thursday. I've already brought this up in a recent board meeting with generally positive feedback, but we agreed that it's probably more of a topic for the TSC.
As some of you are probably aware, inspired by the recent and ongoing protests and societal discourse in the United States, many open source projects and platforms (from Python to GitHub) have started to reevaluate the terminology they use in code and documentation and updated their style guides to promote the use of inclusive terminology. Probably most closely related to our project, the Linux kernel recently merged a patch to deprecate the usage of the terms 'master' and 'slave' as well as 'blacklist' and 'whitelist' in their
codebase: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?i…
I would like to propose that the Trusted Firmware projects (I'm primarily interested in TF-A, but this would probably be something worth coordinating across projects) follow suit and start working on a similar change. Since a lot of our developers are also active in Linux and it is facing many of the same challenges (particularly with terminology tied to specific hardware standards), my proposal would be to basically just follow Linux' guidance regarding affected terms and policy here. I of course do not expect that we'll instantly delete every instance of the word 'master' or 'slave' from the repository, especially since like Linux we have many drivers for hardware where this terminology is already present in register names or protocol standards. But I think it would be important to codify the intention in the style guide to get started and provide guidance for reviewers of new submissions, even though cleaning up existing code is a long-term task and some code will probably remain stuck on them due to external dependencies.
I hope we can have a quick discussion in the meeting to gauge overall opinion of this idea and, if positive, decide on the best approach to bring it to the individual projects.
Thanks,
Julius
Hi All,
Any agenda items to add?
Currently these are on my list:
* Avoiding noninclusive language in code and documentation.
* Ongoing items to close or discuss further -
* Project release strategy
* Groups.io
* Standard hardware requirements
* Gitlab/Github
* Website improvements
Thanks,
Abhishek
Hope it's a joke.
Are you going to create a list with "forbidden" worlds?
-----Original Message-----
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius Werner via TSC
Sent: Tuesday, September 15, 2020 12:50 AM
To: tsc(a)lists.trustedfirmware.org
Subject: [TF-TSC] Avoiding noninclusive language in Trusted Firmware code
Hi all,
I'd like to propose a short discussion topic for the next TSC meeting on Thursday. I've already brought this up in a recent board meeting with generally positive feedback, but we agreed that it's probably more of a topic for the TSC.
As some of you are probably aware, inspired by the recent and ongoing protests and societal discourse in the United States, many open source projects and platforms (from Python to GitHub) have started to reevaluate the terminology they use in code and documentation and updated their style guides to promote the use of inclusive terminology. Probably most closely related to our project, the Linux kernel recently merged a patch to deprecate the usage of the terms 'master' and 'slave' as well as 'blacklist' and 'whitelist' in their
codebase: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kerne…
I would like to propose that the Trusted Firmware projects (I'm primarily interested in TF-A, but this would probably be something worth coordinating across projects) follow suit and start working on a similar change. Since a lot of our developers are also active in Linux and it is facing many of the same challenges (particularly with terminology tied to specific hardware standards), my proposal would be to basically just follow Linux' guidance regarding affected terms and policy here. I of course do not expect that we'll instantly delete every instance of the word 'master' or 'slave' from the repository, especially since like Linux we have many drivers for hardware where this terminology is already present in register names or protocol standards. But I think it would be important to codify the intention in the style guide to get started and provide guidance for reviewers of new submissions, even though cleaning up existing code is a long-term task and some code will probably remain stuck on them due to external dependencies.
I hope we can have a quick discussion in the meeting to gauge overall opinion of this idea and, if positive, decide on the best approach to bring it to the individual projects.
Thanks,
Julius
Hi all,
I'd like to propose a short discussion topic for the next TSC meeting
on Thursday. I've already brought this up in a recent board meeting
with generally positive feedback, but we agreed that it's probably
more of a topic for the TSC.
As some of you are probably aware, inspired by the recent and ongoing
protests and societal discourse in the United States, many open source
projects and platforms (from Python to GitHub) have started to
reevaluate the terminology they use in code and documentation and
updated their style guides to promote the use of inclusive
terminology. Probably most closely related to our project, the Linux
kernel recently merged a patch to deprecate the usage of the terms
'master' and 'slave' as well as 'blacklist' and 'whitelist' in their
codebase: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?i…
I would like to propose that the Trusted Firmware projects (I'm
primarily interested in TF-A, but this would probably be something
worth coordinating across projects) follow suit and start working on a
similar change. Since a lot of our developers are also active in Linux
and it is facing many of the same challenges (particularly with
terminology tied to specific hardware standards), my proposal would be
to basically just follow Linux' guidance regarding affected terms and
policy here. I of course do not expect that we'll instantly delete
every instance of the word 'master' or 'slave' from the repository,
especially since like Linux we have many drivers for hardware where
this terminology is already present in register names or protocol
standards. But I think it would be important to codify the intention
in the style guide to get started and provide guidance for reviewers
of new submissions, even though cleaning up existing code is a
long-term task and some code will probably remain stuck on them due to
external dependencies.
I hope we can have a quick discussion in the meeting to gauge overall
opinion of this idea and, if positive, decide on the best approach to
bring it to the individual projects.
Thanks,
Julius
