Обновление ядра Linux, оставление остальной системы без изменений

Я пользователь OpenBSD. В FAQ по OpenBSD говорится:

OpenBSD - это законченная система, предназначенная для синхронизации. Это не ядро ​​плюс утилиты, которые можно обновлять отдельно друг от друга.

Когда вы обновляете систему, вы делаете это за один раз; ядро и базовая система заменены. Затем вы идете и обновляете сторонние пакеты . При компиляции из исходного кода вы перекомпилируете ядро ​​и загружаете его. Затем вы перестраиваете базовую систему, а затем пакеты, которые вы установили. Если прошло более пары недель / месяцев с тех пор, как вы в последний раз перестраивали все, вы сначала устанавливаете снимок и перестраиваете оттуда (если вы следуете самой последней ветке CVS).

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

Я вполне в порядке с этим. Фактически, это одна из причин, по которой я использую OpenBSD. Это делает систему единым целым, и мне легко составить мысленный обзор.

Каково это в Linux? Большинство Linux, о которых я знаю, не имеют «базовой системы» в том же смысле, что и BSD, а представляют собой набор пакетов, собранных поставщиком распространения. Дальнейшее программное обеспечение затем добавляется к этому местным администратором таким образом, что граница между тем, что было там с самого начала, и тем, что было добавлено позже, в лучшем случае размыта.

Разве у Linux (вообще) нет сильного взаимодействия ядра с пользовательским пространством? Ядро обновляется, насколько мне известно, как и любой другой программный пакет, и меня немного смущает, что это вообще возможно. Добавьте к этому тот факт, что некоторые даже компилируют собственные ядра (что не рекомендуется в OpenBSD) и имеют множество различных версий ядра, перечисленных в их загрузочных меню.

Кто или что гарантирует, что различные подсистемы системы Linux могут взаимодействовать друг с другом, даже если они обновляются независимо друг от друга?

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

Я использую «Linux» выше как сокращение для «Linux дистрибутива», ядра + утилит.

Линус Торвальдс очень твердо убежден в том, что изменения в ядре приводят к регрессии в пользовательском пространстве (подробнее см. Вопрос « Ядро Linux: нарушение пользовательского пространства »).

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

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

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

Однако та же стабильность API не гарантируется для интерфейсов ядра и других деталей реализации . Sysfs (on /sys) и procsfs (on /proc/) предоставляют подробности реализации ядра, касающиеся конфигурации, оборудования, сети, процессов и т. Д., Которые используются низкоуровневыми приложениями. Эти интерфейсы могут изменяться несовместимым образом между версиями ядра, если для этого есть веская причина. Изменения по-прежнему пытаются минимизировать несовместимости, если это возможно, и существуют правила для того, как приложения могут использовать интерфейсы с наименьшей вероятностью вызвать проблемы. Влияние также ограничено, потому что не низкоуровневые приложения не должны использовать эти интерфейсы.

@PeterCordes указал, что если изменение в procfs или sysfs нарушит работу приложения, используемого вашими сценариями инициализации дистрибутива, у вас может возникнуть проблема.

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

@StephenKitt добавил, что для обновленного пользовательского пространства может потребоваться более новая версия ядра, и в этом случае система может не загружаться со старым ядром, и в примечаниях к выпуску дистрибутива об этом упоминается при необходимости.

Ядро Linux и пользовательское пространство дистрибутива Linux, в котором исторически доминировали пользовательские инструменты, разработанные проектом GNU, слабо связаны. Частично это по замыслу, а частично по необходимости.

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

И @sebasth также подчеркивает, что основная политика проекта ядра Linux заключается в том, что он не должен нарушать пространство пользователя. Что, конечно, является еще одним фактором, обеспечивающим слабую связь.

Тем не менее, все еще есть некоторая степень связи. Достаточно старое ядро ​​Linux не будет работать с современными дистрибутивами.

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

Довольно часто в системе устанавливаются два пакета пакетов ядра: текущий используемый пакет и ранее установленный пакет. При обновлении, после проверки правильности работы новой версии, самая старая версия может быть удалена, и у вас все еще есть надежный запасной вариант. Например, Red Hat (и его кузены) package-cleanup --oldkernels --count 2должны делать это автоматически.

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

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

Некоторые дистрибутивы добавляют дополнительные патчи больше, чем другие, но идея состоит в том, чтобы сохранить их так, как они исходят от разработчиков. Очевидно, что есть некоторые программы, которые требуют специальной конфигурации ядра, особенно виртуализации и сторонних драйверов, и обычно обе они используются для работы с конкретной версией ядра или, по крайней мере, не слишком старой версией ... причина в том, что они пытаются работать с новейшими функциями ядра, и поэтому, если вы попытаетесь запустить их со старым ядром, они могут работать неправильно.

Еще один дополнительный элемент, о котором следует помнить, это то, что во всех дистрибутивах Linux есть команда сопровождающих, людей, которые обеспечивают совместимость всего программного обеспечения с системой. Вот почему почти каждый дистрибутив имеет стабильную и нестабильную версию. Разработчики работают с «нестабильным» программным обеспечением и, когда все проверено, они отмечают его как стабильный, только после этого обычный пользователь может обновить пакет, поэтому, если человек, который спросил вас, является обычным пользователем, на 90% уверен, что программное обеспечение хорошо протестировано ,

Итак, кто есть, сообщество, а затем то, что должно быть общим подходом, нам нужно, чтобы программное обеспечение работало вместе, а не ломало систему, поэтому мы стараемся следовать некоторым стандартам, таким как Стандарт файловой системы .