LINUX.ORG.RU

Первый публичный релиз musl

 , , , ,


0

5

В списке рассылки uClibc Рич Фелкер (Rich Felker) объявил о первом публичном выпуске musl — новой реализации библиотек общего назначения языка C. Основные отличия от существующих решений:

  • В отличие от glibc, musl легче и конструктивно проще. Компиляция musl из исходных кодов на Intel Atom D510 занимает менее 40 секунд. Поддержка локалей ограничена UTF-8, что позволяет применять более прямые подходы и улучшает производительность. stdio также проще, меньше и, во многих случаях, ощутимо быстрее. В терминах big-O большинство используемых операций musl сопоставимы с glibc. При этом все алгоритмы более оптимальны по использованию памяти, в частности, многие операции, потенциально рискующие не завершиться из-за нехватки памяти в glibc, удачно сработают в musl, благодаря её более эффективному распределению O(1).
  • В отличие от dietlibc, разработчики не стремятся урезать каждый возможный байт, жертвуя производительностью и корректностью. musl не пытается отвратить вас от использования stdio, тредов, регулярных выражений и т.д., а стремится сделать эти элементы эффективными (размер бинарников, потребление памяти в рантайме и производительность).
  • В отличие от uClibc, musl имеет стабильное, хорошо определённое ABI. Особое внимание было уделено тому, чтобы не создавать лишних зависимостей между компонентами библиотеки, таким образом, при статической линковке будет использован только необходимый код.
  • В отличие от Google Bioinc (Android libc), musl не жертвует совместимостью со стандартами ради уменьшения размера библиотеки и не основан на старом коде BSD.
  • В отличие от всех вышеупомянутых реализаций, musl объединяет все стандартные функции в одну библиотеку (.a или .so), что значительно уменьшает время запуска, количество используемой памяти, упрощает процесс обновления и нивелирует риски несовпадения версий.

На данный момент musl реализует следующие стандарты:

  • ISO C99;
  • IEEE754;
  • POSIX 2008 base;
  • большую часть XSI и других из группы POSIX;
  • никаких заметных усилий на поддержку устаревших SVID и BSD направлено не было.

Целевая аудитория:

  • разработчики встраиваемых систем;
  • разработчики легковесных дистрибутивов Linux;
  • разработчики rescue disk;
  • любой, кто хочет собрать статически слинкованный бинарник для безболезненной установки на любой ОС с ядром Linux;
  • любой, чья программа может вызываться десятки или сотни тысяч раз в секунду и ей необходим минимальный оверхэд по времени старта и используемой памяти.

Текущий выпуск работает на платформе x86 с ядром Linux не старее 2.6 (список платформ будет увеличен в следующих релизах).

Полный набор .a имеет размер 160k, а .so — 220k. Подробную сравнительную таблицу возможностей musl и других реализаций можно посмотреть на сайте проекта.

Скачать

>>> Подробности

Ответ на: комментарий от silw

Это не мешает ему считаться основным сопровождающим глибц и даже фактически быть таковым.

shimon ★★★★★ ()
Ответ на: комментарий от shimon

ну можно и Дреппера «на контроль» поставить ,
например команда eglibc этим занимается,
а чтобы и они ничего не напортили, возьмем в контролеры Аурэлиена Джарно, а если убунтоидам и этого мало, вот новые «вкусные плюшки» от Маттиаса Клосе!

и тем не менее это все еще совместимо с glibc, практически полностью.

Sylvia ★★★★★ ()
Ответ на: комментарий от Lumi

>> Только непонятно нафиг в initrd UTF-8?

Чтобы сразу было прямо, без костылей.

В initrd? Зачем в initrd что-то, кроме ASCII?

Led ★★★☆☆ ()
Ответ на: комментарий от Led

Давай пойдём дальше. Зачем в инитэрдэ вообще что-то, включая аскии?

Lumi ★★★★★ ()
Ответ на: комментарий от Lumi

>Зачем в инитэрдэ вообще что-то, включая аскии?

Для вывода сообщений, в т.ч. по netlink'у, на «монитор» (смотреть по IPMI) и т.п.

Led ★★★☆☆ ()
Ответ на: комментарий от Led

> В initrd? Зачем в initrd что-то, кроме ASCII?

С UTF-8 можно написать что-то навроде:

«флешку с ключом вставь. Флешку запилил мне быстро, мент!»

Или:

«корневая ФС не монтируется, бл-ть!»

shimon ★★★★★ ()

молодцы, больше сказать не чего!

Deleted ()
Ответ на: комментарий от Lumi

>Та сам ответил на свой вопрос про UTF-8.

Тупишь. На POSIX-«языке» сообщений достаточно. Тем более, что экранных не-ASCII шрифтов в initrd никто пихать не будет.

Led ★★★☆☆ ()
Ответ на: комментарий от shimon

>С UTF-8 можно написать что-то навроде:

Не забудь шрифты добавить и загрузить их ДО того, как вякать про флэшку.

Led ★★★☆☆ ()
Ответ на: комментарий от Led

> Тупишь.
Не обольщайся.

На POSIX-«языке» сообщений достаточно.

Устрица.

Тем более, что экранных не-ASCII шрифтов в initrd никто пихать не будет.

Какой ты наивный.

Lumi ★★★★★ ()
Ответ на: комментарий от eugene2k

Надо полагать временная сложность алгоритма, в противовес пространственной сложности n()?

alx_me ★★☆ ()
Ответ на: комментарий от AVL2

> >Поддержка локалей ограничена UTF-8

не погорячились? Хотя...

Адекватные люди сделали бы выбор, пусть даже и перед компиляцией, то есть не run-time.

alx_me ★★☆ ()
Ответ на: комментарий от Deleted

> Хороший способ наконец уже перегнать палкой всех любителей кои-999-zxc.

Палки не хватает, уважаемая?

alx_me ★★☆ ()
Ответ на: комментарий от shty

А риманово, а лобачевского, а минковского? Как же так? И вы реально __знаете__?

alx_me ★★☆ ()

Что там за аллокатор такой - «musl-native». Упоротый велосипед, или он на чем-то базируется? Есть статьи про его устройство?

Manhunt ★★★★★ ()
Ответ на: комментарий от Manhunt

> The allocator was written from the ground up based on the design principles of dlmalloc, but with an added requirement of fine-grained locking, and some simplifications to keep the synchronization complexity from getting out of hand. The resulting code is roughly half the size of dlmalloc.

mmap is used to satisfy allocation requests of 128k or greater. For smaller requests, the heap (brk) is used. Free chunks are returned to the allocator and coalesced immediately, and large free regions will be returned to the system even if they are not at the top of the heap by mapping new zero-pages over top of them. This prevents freed memory from eventually getting swapped to disk or causing other data to get swapped out.


In developing the allocator, I performed a number of stress-test benchmarks to measure worst-case performance under contention when a number of threads all call malloc and free in various patterns within tight loops. I plan to make the benchmark framework rigorous and document the results, but that is a project in itself which is not yet complete. Until then, it suffices to say that, depending on the allocation pattern, musl performed within the range of half as fast to twice as fast as glibc's ptmalloc.

Manhunt ★★★★★ ()

А лицензия там какая? Надеюсь, что BSD или похожая. А то GPL/LGPL для библиотек не самое удачное решение. Ведь на основе этих библиотек иногда собирают что-то вроде Android'а. И тогда сочиняют велосипеды только из-за слишком суровой лицензии.

lucentcode ★★★★★ ()

> Все используемые алгоритмы, в отличие от glibc, оптимизированы в big-O; многие операции, которые могут не завершиться из-за условий out-of-memory в glibc, удачно сработают в musl, благодаря лучшей реализации пространства O(1).

Бгггг. Фееричнейший перевод. «Space» - это не в смысле пространств (евклидовых, гильбертовых, и прочих), а в смысле используемого места. То есть в смысле потребляемой памяти. Разжевываю по пунктам:

  • musl tends to match glibc's big-O performance for most operations, with constant factors varying between moderately worse and significantly better (тут говорят о равном с glibc БЫСТРОДЕЙСТВИИ, в терминах O-большого)
  • Unlike glibc, all algorithms used by musl have optimal space big-O (тут говорят об оптимальном, в отличие от glibc, ИСПОЛЬЗОВАНИИ ПАМЯТИ, в терминах O-большого)
  • many operations which can fail on glibc due to out-of-memory conditions never fail with musl, due to superior O(1)-space implementations (тут говорят о том, что, в отличие от glibc, многие операции никогда не фейлятся из-за нехватки памяти, потому что ПОТРЕБЛЯЮТ O(1) ПАМЯТИ; т.е. их потребление памяти совсем не зависит от размера входных данных)

Переводчики-корректоры-ньюсмейкеры, стыдно должно быть.

Manhunt ★★★★★ ()
Ответ на: комментарий от lucentcode

> LGPL для библиотек не самое удачное решение.

Бгг, копирасты сраные, все что от вас требуется - таскать с собой динамическую библиотеку и ее исходники. Неужели и это вам не подходит?!

Ведь на основе этих библиотек иногда собирают что-то вроде Android'а. И тогда сочиняют велосипеды только из-за слишком суровой лицензии.


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

Manhunt ★★★★★ ()

Если единственная поддерживаемая локаль — UTF-8, то как там с поддержкой string.h и wchar.h ?

question4 ★★★★★ ()

это реверсная эволюция с конструктивным налетом минимализма...

Vetoldov ()

Changes: This release fixes a major bug in the intended long-term ABI for sigset_t/sigaction. Anyone using musl to build libraries should upgrade immediately (and rebuild any libraries... which might use signals) to avoid running into ABI breakage issues at a later time. The public header files have also undergone review and correction for conformance to ISO C and POSIX requirements for what they are allowed to make visible. Various other minor bugs have been fixed, and internal improvements have been made to facilitate upcoming ports to x86_64 and possibly ARM


http://www.etalabs.net/musl/releases/musl-0.5.9.tar.gz


обновили, с исправлениями косяков.

Sylvia ★★★★★ ()
Ответ на: комментарий от GAMer

> потому как во многих проектах ОС libc(правда обычно кастрированный донельзя) вообще встроен в ядро.

интересно, надо будет эти мюсли под Хайкой пособирать. Там libc какой-то BSD-шный, libroot.so, но половина фич glibc не работает, а сам glibc портировать под гайку как-то нудно.. надо попробовать эти мюсли как drop-in replacement вместо glibc

anonymous ()
Ответ на: комментарий от shimon

>Только гит автор все никак не сделает

git clone git.etalabs.net/musl

anonymous ()
Ответ на: комментарий от Sylvia

Так сказано же, что BSDшное старье не тянут за собой. NODELAY это как раз оттуда. NONBLOCK надо пользовать :)

anonymous ()
Ответ на: комментарий от anonymous

тем не менее в bash используется NDELAY,
кстати баш глючит ужасно с musl... если не сегфолится при любой команды (ps aux) то зависает на скриптах, даже таких простых как в eselect

Sylvia ★★★★★ ()
Ответ на: комментарий от Sylvia

ltrace на него натрави. И strace.

Вот по ссылке выше написано что gmon не поддерживается. Это плохо. Почему не сделали? там же просто заглушки нужно было написать.

anonymous ()
Ответ на: комментарий от anonymous

мне проще продолжать его собирать пока с dietlibc, не люблю когда инит скрипты оставляют в памяти висеть bash/sh , даже если это safe_mysqld,
поэтому ставлю задачу минимизировать потребление памяти sh

Sylvia ★★★★★ ()
Ответ на: комментарий от Sylvia

musl в GSoC 2011

У нас появилась задача по musl в рамках участия Openwall в GSoC 2011. Ментор по этой задаче - автор musl. :-)

http://openwall.info/wiki/ideas#Tasks2

«Develop intense unit tests for all libc interfaces, and test musl and other C libraries for correctness. Ideally the tests would be resilient against missing or buggy interfaces halting the test, so that partial results could be obtained even on certain incomplete or/and highly buggy C libraries.»

Есть предположение, что это позволит найти (и потом исправить) баги и даже уязвимости в glibc, dietlibc и др.

Студенты - обращайтесь.

solardiz ()
Ответ на: musl в GSoC 2011 от solardiz

Отличненько, автор musl потихоньку идет к успеху.

silw ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.