Extend coding-style with inclusive-terminology recommendations.

-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEf41QbsdZzFdA8EfZHtKRamZ9iAIFAl8JBGkACgkQHtKRamZ9
 iAKzew//V1Hf5IjSFns8hY1qhXAp9L80RR0MkhJwua1AH/LmUB0mWdJRVDhUj5b1
 nIlk/mTbRnTdfnIZeSGfaZ6JkTEy4LtCDvlD9b3rd6jNqTRi27ibIeFlWKQH/dm9
 2AxdJ4eApHOkcM5o+Do+8EWTiyXpmeMxj2MQGFf6EM+aE+zbfWblhy1gfd27x4rG
 x254dkrkwgwdSO/gVRJRiFL4gFO7QNnAFVxy/XHaRaflkzBA4BY7w/sADvZSYThg
 OFtyu05CBiD6dADhjVR2i8mnbNrdLEDhDV6zmN7oXWB3ao1V5zazvefoTEh7k8CY
 FKXKiND5DVuhqM8rx2znIEEsBUdi+wXOBLc3iiSQ7aforF/oY2U2f4IhTnhspSRL
 Dtqjpma6qQNuqkDjRTv/Xw92AiElOEylC8PPapi1StGKW1YUSi9oIZJr6TgSUnbQ
 4QVC6BjOYfl31D4d+UMLewV18TXYh6gvP8l5fVNRtkBDCzvj5/8OmBOfhgwDBFH2
 MOU/HeLkZD4lElqtIBFMwS6+t1JW/mZleuS+MgoJfGBVVVxAXtvC4oQ2Luvtf4pk
 j0s9WVdpZ0ZmpmxasnJUFUOJel1SFXgkTnXDYFVzqHrE2GbobPJOsarMddYzrn5o
 1sIvo8LAh/Y+Bjp04XGpkVCWEnoXNtrqMdnhhcYZrRwPhZV09t4=
 =sJXD
 -----END PGP SIGNATURE-----

Merge tag 'inclusive-terminology' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux

Pull coding style terminology documentation from Dan Williams:
 "The discussion has tapered off as well as the incoming ack, review,
  and sign-off tags. I did not see a reason to wait for the next merge
  window"

* tag 'inclusive-terminology' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux:
  CodingStyle: Inclusive Terminology
This commit is contained in:
Linus Torvalds 2020-07-10 21:15:25 -07:00
commit 49decddd39
1 changed files with 20 additions and 0 deletions

View File

@ -319,6 +319,26 @@ If you are afraid to mix up your local variable names, you have another
problem, which is called the function-growth-hormone-imbalance syndrome.
See chapter 6 (Functions).
For symbol names and documentation, avoid introducing new usage of
'master / slave' (or 'slave' independent of 'master') and 'blacklist /
whitelist'.
Recommended replacements for 'master / slave' are:
'{primary,main} / {secondary,replica,subordinate}'
'{initiator,requester} / {target,responder}'
'{controller,host} / {device,worker,proxy}'
'leader / follower'
'director / performer'
Recommended replacements for 'blacklist/whitelist' are:
'denylist / allowlist'
'blocklist / passlist'
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. For new specifications
translate specification usage of the terminology to the kernel coding
standard where possible.
5) Typedefs
-----------