Адзін з распрацоўшчыкаў з кампаніі Google у спісе рассылання LLVM тэму распрацоўкі шматплатформеннай стандартнай Сі-бібліятэкі (Libc) у рамках праекту LLVM. Па шэрагу прычын Google не задавальняюць бягучыя libc (glibc, musl) і кампанія на шляху да распрацоўкі новай рэалізацыі, якую прапануецца развіваць як частка LLVM.
Напрацоўкі LLVM апошнім часам выкарыстоўваюцца ў якасці асновы для пабудовы зборачнага інструментара Google. Асноўнай ідэяй з'яўляецца тое, што калі Google ужо пачаў развіваць сваю libc, то чаму б яму адразу не развіваць сваю сістэму ў складзе LLVM, які ўжо прапануе сваю стандартную бібліятэку для З++ (Libc++), але не мае аналагічнай стандартнай бібліятэкі для Сі ( Libc).
Распрацоўку плануецца весці паэтапна, паступова нарошчваючы функцыянальнасць. Першыя варыянты прапануецца аформіць у выглядзе праслойкі паміж дадаткам і сістэмнай Libc, з якой будуць запазычацца яшчэ не рэалізаваныя магчымасці. Пасля дасягнення пэўнага ўзроўню ў функцыянальнасці новая Libc зможа прымяняцца ў якасці поўнай замены сістэмнай Libc. Пачаць плануецца з падтрымкі архітэктуры x86-64, Linux і статычнага звязвання (дынамічная загрузка, кампаноўка і дадатковыя архітэктуры будуць рэалізаваны ў другую чаргу).
Праект пакуль на пачатковай стадыі развіцця, але ўжо вызначаны базавыя мэты:
- Модульнасць і развіццё ў адпаведнасці з філасофіяй пастаўкі грануляванай бібліятэкі, а не маналітнага набору;
- Падтрымка статычнага звязвання ў рэжымах з (Position-independent executables) і без PIE. Прадастаўленне CRT (C runtime) і загрузніка PIE для статычна злучаных выкананых файлаў;
- Падтрымка большай часткі функцый стандартнай Сі-бібліятэкі з дадаткамі POSIX і некаторымі спецыфічнымі для сістэм пашырэннямі, запатрабаванымі ў існуючых дадатках;
- Асцярожнае стаўленне да спецыфічных для вытворцаў пашырэнняў і іх даданне толькі пры неабходнасці. У стаўленні падтрымкі іншых пашырэнняў прапануецца ўжываць падыход праектаў Clang і libc++;
- Выкарыстанне ўзорных практык у распрацоўцы з выкарыстаннем інструментара LLVM, такіх як прымяненне sanitizer і fuzzing-тэставанні з самага пачатку.
Адзін з актыўных распрацоўшчыкаў LLVM , Што пастаўка libc у складзе інструментара LLVM не пазбаўлена сэнсу, але звычайна пры падобнай неабходнасці выкарыстоўваюць бібліятэку musl, якая якасна напісана, падтрымлівае розныя архітэктуры і дае неабходную функцыянальнасць, у тым ліку падтрымлівае дынамічнае звязванне. Апраўданым можа быць убудаванне musl у LLVM і развіццё яго як сінхранізаванага з асноўным праектам форка.
Сваё меркаванне таксама аўтар праекту Musl, які паспрабаваў аргументаваць чаму прапанова Google і ўключэнне Libc у пастаўку LLVM з'яўляюцца вельмі дрэннымі ідэямі:
- Распрацоўка і суправаджэнне карэктнай, сумяшчальнай і высакаякаснай Libc з'яўляецца вельмі цяжкай задачай. Праблема не ў аб'ёме кода, а ў забеспячэнні карэктных паводзін і цяжкасцях з рэалізацыяй інтэрфейсаў з улікам велізарнага пласта калі-небудзь напісаных прыкладанняў на З/C++, а таксама прыкладанняў на іншых мовах, runtime якіх выкарыстоўвае Libc. Падыход у лоб без уліку нюансаў толькі прывядзе да таго, што многія праграмы не змогуць працаваць з Libc, але тады такі праект не будзе цікавы спажыўцам.
- Карпаратыўная распрацоўка можа сапсаваць Libc, але праціснуць для шырокага выкарыстання, вынікам чаго стане неабходнасць дадання хакаў для забеспячэння сумяшчальнасці ў дадатках. Распрацоўка пад эгідай карпаратыўнага адкрытага праекта будзе цягнуць коўдру ў бок патрэб і рашэнняў кампаніі, у шкоду інтарэсаў супольнасці. Напрыклад, у выпадку выяўлення праблемы, якая выклікана памылкай у іншай сваёй праграме, у падкантрольнай распрацоўцы прасцей забяспечыць сумяшчальнасць Libc з гэтай памылкай, чым выправіць саму памылку. Apple выкарыстоўвае для гэтых мэт форк BSD libc, а Google ужывае ў Fuchsia форк musl. Досвед распрацоўніка musl кажа аб тым, што з ім звязваліся ў асноўным юрысты для ўдакладнення пытанняў ліцэнзавання, але ніколі не звярталіся для ўдакладнення тэхнічных дэталяў перад занясеннем у свае адгалінаванні бескарысных і парушаючых працу змен.
- Адсутнасць монакультуры пры распрацоўцы libc і арыентацыя на якія развіваюцца на аснове дасягнення кансэнсусу стандарты, замест аднаасобнага кіравання, што матывуе распрацоўнікаў прыкладных прыкладанняў выкарыстоўваць стандарты, а не прывязвацца да пэўных рэалізацый. Менавіта таму аўтар musl супраць уключэння яго бібліятэкі ў склад LLVM, як і супраць распрацоўкі libc у рамках LLVM, бо ў гэтым выпадку губляецца незалежны характар libc і вызначаная рэалізацыя становіцца рашэннем першага класа для LLVM, а ўсе астатнія - другога.
Крыніца: opennet.ru