{"id":88166,"date":"2020-07-13T01:42:48","date_gmt":"2020-07-12T23:42:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/v-sostav-yadra-linux-5-8-prinyaty-rekomendaczii-po-inklyuzivnoj-terminologii"},"modified":"2020-07-13T01:42:48","modified_gmt":"2020-07-12T23:42:48","slug":"v-sostav-yadra-linux-5-8-prinyaty-rekomendaczii-po-inklyuzivnoj-terminologii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/v-sostav-yadra-linux-5-8-prinyaty-rekomendaczii-po-inklyuzivnoj-terminologii","title":{"rendered":"The Linux 5.8 kernel has accepted recommendations for inclusive terminology.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Linus Torvalds accepted<\/a><\/noindex> in the Linux kernel 5.8 branch changes<\/a><\/noindex> style guide recommendations. The third draft was accepted third edition<\/a><\/noindex> text on the use of inclusive terminology, which was approved by 21 prominent kernel developers, including members of the Linux Foundation Technical Committee. A request was sent to Linus query<\/a><\/noindex> to include changes in kernel 5.9, but he felt there was no reason to wait for the next window for changes and accepted the new document into branch 5.8.<\/p>\n

The third version of the text on inclusive terminology was shortened compared to the original proposal<\/a><\/noindex> (the file inclusive-terminology.rst<\/a><\/noindex> with a discussion on the importance of inclusive language and an explanation of the reasons to avoid problematic terms). Only changes to the document defining the coding style remain. Developers are advised not to use the terms 'master \/ slave' and 'blacklist \/ whitelist', as well as the term 'slave' by itself. These recommendations only apply to new usage of these terms. Existing mentions of the specified words in the core will remain untouched. <\/p>\n

Additionally, the use of the highlighted terms in new code is permitted if it is required to maintain the user-space API and ABI, as well as when updating code to support existing hardware or protocols, where specifications mandate the use of these terms. When creating implementations based on new specifications, it is recommended, where possible, to align the terminology with the standard coding practices for the Linux kernel. <\/p>\n

The words 'blacklist\/whitelist' are recommended to be replaced with
\n'denylist \/ allowlist' or 'blocklist \/ passlist', and instead of the terms 'master \/ slave', the following pairs of alternatives are suggested:<\/p>\n