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

Я начал думать об этой проблеме в контексте этикета в списке рассылки Linux Kernel. Являясь самым известным в мире и, возможно, самым успешным и важным проектом свободного программного обеспечения, ядро ​​Linux получает множество пресса. И основатель проекта и лидер Линус Торвальдс, очевидно, не нуждается в представлении здесь.

Линус иногда привлекает споры с его пламенем на LKML. Эти пламена часто, по его собственному признанию, делают с нарушением пространства пользователя. Это подводит меня к моему вопросу.

Могу ли я иметь какую-то историческую точку зрения о том, почему нарушение пользовательского пространства такое плохо? Насколько я понимаю, для нарушения пользовательского пространства потребуются исправления на уровне приложения, но неужели это плохо, если он улучшает код ядра?

Как я понимаю, политика, изложенная Linus, заключается в том, что не нарушая пространства пользователя, все колывает все остальное, включая качество кода. Почему это так важно, и каковы плюсы и минусы такой политики?

(Очевидно, что некоторые политики придерживаются такой политики, последовательно применяемой, поскольку Линус иногда имеет «разногласия» со своими лучшими лейтенантами на LKML именно по этой теме. Насколько я могу судить, он всегда пробирается в материя.)

33 голоса | спросил Faheem Mitha 11 +03002015-10-11T06:51:18+03:00312015bEurope/MoscowSun, 11 Oct 2015 06:51:18 +0300 2015, 06:51:18

1 ответ


23

В любых взаимозависимых системах существуют в основном два варианта. Абстракция и интеграция. (Я намеренно не использую технические термины). С Abstraction вы говорите, что когда вы звоните в API, который, хотя код API может измениться, результат всегда будет таким же. Например, когда мы вызываем fs.open(), нам все равно, будет ли это сетевой диск, SSD или жесткий диск, мы всегда будем получать открыть файловый дескриптор, с которым мы можем работать. С «интеграцией» цель состоит в том, чтобы обеспечить «лучший» способ сделать что-то, даже если путь изменится. Например, открытие файла может отличаться для общего сетевого ресурса, чем для файла на диске. Оба способа широко используются на современном рабочем столе Linux.

С точки зрения разработчиков это вопрос «работает с любой версией» или «работает с определенной версией». Отличным примером этого является OpenGL. Большинство игр настроены на работу с определенной версией OpenGL. Неважно, если вы компилируете из источника. Если игра была написана для использования OpenGL 1.1, и вы пытаетесь запустить ее на 3.x, вы не будете хорошо проводить время. На другом конце спектра некоторые вызовы, как ожидается, будут работать независимо от того, что. Например, я хочу вызвать fs.open() Я не хочу заботиться о том, какая версия ядра включена. Мне просто нужен файловый дескриптор.

Есть преимущества для каждого способа. Интеграция обеспечивает «новые» функции за счет обратной совместимости. Хотя абстракция обеспечивает стабильность по сравнению с «более новыми» вызовами. Хотя важно отметить, что это вопрос приоритетности, а не возможность.

Из общей точки зрения, без по-настоящему веской причины, абстракция всегда лучше в сложной системе. Например, представьте, если fs.open() работал по-разному в зависимости от версии ядра. Тогда простая библиотека взаимодействия с файловой системой должна поддерживать несколько сотен различных методов «открытого файла» (или, вероятно, блоков). Когда выйдет новая версия ядра, вы не сможете «обновить», вам придется протестировать каждую отдельную программу, которую вы использовали. Ядро 6.2.2 (подделка) может просто сломать ваш текстовый редактор.

Для некоторых примеров реального мира OSX обычно не заботится о нарушении пользовательского пространства. Они чаще стремятся к «интеграции» над «абстракцией». И при каждом крупном обновлении ОС все происходит. Это не значит, что один способ лучше, чем другой. Это выбор и дизайнерское решение.

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

Например, я отправил патч на BuildNotify.py. Не потому, что я альтруистичен, а потому, что я использую инструмент, и мне нужна функция. Это было легко, поэтому здесь есть патч. Если бы это было сложно или громоздко, я бы не использовал BuildNotify.py, и я бы нашел что-то еще. Если каждый раз, когда появляется обновление ядра, мой текстовый редактор сломался, я бы просто использовал другую ОС. Мои вклады в сообщество (пусть и небольшие) не будут продолжать или существовать, и так далее.

Итак, дизайнерское решение было принято для абстрактных системных вызовов, так что, когда я делаю fs.open(), он просто работает. Это означает сохранение fs.open после fs.open2() популярность.

Исторически это цель POSIX-систем в целом. «Вот набор вызовов и ожидаемых значений возврата, вы выясните середину». Опять же по причинам мобильности. Почему Линус выбирает использовать эту методологию, является внутренней для его мозга, и вы должны попросить его точно знать, почему. Если бы это был я, я бы выбрал абстракцию над интеграцией в сложной системе.

ответил coteyr 11 +03002015-10-11T07:30:16+03:00312015bEurope/MoscowSun, 11 Oct 2015 07:30:16 +0300 2015, 07:30:16

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132