Это написано, чтобы попытаться объяснить, почему Linux ** не имеет двоичного
интерфейс ядра, и при этом он не имеет стабильного интерфейса ядра**.

.. примечание::

  Обратите внимание, что эта статья описывает интерфейсы **в ядре**, а не
  ядро к интерфейсам пользовательского пространства.

  Интерфейс ядра к пользовательскому пространству — это тот, который используют прикладные программы,
  интерфейс системного вызова. Этот интерфейс **очень** стабилен с течением времени, и
  не сломается. У меня есть старые программы, которые были построены на чем-то до 0.9.
  ядра, которые по-прежнему прекрасно работают с последней версией ядра 2.6.
  Этот интерфейс — тот, на который могут рассчитывать пользователи и разработчики приложений.
  на стабильность.


...


Бинарный интерфейс ядра
-----------------------
Предполагая, что у нас есть стабильный исходный интерфейс ядра для ядра,
двоичный интерфейс, естественно, тоже произойдет, верно? Неправильный. Пожалуйста
рассмотрим следующие факты о ядре Linux:

  - В зависимости от версии используемого вами компилятора C, разные ядра
    структуры данных будут содержать различное выравнивание структур, и
    возможно включать разные функции по-разному (помещая
    встроенные функции или нет.) Индивидуальная организация функций
    не так важно, но другое заполнение структуры данных
    очень важно.

  - В зависимости от того, какие варианты сборки ядра вы выберете,
    ядро может принимать разные вещи:

      - разные структуры могут содержать разные поля
      - Некоторые функции могут быть вообще не реализованы (т.е. некоторые блокировки
	компилируется в ничто для не-SMP-сборок.)
      - Память внутри ядра можно выравнивать по-разному,
	в зависимости от вариантов сборки.

  - Linux работает на самых разных процессорных архитектурах.
    Невозможно, чтобы бинарные драйверы из одной архитектуры работали
    на другой архитектуре правильно.

Теперь ряд этих проблем можно решить, просто скомпилировав
модуль для точной конкретной конфигурации ядра, используя точно такой же
Компилятор C, с помощью которого было собрано ядро. Этого достаточно, если вы
хотите предоставить модуль для конкретной версии выпуска определенного
дистрибутив линукс. Но умножьте эту единственную сборку на количество
различные дистрибутивы Linux и количество различных поддерживаемых
релизы дистрибутива Linux, и вам быстро снится кошмар
разные варианты сборки на разных релизах. Также осознайте, что каждый
Выпуск дистрибутива Linux содержит несколько различных ядер, все
настроены на разные типы оборудования (разные типы процессоров и
разные варианты), так что даже для одного релиза вам нужно будет создать
несколько версий вашего модуля.

Поверьте, вы со временем сойдете с ума, если будете пытаться поддерживать такого рода
выпуска, я узнал это на собственном горьком опыте давным-давно...


Стабильные исходные интерфейсы ядра
-------------------------------

Это гораздо более «изменчивая» тема, если вы разговариваете с людьми, которые пытаются
сохранить драйвер ядра Linux, которого нет в основном дереве ядра, до
дата со временем.

Разработка ядра Linux ведется непрерывно и в быстром темпе, никогда
останавливаясь, чтобы замедлиться. Таким образом, разработчики ядра находят ошибки в
текущие интерфейсы или найти лучший способ сделать что-то. Если они это сделают
затем они исправляют текущие интерфейсы, чтобы они работали лучше. Когда они делают
поэтому имена функций могут меняться, структуры могут увеличиваться или уменьшаться, и
параметры функции могут быть переработаны. Если это произойдет, все
случаи использования этого интерфейса в ядре исправлены
в то же время, гарантируя, что все продолжает работать должным образом.

В качестве конкретных примеров этого можно привести встроенные в ядро ​​USB-интерфейсы.
претерпел не менее трех различных переделок за время существования этого
подсистема. Эти переделки были сделаны для решения ряда различных
проблемы:

  - Переход от синхронной модели потоков данных к асинхронной
    один. Это уменьшило сложность ряда драйверов и
    увеличили пропускную способность всех USB-драйверов, так что теперь мы
    почти все USB-устройства работают на максимально возможной скорости.
  - Внесено изменение в способ распределения пакетов данных из
    USB-ядро с помощью USB-драйверов, так что теперь все драйверы, необходимые для обеспечения
    больше информации к ядру USB, чтобы исправить ряд задокументированных
    тупики.

Это резко контрастирует с рядом операционных систем с закрытым исходным кодом.
которым со временем пришлось поддерживать свои старые USB-интерфейсы. Этот
предоставляет возможность новым разработчикам случайно использовать старый
интерфейсы и делать что-то неправильным образом, что приводит к нестабильности
операционная система страдает.

В обоих этих случаях все разработчики согласились, что это
важные изменения, которые необходимо было сделать, и они были сделаны, с
относительно небольшая боль. Если бы Linux нужно было гарантировать, что он сохранит
стабильный исходный интерфейс, новый интерфейс был бы создан, и
более старый, сломанный, пришлось бы обслуживать с течением времени, что привело
к дополнительной работе для разработчиков USB. Поскольку все разработчики Linux USB делают
свою работу в свободное время, прося программистов делать дополнительную работу бесплатно
получить, бесплатно, не представляется возможным.

Вопросы безопасности также очень важны для Linux. Когда
проблема с безопасностью найдена, она устранена за очень короткое время. А
несколько раз это приводило к тому, что внутренние интерфейсы ядра
переработано, чтобы предотвратить возникновение проблемы безопасности. Когда это
случается так, что все драйверы, использующие интерфейсы, также были исправлены в
в то же время, гарантируя, что проблема безопасности была устранена и не могла
случайно вернуться в будущем. Если внутренние интерфейсы
не разрешалось изменять, исправляя такого рода проблемы с безопасностью и
гарантировать, что это не повторится, невозможно.

Интерфейсы ядра очищаются с течением времени. Если никто не пользуется
текущий интерфейс, он удален. Это гарантирует, что ядро ​​останется
как можно меньше, и что все потенциальные интерфейсы тестируются как
насколько это возможно (неиспользуемые интерфейсы почти невозможно
тест на достоверность)