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:
commit
49decddd39
|
@ -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
|
||||
-----------
|
||||
|
|
Loading…
Reference in New Issue