Jeden z programistów z firmy Google w liście dyskusyjnej LLVM temat rozwoju wieloplatformowej standardowej biblioteki C (Libc) w ramach projektu LLVM. Z różnych powodów Google nie zadowala aktualna libc (glibc, musl) i firma dąży do opracowania nowej implementacji, którą proponuje rozwijać jako część LLVM.
Osiągnięcia LLVM są ostatnio wykorzystywane jako podstawa do budowy narzędzi kompilacyjnych Google. Podstawową ideą jest to, że jeśli Google już rozpoczął rozwój swojej libc, to dlaczego nie rozwijać od razu swojego systemu w ramach LLVM, który już oferuje swoją standardową bibliotekę dla C++ (Libc++), ale nie ma podobnej standardowej biblioteki dla C (Libc).
Rozwój planowany jest etapowo, stopniowo zwiększając funkcjonalność. Pierwsze wersje mają być przedstawione w postaci warstwy między aplikacją a systemową Libc, z której będą czerpane jeszcze nie wdrożone możliwości. Po osiągnięciu określonego poziomu funkcjonalności nowa Libc będzie mogła być stosowana jako pełny zamiennik systemowej Libc. Planowane rozpoczęcie od wsparcia architektury x86-64, Linux i statycznego linkowania (dynamiczne ładowanie, kompozycja i dodatkowe architektury będą realizowane w drugim etapie).
Projekt jest na wczesnym etapie rozwoju, ale już określono podstawowe cele:
- Modularność i rozwój zgodny z filozofią dostarczania granularnej biblioteki, a nie monolitycznego zestawu;
- Wsparcie statycznego linkowania w trybach z (programy niezależne od adresów) i bez PIE. Dostarczenie CRT (środowisko uruchomieniowe C) i ładowarki PIE dla statycznie linkowanych plików wykonywalnych;
- Wsparcie większości funkcji standardowej biblioteki C z dodatkami POSIX i niektórymi specyficznymi rozszerzeniami systemowymi, które są potrzebne w istniejących aplikacjach;
- Ostrożne podejście do specyficznych rozszerzeń producentów z ich dodawaniem tylko w razie potrzeby. W odniesieniu do wsparcia dla zewnętrznych rozszerzeń proponuje się zastosowanie podejścia projektów Clang i libc++;
- Wykorzystanie najlepszych praktyk w rozwoju z użyciem narzędzi LLVM, takich jak zastosowanie sanitizerów i testów fuzzerowych od samego początku.
Jeden z aktywnych programistów LLVM , że dostarczenie libc w składzie narzędziowego LLVM ma sens, ale zwykle w takiej sytuacji używa się biblioteki musl, która jest dobrze napisana, wspiera różne architektury i zapewnia niezbędną funkcjonalność, w tym obsługę linkowania dynamicznego. Uzasadnione może być wbudowanie musl w LLVM i rozwijanie go jako zsynchronizowanego z głównym projektem forka.
Swoją opinię również autor projektu Musl, który próbował uzasadnić, dlaczego propozycja Google i włączenie Libc do dostarczania LLVM są bardzo złymi pomysłami:
- Rozwój i wsparcie prawidłowego, kompatybilnego i wysokiej jakości Libc jest bardzo trudnym zadaniem. Problem nie leży w objętości kodu, lecz w zapewnieniu prawidłowego zachowania oraz trudności w realizacji interfejsów, biorąc pod uwagę ogromną liczbę wcześniej napisanych aplikacji w C/C++, a także aplikacji w innych językach, których runtime wykorzystuje Libc. Podejście bez uwzględnienia niuansów tylko doprowadzi do tego, że wiele istniejących programów nie będzie mogło współpracować z Libc, a taki projekt nie będzie interesujący dla użytkowników.
- Korporacyjny rozwój może zepsuć Libc, ale wprowadzić do szerokiego użytku, co skutkować będzie koniecznością dodawania hacków w celu zapewnienia kompatybilności w aplikacjach. Rozwój pod auspicjami korporacyjnego projektu open source będzie ciągnął w stronę potrzeb i rozwiązań firmy, kosztem interesów społeczności. Na przykład w przypadku wykrycia problemu spowodowanego błędem w innym swoim programie, w kontrolowanym rozwoju łatwiej zapewnić kompatybilność Libc z tym błędem, niż naprawić sam błąd. Apple w takich celach używa forka BSD libc, a Google stosuje fork musl w Fuchsia. Doświadczenie developera musl pokazuje, że kontaktowali się z nim głównie prawnicy w celu wyjaśnienia kwestii licencyjnych, ale nigdy nie pytali o szczegóły techniczne przed wprowadzeniem do swoich gałęzi bezużytecznych i zakłócających działanie zmian.
- Brak monokultury przy rozwijaniu libc oraz orientacja na rozwijane w oparciu o osiągnięcie konsensusu standardy, zamiast jednopersonalnego zarządzania, co motywuje twórców aplikacji do stosowania standardów, a nie przywiązywania się do konkretnych implementacji. Z tego powodu autor musl sprzeciwia się włączeniu swojej biblioteki do LLVM, podobnie jak sprzeciwia się rozwojowi libc w ramach LLVM, ponieważ w takim przypadku niezależny charakter libc zostaje utracony, a konkretna implementacja staje się rozwiązaniem pierwszej klasy dla LLVM, a wszystkie inne – drugiej.
Źródło: opennet.ru
