ProHoster > Blogs > interneta ziņas > Google izstrādātāji ieteica izstrādāt savu libc priekÅ” LLVM

Google izstrādātāji ieteica izstrādāt savu libc priekŔ LLVM

Viens no Google izstrādātājiem paaugstināts LLVM adresātu sarakstā par daudzplatformu standarta C bibliotēkas (Libc) izstrādi LLVM projekta ietvaros. Vairāku iemeslu dēļ Google nav apmierināts ar paÅ”reizējo libc (glibc, musl), un uzņēmums ir ceļā uz jaunas implementācijas izstrādi, kuru tiek piedāvāts izstrādāt LLVM ietvaros.

LLVM izstrāde nesen tika izmantota kā pamats Google montāžas rÄ«ku izveidei. Galvenā doma ir tāda, ka, ja Google jau ir sācis izstrādāt savu libc, tad kāpēc gan uzreiz neizstrādāt savu sistēmu kā daļu no LLVM, kas jau piedāvā savu standarta bibliotēku priekÅ” C++ (Libc++), bet tai nav lÄ«dzÄ«gas standarta bibliotēkas priekÅ” C. (libc).

Izstrādi plānots veikt pa posmiem, pakāpeniski palielinot funkcionalitāti. Pirmās opcijas tiek piedāvātas veidot kā slāni starp aplikāciju un sistēmu Libc, no kuras tiks aizņemtas vēl nerealizētas iespējas. Pēc noteikta funkcionalitātes lÄ«meņa sasniegÅ”anas jauno Libc var izmantot kā pilnÄ«gu sistēmas Libc aizstājēju. Mēs plānojam sākt ar x86-64 arhitektÅ«ras, Linux un statiskās saistÄ«Å”anas atbalstu (sekundāri tiks ieviesta dinamiskā ielāde, saistÄ«Å”ana un papildu arhitektÅ«ras).

Projekts vēl ir sākotnējā izstrādes stadijā, taču jau ir noteikti pamatmērķi:

  • Modularitāte un attÄ«stÄ«ba saskaņā ar granulētas bibliotēkas, nevis monolÄ«ta komplekta piegādes filozofiju;
  • Atbalsts statiskai saistÄ«Å”anai režīmos PIE (No pozÄ«cijas neatkarÄ«gi izpildāmie faili) un bez PIE. CRT (C izpildlaika) un PIE ielādēja nodroÅ”ināŔana statiski saistÄ«tiem izpildāmiem failiem;
  • Atbalsts lielākajai daļai standarta C bibliotēkas funkciju ar POSIX papildinājumiem un dažiem sistēmai specifiskiem paplaÅ”inājumiem, kas nepiecieÅ”ami esoÅ”ajām lietojumprogrammām;
  • Esiet piesardzÄ«gs ar pakalpojumu sniedzēja paplaÅ”inājumiem un pievienojiet tos tikai nepiecieÅ”amÄ«bas gadÄ«jumā. AttiecÄ«bā uz atbalstu treÅ”o puÅ”u paplaÅ”inājumiem tiek piedāvāts izmantot Clang un libc++ projektu pieeju;
  • Labākās prakses izmantoÅ”ana izstrādē, izmantojot LLVM rÄ«kkopu, piemēram, dezinfekcijas lÄ«dzekļa un izplÅ«des testÄ“Å”anas izmantoÅ”ana jau no paÅ”a sākuma.

Viens no aktÄ«vajiem LLVM izstrādātājiem norādÄ«jaIr skaidrs, ka ir jēga nosÅ«tÄ«t libc kā daļu no LLVM rÄ«ku komplekta, taču parasti, kad rodas Ŕāda vajadzÄ«ba, viņi izmanto musl bibliotēku, kas ir labi uzrakstÄ«ta, atbalsta dažādas arhitektÅ«ras un nodroÅ”ina nepiecieÅ”amo funkcionalitāti, tostarp atbalstu dinamiskai. saistÄ«Å”ana. Var bÅ«t pamatoti iegult musl LLVM un attÄ«stÄ«t to kā dakÅ”iņu, kas sinhronizēta ar galveno projektu.

Tavs viedoklis arÄ« izteikts Musl projekta autors, kurÅ” mēģināja argumentēt, kāpēc Google priekÅ”likums un Libc iekļauÅ”ana LLVM izplatÄ«Å”anā ir ļoti sliktas idejas:

  • Pareiza, saderÄ«ga un kvalitatÄ«va Libc izstrāde un uzturÄ“Å”ana ir ļoti grÅ«ts uzdevums. Problēma nav koda apjomā, bet pareizas uzvedÄ«bas nodroÅ”ināŔanā un saskarņu ievieÅ”anas grÅ«tÄ«bās, ņemot vērā milzÄ«go aplikāciju slāni, kas jebkad rakstÄ«ts C/C++ valodā, kā arÄ« aplikācijas citās valodās, kuru izpildlaiks tiek izmantots autors Libc. TieÅ”a pieeja, neņemot vērā nianses, novedÄ«s tikai pie tā, ka daudzas esoŔās programmas nespēs strādāt ar Libc, bet tad Ŕāds projekts patērētājus neinteresēs.
  • KorporatÄ«vā attÄ«stÄ«ba var sabojāt Libc, taču to var plaÅ”i izmantot, kā rezultātā ir jāpievieno uzlauzumi, lai nodroÅ”inātu lietojumprogrammu saderÄ«bu. AttÄ«stÄ«ba korporatÄ«vā atvērtā pirmkoda projekta aizgādÄ«bā virzÄ«s segu uz uzņēmuma vajadzÄ«bām un risinājumiem, kaitējot sabiedrÄ«bas interesēm. Piemēram, ja identificējat problēmu, ko izraisÄ«jusi kļūda citā programmā, kontrolētā izstrādē ir vieglāk nodroÅ”ināt Libc saderÄ«bu ar Å”o kļūdu, nevis labot paÅ”u kļūdu. Apple Å”iem nolÅ«kiem izmanto BSD libc dakÅ”iņu, un Google izmanto musl dakÅ”iņu fuksijā. Musl izstrādātāja pieredze liecina, ka ar viņu galvenokārt sazinājās juristi, lai noskaidrotu licencÄ“Å”anas jautājumus, taču viņŔ nekad nav sazinājies, lai noskaidrotu tehniskās detaļas, pirms veica bezjēdzÄ«gas un traucējoÅ”as izmaiņas viņa filiālēs.
  • MonokultÅ«ras trÅ«kums libc izstrādē un koncentrÄ“Å”anās uz vienprātÄ«giem standartiem, nevis vienpersonisku kontroli, kas motivē lietojumprogrammu izstrādātājus izmantot standartus, nevis bÅ«t piesaistÄ«tiem konkrētām implementācijām. TieÅ”i tāpēc musl autors ir pret savas bibliotēkas iekļauÅ”anu LLVM, kā arÄ« pret libc attÄ«stÄ«bu LLVM ietvaros, jo Å”ajā gadÄ«jumā zÅ«d libc neatkarÄ«gais raksturs un noteikta realizācija kļūst par pirmŔķirÄ«gu risinājumu LLVM, un visi pārējie kļūst par otrŔķirÄ«gu risinājumu.

Avots: opennet.ru

Pievieno komentāru