Когда речь идет про low level API, то как правило говорят про Glibc. Но на самом деле библиотека просто отдает наверх то, что выдается ей ядром системы. Есть такой механизм, syscalls, и Glibc оборачивает функции ядра просто вызовом syscall, например, чтобы реализовать функцию ssize_t read(int fd, void* buf, size_t len) это делается примерно вот так:

nread = syscall(SYS_read, fd, buf, len);



Вместо использования оберток Glibc можно дергать эти функции самому напрямую из ядра с помощью syscall, хотя почти всегда это нецелесообразно - ведь Glibc не просто оборачивает их, но и выполняет много других проверок (корректность аргументов, 32/64-битность и прочее). Но порой приходится, т.к. обертки в Glibc просто нет. Ядро Linux предоставляет огромное количество функций, и далеко не все из них имеют аналоги в API Glibc. Возникает вопрос, а почему какие-то функции экспортированы, а какие-то нет?

Раньше, когда Glibc управлял Ulrich "Stop Reopening" Drepper, он и решал - эту функцию включаем, а эту нет. После его ухода из Red Hat на заработки к финансовым спекулянтам в Goldman Sachs, когда процесс разработки Glibc упорядочился и оздоровился, народ начал обсуждать, а каковы могут быть формальные критерии для создания обертки для функции из ядра?

Одной из проблем является мало кому нужная кроссплатформенность Glibc. Дело в том, что несмотря на то, что в несовместимых между собой операционных системах семейства BSD, проприетарных Unix-системах, и т.п. используется свой аналог Libc, разработчики Glibc с непонятным упорством пытаются обеспечить кроссплатформенность библиотеки - спроса на это практически никакого, но работа ведется. Практика показывает, что кроссплатформенный аналог всегда проигрывает нативному, т.к. вынужден опираться на общее подмножество функционала всех систем, на которых он работает. Поэтому в коде будет полно кусков, облепленных ifdef, в которых по каждой ветке будут неисправленные ошибки, уже давно отсутствующие в других ветках. Хочется добавлять интересный Linux-функционал, но это сразу будет уводить Glibc от его сборок для альтернативных ядер. И даже когда функционал добавляется, его не используют в userspace, т.к. люди боятся обидеть шумных представителей меньшинств с нетрадиционными системами, которые запросто могут начать собирать на киллера. Поэтому Linux-специфичный API повисает мертвым грузом с одним или двумя пользователями, потому что любители юниксвэя закричат любую попытку его использования в популярных приложениях. Однако и здесь в обществе уже начало брезжить понимание, например Debian начал робко отказываться от комбинаций userspace и ядер, которые сдерживают его развитие, хотя до полного отказа от поддержки альтернативных игрушечных систем еще очень далеко.

Обсуждая невостребованную кроссплатформенность Glibc и аналоги в несовместимых между собой вариантах BSD нельзя не упомянуть религиозную суть вопроса. Мы ее не будем раскрывать, т.к. боимся ненависти со стороны фанатиков, и просто предложим подумать, о том, насколько может быть конструктивна техническая дискуссия с людьми, приписывающими везде GNU к названию ядра дистрибутива и ходящими босиком, или с людьми, переписывающими утилиты ls и cp, т.к. им показалось, что лицензия недостаточно открытая.

Так или иначе, но несмотря на все проблемы, интересный Linux-специфичный функционал в Glibc продолжал появляться все время, и обсуждение того, как бы формализовать его появление тоже шло. Все сдвинулось с мертвой точки в конце 2012 - начале 2013 года, когда гентушник Mike Frysinger выписал доводы за и против включения дополнительного API ядра в Glibc. Тогда результата не получилось, т.к. вопрос серьезный и всплыло много нюансов - дополнительная библиотека liblinux, как поступать на "стабильных" и "сертифицированных" (т.е. замороженных, старых и глючных) дистрибутивах, как поддерживать альтернативные архитектуры (а почему бы и никак не поддерживать и их?) и много чего еще.

Недавнее включение (обновление) поддержки futex в Glibc вновь плавно привело к идее формального описания критериев для добавления Linux-специфичного API . На этот раз дело дошло до документации. В целом народ согласен с документом - пора бы начать добавлять API из Linux без оглядки на совместимость с каким-нибудь TruOpenUnixWorks. Из забавного, появление и обсуждение этого RFC затормозило включение в Glibc функционала для поддержки kdbus.