Jeden z programistów z Google na liście mailingowej LLVM na temat rozwoju wieloplatformowej standardowej biblioteki C (Libc) w ramach projektu LLVM. Z wielu powodów Google nie jest usatysfakcjonowany obecną biblioteką libc (glibc, musl) i firma jest na dobrej drodze do opracowania nowej implementacji, która ma zostać opracowana w ramach LLVM.
Rozwój LLVM został ostatnio wykorzystany jako podstawa do tworzenia narzędzi montażowych Google. Główną ideą jest to, że skoro Google zaczął już rozwijać swoją bibliotekę libc, to dlaczego nie od razu opracować swojego systemu w ramach LLVM, który oferuje już własną bibliotekę standardową dla C++ (Libc++), ale nie posiada podobnej biblioteki standardowej dla C (biblioteka).
Rozwój planowany jest etapowo, stopniowo zwiększając funkcjonalność. Pierwsze warianty proponuje się zaprojektować jako warstwę pomiędzy aplikacją a systemem Libc, z której zostaną zapożyczone funkcjonalności, które nie zostały jeszcze zaimplementowane. Po osiągnięciu określonego poziomu funkcjonalności, nowy Libc może być używany jako kompletny zamiennik systemu Libc. Planujemy zacząć od obsługi architektury x86-64, Linuksa i łączenia statycznego (dynamiczne ładowanie, łączenie i dodatkowe architektury zostaną zaimplementowane w drugiej kolejności).
Projekt jest jeszcze w początkowej fazie rozwoju, ale podstawowe cele zostały już określone:
- Modułowość i rozwój zgodny z filozofią dostarczania biblioteki ziarnistej, a nie monolitycznego zestawu;
- Obsługa statycznego łączenia w trybach (Pliki wykonywalne niezależne od pozycji) i bez PIE. Udostępnianie CRT (środowisko wykonawcze C) i modułu ładującego PIE dla statycznie połączonych plików wykonywalnych;
- Obsługa większości standardowych funkcji biblioteki C, z dodatkami POSIX i niektórymi rozszerzeniami specyficznymi dla systemu wymaganymi przez istniejące aplikacje;
- Zachowaj ostrożność w przypadku rozszerzeń specyficznych dla dostawcy i dodawaj je tylko wtedy, gdy jest to konieczne. Jeśli chodzi o obsługę rozszerzeń stron trzecich, proponuje się wykorzystanie podejścia projektów Clang i libc++;
- Stosowanie najlepszych praktyk w rozwoju przy użyciu zestawu narzędzi LLVM, takich jak używanie środków dezynfekujących i testów fuzz od samego początku.
Jeden z aktywnych programistów LLVM Oczywiste jest, że ma sens dostarczanie biblioteki libc jako części zestawu narzędzi LLVM, ale zazwyczaj, gdy pojawia się taka potrzeba, korzystają z biblioteki musl, która jest dobrze napisana, obsługuje różne architektury i zapewnia niezbędną funkcjonalność, w tym obsługę dynamicznych łączenie. Uzasadnione może być osadzenie musla w LLVM i rozwinięcie go jako forka zsynchronizowanego z głównym projektem.
Twoja opinia również Autor projektu Musl, który próbował argumentować, dlaczego propozycja Google'a i włączenie Libc do dystrybucji LLVM to bardzo złe pomysły:
- Opracowanie i utrzymanie poprawnej, kompatybilnej i wysokiej jakości Libc jest bardzo trudnym zadaniem. Problem nie leży w ilości kodu, ale w zapewnieniu poprawności działania i trudnościach w implementacji interfejsów, biorąc pod uwagę ogromną warstwę aplikacji, jakie kiedykolwiek napisano w C/C++, a także aplikacji w innych językach, których środowisko uruchomieniowe jest wykorzystywane przez Libc. Bezpośrednie podejście bez uwzględnienia niuansów doprowadzi jedynie do tego, że wiele istniejących programów nie będzie mogło współpracować z Libc, ale wtedy taki projekt nie będzie interesujący dla konsumentów.
- Rozwój korporacyjny może zrujnować Libc, ale wprowadzi go do powszechnego użytku, co spowoduje konieczność dodania hacków, aby zapewnić kompatybilność w aplikacjach. Rozwój pod auspicjami korporacyjnego projektu open source będzie ściągał zasłonę w stronę potrzeb i rozwiązań firmy, ze szkodą dla interesów społeczności. Na przykład, jeśli zidentyfikujesz problem spowodowany błędem w innym programie, podczas kontrolowanego programowania łatwiej jest upewnić się, że Libc jest kompatybilny z tym błędem, niż naprawić sam błąd. Apple używa do tych celów forka libc BSD, a Google używa forka musl w języku Fuchsia. Z doświadczenia programisty musl wynika, że kontaktowali się z nim głównie prawnicy w celu wyjaśnienia kwestii licencyjnych, ale nigdy nie skontaktowano się z nim w celu wyjaśnienia szczegółów technicznych przed wprowadzeniem bezużytecznych i zakłócających zmiany w jego oddziałach.
- Brak monokultury w rozwoju bibliotek libc i skupienie się na standardach opartych na konsensusie, a nie na indywidualnej kontroli, co motywuje twórców aplikacji do korzystania ze standardów, a nie przywiązywania się do konkretnych implementacji. Dlatego autor musl jest przeciwny włączeniu swojej biblioteki do LLVM, a także rozwojowi libc w ramach LLVM, ponieważ w tym przypadku traci się niezależny charakter libc, a pewna implementacja staje się pierwszorzędnym rozwiązaniem dla LLVM i wszystkie inne stają się rozwiązaniem drugiej klasy.
Źródło: opennet.ru