Почему API модуля Linux не имеет обратной совместимости?
Как это сделано
Так называемые "литеральные символы" реализованы как обычные символы Unicode. Давайте посмотрим, как это работает для Tabulationи New line. Проверить Tabulationшестнадцатеричное -кодирование:
printf $'\t' | hexdump
Вывод
0000000 0009
0000001
Вывод означает, что символ \tявляется обычным символом UTF -8 U+0009. Вы можете распечатать его таким образом:
printf '\x00\x09'
или сecho:
echo -e '\u0009'
Рассмотрим следующий пример для символа New line:
bob@alice:~$ printf $'\n' | hexdump
0000000 000a
0000001
bob@alice:~$ printf '\x00\x0A empty lines are above and below'; echo $'\n'
empty lines are above and below
bob@alice:~$ echo -e '\u000a empty line is above'
empty line is above
bob@alice:~$
Как вводить символы Unicode
В Linux есть так называемые ComposeKeyили MultiKey. Ключ можно определить в файле xorg.conf.d/10-keyboard.conf, просто добавьте строку в файл:
Option "xkbOptions" "grp:alt_shift_toggle,terminate:ctrl_alt_bksp,compose:menu"`
UTF -8 (Unicode )Подсказки последовательности компоновки можно найти в файле Compose:
less /usr/share/X11/locale/en_US.UTF-8/Compose
В терминалах с графическим интерфейсом также работает CTRL+SHIFT+Uпривязка клавиш -нажмите ее, и вы увидите букву u. Введите 266aи завершите его клавишей Spaceили Enter-. Появится знак восьмерки.
Дополнительная информация
Грег Кроа -Хартман писал на эту тему здесь:https://www.kernel.org/doc/html/v4.10/process/stable-api-nonsense.html
Помимо некоторых технических подробностей, касающихся компиляции кода C, он выделяет пару основных вопросов разработки программного обеспечения, которые определяют их решение.
Ядро Linux всегда находится в стадии разработки. Это происходит по многим причинам:
- Появляются новые требования. Люди хотят, чтобы их программное обеспечение делало больше, поэтому большинство из нас обновляются, нам нужны новейшие и лучшие функции. Это может потребовать доработки существующего программного обеспечения.
- Обнаружены ошибки, требующие исправления, иногда ошибки связаны с самим дизайном и не могут быть исправлены без существенной доработки
- В мире программного обеспечения появляются новые идеи и идиомы, и люди находят гораздо более простые / элегантные / эффективные способы делать вещи.
Это относится к большинству программного обеспечения , и любое программное обеспечение, которое не поддерживается, умрет медленной и мучительной смертью . Вы спрашиваете, почему этот старый неподдерживаемый код все еще не работает?
Почему не поддерживаются старые интерфейсы?
Для обеспечения обратной совместимости потребуется поддерживать старые (часто "сломанные" и небезопасные )интерфейсы. Конечно, теоретически это возможно, за исключением того, что это требует значительных затрат .
Грег Кроа -Хартман пишет
If Linux had to ensure that it will preserve a stable source interface, a new interface would have been created, and the older, broken one would have had to be maintained over time, leading to extra work for the [developers]. Since all Linux [developers] do their work on their own time, asking programmers to do extra work for no gain, for free, is not a possibility.
Несмотря на то, что исходный код Linux является открытым, время разработчиков на его поддержку ограничено. Так что рабочую силу все же можно обсуждать с точки зрения «стоимости». Разработчики должны выбирать, как они проводят свое время:
- Тратить много времени на поддержку старых/сломанных/медленных/небезопасных интерфейсов. Иногда это может удвоить или утроить время, необходимое для написания интерфейса в первом экземпляре.
- Выбросьте старые интерфейсы и ожидайте, что другие специалисты по сопровождению программного обеспечения будут [выполнять свою работу и] поддерживать собственное программное обеспечение.
В конечном счете, объединение интерфейсов в бинарные группы действительно экономически -эффективно(для разработчиков ядра). Если вы хотите знать, почему разработчики не тратят месяцы и годы своей жизни на спасение других от платить 10 долларов за новый адаптер Wi-Fi... вот причина. Помните, что это выгодно с точки зрения времени и затрат для разработчиков ядра, но не обязательно -эффективно с точки зрения затрат для вас или производителей.
Хотя я внес несколько (незначительных )исправлений в ядро Linux, я не считаю себя разработчиком ядра. Однако вот что я знаю:
Драйвер, написанный для версии ядра 2.6.0.0 до -даты устранения большой блокировки ядра (BKL ), которая произошла в версии ядра 2.6.39.
BKL был создан еще тогда, когда Linux был еще одно-процессором (одноядерным -однопоточным -потоком )ОС. Как только была добавлена поддержка SMP, разработчики поняли, что BKL в какой-то момент станет большим узким местом, но пока в системе было всего несколько ядер/потоков, это было несколько терпимо. Но сначала это стало настоящей проблемой для людей, использующих Linux на суперкомпьютерах, и поэтому началась работа по замене всего, что требовало BKL, на более тонкие -детализированные механизмы блокировки или, по возможности, методы без блокировки.
На современных компьютерах, которые могут иметь двузначное -число ядер на обычных настольных компьютерах и мощных -ноутбуках, не говоря уже о серверах, API-интерфейс модуля ядра, обратно -совместимый с версией 2.6.0, также должен быть реализован. БКЛ.
Если устаревший модуль говорит: «Я хочу получить BKL», остальная часть ядра не имеет ни малейшего представления о том, что модуль планирует с ним делать, и поэтому механизм обратной -совместимости должен будет взять на себя все замки, которые заменили BKL только для покрытия всех возможностей. Это было бы большим хитом производительности. И новые методы без блокировки также должны будут проверять устаревшую блокировку -, что, в первую очередь, лишает возможности быть без блокировки. Так что само существование механизма обратной совместимости ухудшит производительность системы,даже если на самом деле не было загружено ни одного устаревшего модуля.
Совсем недавно патчи безопасности Spectre/Meltdown внесли большие изменения в то, что должно происходить при пересечении границы между ядром и пользовательским пространством. Любые модули, скомпилированные до того, как были реализованы исправления Spectre/Meltdown, могут быть ненадежными с ядрами после -Specre/Meltdown.
Всего две недели назад я устранял неполадки на старом сервере, который нуждался в ручном -включении питания, когда автоматически применялись обновления безопасности. Это случалось несколько раз до этого и было воспроизводимо. Я обнаружил, что у него была очень старая версия проприетарного megasrдрайвера хранилища до патчей Spectre/Meltdown, который не был включен в автоматические обновления. После обновления драйвера до актуальной версии проблема ушла. Кстати, это было в простой системе RHEL 6.10.
Я также наблюдал сбои серверов при загрузке проприетарных драйверов мониторинга оборудования до -Spectre/Meltdown с ядром после -Spectre/Meltdown. Основываясь на этом опыте, я полностью убежден, что исправления Spectre/Meltdown следует рассматривать как переломное событие :, ядро и модули должны быть либо все до -исправлений, либо все после -исправлений. версии; смешивание и сопоставление приведут только к печальным и полуночным вызовам -пробуждения для -вызова системного администратора.
А поскольку Spectre был проблемой на уровне конструкции ЦП , это «подарок, который не перестает приносить» :некоторые люди найдут новые способы использования слабых мест, и тогда разработчикам ядра понадобится выяснить способы блокировки эксплойтов.
Это всего лишь две большие проблемы, которые необходимо решить API устаревшего модуля ядра, совместимого с версией 2.6.0.0 -. Я уверен, что есть много других.
И еще есть более философская сторона. Подумайте об этом :, что делает Linux возможным?
По большей части это открытые спецификации оборудования . Если технические характеристики оборудования открыты, участвовать может любой желающий. Поскольку исходный код операционной системы открыт, каждый может внести свой вклад на благо всех. И вы не можете хранить спецификации аппаратного программирования как коммерческую тайну, если исходный код вашего драйвера -открыт.
Разработчики ядра Linux склонны верить в модель с открытым исходным кодом. Вот почему они сделали свой выбор дизайна и разработки таким образом, что предпочтительный способ участия производителя оборудования — это открыть -исходный код драйвера, объединить его с основным исходным дистрибутивом ядра, а затем (и . ] только тогда)вы получите пользу от всего сообщества разработчиков ядра в его поддержке.
Это дает разработчикам и производителям аппаратного обеспечения определенный стимул сделать это возможным. Если у вас есть что-то, что вы хотите сохранить в секрете, постарайтесь инкапсулировать это в ASIC или, если необходимо, в подписанную прошивку. (Если вы сделаете последнее, дайте другим разрешение на распространение пакета встроенного ПО.)
Но поскольку ядро имеет открытый исходный код, разработчики ядра точно не могут запретить другим поддерживать проприетарные драйверы отдельно. Но у них нет и стимула заботиться о них.
На самом деле дополнительные проблемы, вызванные проприетарными двоичными драйверами при отладке ядра, являются стимулом для разработчиков ядра не заботиться о разработке проприетарных драйверов :«Они усложняют мою работу, почему я должен сделать что-нибудь конкретное, чтобы облегчить их жизнь?"
Итак, разработчики ядра обычно делают то, что наиболее выгодно для их как группы/сообщества. Если это включает в себя некоторые изменения API модуля, пусть будет так. Драйверы сторонних -производителей даже не входят в уравнение.