Linux для запуска альтернативы glibc?

Мир программного обеспечения с открытым исходным кодом и Linux / GNU в частности — странный мир, управляемый внутренней политикой и убеждениями. Теперь разочарование, похоже, взяло верх над разработчиками Linux, которые сейчас рассматривают возможность создания собственной библиотеки вызовов Linux.

Если вы пишете программы для Linux, вы столкнетесь с явлением отсутствия вызова функции, которая реализует какой-то аспект операционной системы. Обычно ваш единственный выбор — это попытаться вспомнить, как выполнить системный вызов, и поискать информацию в документации. Обычно вы можете создать свою собственную простую оболочку за несколько минут, а затем у вас остается вопрос, почему ее нет в стандартной библиотеке Linux C glibc?
Библиотека glibc поддерживает стандарты C и C ++, а также стандарты POSIX 1 и 2, и некоторые упущения, вероятно, связаны с тем, что системный вызов является специфичным для Linux, но в glibc есть много специфичных для Linux оболочек функций, обычно обозначенных имя, оканчивающееся на _np для непереносимого, так почему не все системные вызовы?
Ответ найти непросто. Кажется, что программисты glibc иногда торопятся, а иногда им просто не нравятся системные вызовы. Это странно, потому что вы можете подумать, что роль разработчика библиотеки будет заключаться в том, чтобы обернуть все системные вызовы и упростить их использование в пространстве пользователя, пытаясь сохранить как можно большую переносимость. Вместо этого программисты glibc критикуют системные вызовы Linux и отказываются поддерживать те, которые им не нравятся, по целому ряду причин. На самом деле уже слишком поздно критиковать системный вызов после того, как он был разработан и включен в операционную систему, но, похоже, именно это и происходит.
На практике ожидание поддержки glibc может быть долгим — например, если вы хотите использовать планирование крайних сроков, которое было введено в основное ядро в 2014 году, оно все еще не имеет оболочки и может никогда не получить ее. Это не только делает планирование сроков более сложным для потенциального пользователя, но и делает его менее поддерживаемым, и, следовательно, его лучше избегать.

В списке рассылки ядра Linux наконец-то всплыло разочарование:
Даниэль Колашьоне
Официальная библиотека оболочки Linux?
Теперь, когда glibc в основном не добавляет никаких новых оболочек системных вызовов, как насчет публикации «официальной» библиотеки склейки системных вызовов как части дистрибутива ядра вместе с заголовками uapi? Я не думаю, что разумно ожидать, что люди будут продолжать использовать syscall (__ NR_XXX) для всех новых функций, особенно по мере того, как система расширяет все более сложные возможности (например, новый API монтирования и, надеюсь, новый API процессов) за пределами ограничений POSIX. процесс.
В более поздних публикациях указывается, что утверждение о том, что glibc больше не принимает специальные оболочки для Linux, является преувеличением, но в целом создается впечатление, что новая библиотека вызовов Linux — хорошая идея.
Может быть, glibc пытается обслужить слишком много стандартов?
Может ли быть, что POSIX — это просто отвлечение, учитывая, что Linux имеет так много расширений и является стандартом де-факто сам по себе?
Частично проблема заключается в управлении glibc:
Майкл Керриск:
Из разработки glibc могли исчезнуть люди, возражавшие против gettid. Я думал, что это было в случае с strlcpy / strlcat, но это не так.
В настоящее время требуется один полуактивный участник glibc, чтобы заблокировать добавление системного вызова. Процесс преодоления устойчивых возражений никогда не применялся успешно, и даже для его запуска требуется много работы.
Gettid — это, пожалуй, самый известный случай, когда glibc не упаковывает системный вызов из-за неодобрения самого его существования. Это может быть плохой вызов, но он находится в ОС, и его следует упростить в использовании, предоставив простую оболочку функции.
Далее следует предложение о том, что люди, занимающиеся Linux, должны больше сотрудничать с разработчиками glibc, но вы можете сказать, что предстоит преодолеть немало истории.
Частично конфликт культур вызван разными проблемами:
Флориан Веймер
Некоторые разработчики glibc очень заботятся о соответствии стандартам для файлов заголовков. Разработчиков ядра это не волнует, и в результате мы копируем определения и объявления из файлов заголовков ядра, создавая дополнительные проблемы.
Сомнительно, что что-то случится, но беспокойство и разочарование реальны.
Вы должны прийти к выводу, что модель «доброжелательного диктатора» имеет ряд преимуществ.