В любых взаимозависимых системах есть два основных варианта. Абстракция и интеграция. (Я специально не использую технические термины). С 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 в целом. «Вот набор вызовов и ожидаемых возвращаемых значений, вы выясните середину». Опять же по причинам портативности. Почему Линус выбирает использовать эту методологию, является внутренним для его мозга, и вам придется попросить его точно знать, почему. Однако, если бы это был я, я бы выбрал абстракцию вместо интеграции в сложной системе.