Një nga zhvilluesit nga kompania Google në listën e postimeve LLVM temën e zhvillimit të një biblioteke standarde C shumëplatformëshe (Libc) në kuadër të projektit LLVM. Për një sërë arsyesh, Google nuk është i kënaqur me libc aktuale (glibc, musl) dhe kompania është në rrugën e zhvillimit të një implementimi të ri, i cili propozohet të zhvillohet si pjesë e LLVM.
Prodhimet e LLVM kohët e fundit po përdoren si bazë për ndërtimin e veglave të ndërtimit të Google. Ideja kryesore është se nëse Google ka filluar tashmë të zhvillojë libc-në e saj, pse të mos e zhvillojë menjëherë sistemin e saj brenda LLVM, i cili tashmë ofron bibliotekën e tij standarde për C++ (Libc++) por nuk ka një bibliotekë standarde të ngjashme për C (Libc).
Zhvillimi do të bëhet në etapa, duke rritur gradualisht funksionalitetin. Versionet e para propozohet të organizohen si një shtresë midis aplikacionit dhe Libc sistemike, nga e cila do të marrë mundësi që ende nuk janë realizuar. Pasi të arrihet një nivel i caktuar në funksionalitet, Libc e re do të jetë në gjendje të përdoret si një zëvendësim i plotë për Libc sistemike. Planifikimi fillon me mbështetje për arkitekturën x86-64, Linux dhe lidhjen statike (ngarkimi dinamik, kompozimi dhe arkitekturat shtesë do të realizohen në etapën e dytë).
Projekti është ende në fazën fillestare të zhvillimit, por janë përcaktuar tashmë qëllimet bazë:
- Modulariteti dhe zhvillimi sipas filozofisë së ofrimit të një biblioteke të granuluar, dhe jo një set monolit;
- Mbështetja e lidhjes statike në modulet me (ekzekutues të pavarur nga pozita) dhe pa PIE. Ofrimi i CRT (C runtime) dhe ngarkuesit PIE për skedarët ekzekutivë që lidhën statikisht;
- Mbështetje për shumicën e funksioneve të bibliotekës standarde C me shtesa POSIX dhe disa zgjerime specifike për sistemet që kërkohen në aplikacionet ekzistues.
- Një qasje e kujdesshme ndaj zgjerimeve specifike për prodhuesit dhe shtimi i tyre vetëm kur është e nevojshme. Për sa i përket mbështetjes për zgjerimet e palëve të treta, sugjerohet të aplikohet qasja e projekteve Clang dhe libc++;
- Përdorimi i praktikave më të mira në zhvillim me mjete të LLVM, si përdorimi i sanitizer dhe testimeve fuzzing nga fillimi.
Një nga zhvilluesit aktivë të LLVM , të cilat sugjerojnë se kalimi i libc si pjesë e mjetit LLVM ka kuptim, por zakonisht, në raste të tilla, përdoret biblioteka musl, e cila është shkruar me cilësi, mbështet arkitektura të ndryshme dhe ofron funksionalitetin e nevojshëm, përfshirë mbështetje për lidhjen dinamike. Integrimi i musl në LLVM dhe zhvillimi i tij si një fork i sinkronizuar me projektin kryesor mund të jetë i arsyeshëm.
Opinioni i tij gjithashtu autori i projektit Musl, i cili përpiqej të argumentonte pse propozimi i Google dhe përfshirja e Libc në përbërjen e LLVM janë ide jashtëzakonisht të këqija:
- Zhvillimi dhe mbështetje e saktë, e pajtueshme dhe me cilësi të lartë të Libc është një detyrë shumë e vështirë. Problemi nuk është në vëllimin e kodit, por në sigurimin e sjelljes së saktë dhe vështirësitë e implementimit të ndërfaqeve me parasysh shtresat e shumta të aplikacioneve të shkruara ndonjëherë në C/C++, si dhe aplikacioneve në gjuhë të tjera, runtime i të cilave përdor Libc. Një qasje e drejtpërdrejtë pa marrë parasysh nuancat do të çonte vetëm në faktin që shumë programe ekzistuese nuk do të ishin në gjendje të funksiononin me Libc, dhe në këtë rast një projekt i tillë nuk do të ishte i interesant për konsumatorët.
- Zhvillimi korporativ mund të dëmtojë Libc, por gjithashtu të lehtësojë përdorimin e gjerë, duke rezultuar në nevojën për të shtuar hack-a për të siguruar kompatibilitetin në aplikacione. Zhvillimi nën ombrellën e një projekti të hapur korporativ do të tërheqë vëmendjen në drejtim të nevojave dhe zgjidhjeve të kompanisë, në dëm të interesave të komunitetit. Për shembull, në rastin e identifikimit të një problemi, i cili shkaktohet nga një gabim në ndonjë program tjetër të saj, është më e lehtë të sigurohet kompatibiliteti i Libc me këtë gabim sesa të riparohet vetë gabimi. Apple përdor për këto qëllime një fork të BSD libc, ndërsa Google aplikon në Fuchsia një fork të musl. Eksperienca e zhvilluesit të musl tregon se ai është kontaktuar kryesisht nga avokatët për sqarime mbi çështjet e licencimit, por kurrë nuk është kërkuar për detajet teknike para se të përfshihen në degëzime ndryshime të padobishme dhe që dëmtojnë funksionimin.
- Mungesa e monokulturës në zhvillimin e libc dhe orientimi drejt standardeve të zhvilluara mbi arritjen e konsensusit, në vend të menaxhimit të vetëm, motivon zhvilluesit e aplikacioneve të aplikojnë standardet dhe të mos mbahen pas implementimeve të caktuara. Kjo është arsyeja pse autori i musl është kundër përfshirjes së bibliotekës së tij në LLVM, ashtu siç është kundër zhvillimit të libc brenda LLVM, pasi në këtë rast humbet karakteri i pavarur i libc dhe një implementim i caktuar bëhet zgjidhja e klasës së parë për LLVM, ndërsa të gjitha të tjerat mbeten të dytat.
Burimi: opennet.ru
