Google का विकासकर्ताहरूले LLVM का लागि आफ्नै libc विकास गर्न सुझाव दिए

Google बाट विकासकर्ताहरू मध्ये एक उठाएको LLVM परियोजनाको भागको रूपमा बहु-प्लेटफर्म मानक सी पुस्तकालय (Libc) को विकासको बारेमा LLVM मेलिङ सूचीमा। धेरै कारणहरूका लागि, Google हालको libc (glibc, musl) सँग सन्तुष्ट छैन र कम्पनीले नयाँ कार्यान्वयनको विकास गर्ने बाटोमा छ, जुन LLVM को भागको रूपमा विकास गर्न प्रस्ताव गरिएको छ।

LLVM विकासहरू हालै गुगलको असेंबली उपकरणहरू निर्माण गर्न आधारको रूपमा प्रयोग गरिएको छ। मुख्य विचार यो हो कि यदि गुगलले पहिले नै आफ्नो libc विकास गर्न थाल्यो भने, किन तुरुन्तै LLVM को भागको रूपमा आफ्नो प्रणाली विकास नगर्ने, जसले पहिले नै C++ (Libc++) को लागि आफ्नै मानक पुस्तकालय प्रदान गर्दछ, तर C को लागि समान मानक पुस्तकालय छैन। (libc)।

बिस्तारै कार्यक्षमता बढाउँदै चरणहरूमा विकास गर्ने योजना छ। पहिलो विकल्पहरू एप्लिकेसन र प्रणाली Libc बीचको तहको रूपमा डिजाइन गर्न प्रस्तावित छन्, जसबाट अझै कार्यान्वयन नगरिएका सुविधाहरू उधारो गरिनेछ। कार्यक्षमताको निश्चित स्तरमा पुगेपछि, नयाँ Libc लाई प्रणाली Libc को लागि पूर्ण प्रतिस्थापनको रूपमा प्रयोग गर्न सकिन्छ। हामी x86-64 आर्किटेक्चर, लिनक्स, र स्थिर लिङ्किङ (गतिशील लोडिङ, लिङ्किङ, र अतिरिक्त आर्किटेक्चरहरू दोस्रो रूपमा लागू गरिनेछ) को लागि समर्थनको साथ सुरु गर्ने योजना बनाउँछौं।

परियोजना अझै विकासको प्रारम्भिक चरणमा छ, तर आधारभूत लक्ष्यहरू पहिले नै परिभाषित गरिएको छ:

• मोनोलिथिक सेटको सट्टा ग्रेन्युलर लाइब्रेरी डेलिभर गर्ने दर्शन अनुसार मोडुलरिटी र विकास;
• मोडहरूमा स्थिर लिङ्किङको लागि समर्थन पाइ (स्थिति-स्वतन्त्र कार्यान्वयनयोग्य) र PIE बिना। CRT (C रनटाइम) र PIE लोडर स्थिर रूपमा लिङ्क गरिएको कार्यान्वयन योग्यहरूको लागि प्रदान गर्दै;
• POSIX थपहरू र अवस्थित अनुप्रयोगहरू द्वारा आवश्यक केही प्रणाली-विशिष्ट विस्तारहरू सहित धेरै मानक C पुस्तकालय कार्यहरूको लागि समर्थन;
• विक्रेता-विशिष्ट विस्तारहरूसँग सावधान रहनुहोस् र आवश्यक पर्दा मात्र तिनीहरूलाई थप्नुहोस्। तेस्रो-पक्ष विस्तारहरूको लागि समर्थनको सन्दर्भमा, यो क्ल्याङ्ग र libc++ परियोजनाहरूको दृष्टिकोण प्रयोग गर्न प्रस्ताव गरिएको छ;
• LLVM टूलकिट प्रयोग गरेर विकासमा उत्कृष्ट अभ्यासहरू प्रयोग गर्दै, जस्तै सेनिटाइजर प्रयोग गर्ने र फज परीक्षण सुरुदेखि नै।

सक्रिय LLVM विकासकर्ताहरू मध्ये एक औंल्याएयो स्पष्ट छ कि यसले LLVM टूलकिटको भागको रूपमा libc पठाउनको लागि अर्थ राख्छ, तर सामान्यतया, जब यस्तो आवश्यकता उत्पन्न हुन्छ, तिनीहरूले राम्रोसँग लेखिएको musl पुस्तकालय प्रयोग गर्दछ, विभिन्न वास्तुकलाहरूलाई समर्थन गर्दछ, र आवश्यक कार्यक्षमता प्रदान गर्दछ, जसमा गतिशीलका लागि समर्थन सहित। लिङ्क गर्दै। मसललाई LLVM मा इम्बेड गर्नु र यसलाई मुख्य परियोजनासँग सिङ्क्रोनाइज्ड फोर्कको रूपमा विकास गर्नु उचित हुन सक्छ।

तपाईको पनि बिचार व्यक्त गरे मुसल परियोजनाका लेखक, जसले गुगलको प्रस्ताव र LLVM वितरणमा Libc को समावेश गर्नु धेरै खराब विचारहरू हुन् भनेर तर्क गर्ने प्रयास गरे:

• सही, मिल्दो र उच्च गुणस्तरको Libc को विकास र मर्मत गर्नु धेरै गाह्रो काम हो। समस्या कोडको मात्रामा होइन, तर सही व्यवहार सुनिश्चित गर्न र इन्टरफेसहरू कार्यान्वयन गर्न कठिनाइहरू सुनिश्चित गर्नमा, C/C++ मा लेखिएका अनुप्रयोगहरूको विशाल तह, साथै अन्य भाषाहरूमा अनुप्रयोगहरू, जसको रनटाइम प्रयोग गरिन्छ। Libc द्वारा। सूक्ष्मताहरूलाई ध्यानमा नलिई हेड-अन दृष्टिकोणले मात्र यस तथ्यलाई निम्त्याउनेछ कि धेरै अवस्थित कार्यक्रमहरू Libc सँग काम गर्न सक्षम हुनेछैनन्, तर त्यसोभए यस्तो परियोजना उपभोक्ताहरूको लागि चासोको हुनेछैन।
• कर्पोरेट विकासले Libc लाई बर्बाद गर्न सक्छ, तर यसलाई व्यापक प्रयोगको लागि धक्का दिन्छ, परिणामस्वरूप अनुप्रयोगहरूमा अनुकूलता सुनिश्चित गर्न ह्याकहरू थप्न आवश्यक हुन्छ। एक कर्पोरेट खुला स्रोत परियोजना को आश्रय अन्तर्गत विकास कम्पनी को आवश्यकता र समाधान को लागी कम्प्लेट तान्नेछ, समुदाय को हित को हानि को लागी। उदाहरणका लागि, यदि तपाईंले अर्को कार्यक्रममा बगको कारणले भएको समस्या पहिचान गर्नुभयो भने, नियन्त्रित विकासमा यो बग समाधान गर्नु भन्दा Libc यो बगसँग उपयुक्त छ भनी सुनिश्चित गर्न सजिलो हुन्छ। Apple ले यी उद्देश्यका लागि BSD libc फोर्क प्रयोग गर्दछ, र Google ले Fuchsia मा musl fork प्रयोग गर्दछ। मुसल विकासकर्ताको अनुभव यो छ कि उहाँलाई मुख्यतया वकिलहरू द्वारा इजाजतपत्र समस्याहरू स्पष्ट गर्न सम्पर्क गरिएको थियो, तर उहाँका शाखाहरूमा बेकार र विघटनकारी परिवर्तनहरू गर्नु अघि प्राविधिक विवरणहरू स्पष्ट गर्न कहिल्यै सम्पर्क गरिएको थिएन।
• Libc विकासमा एकल संस्कृतिको अभाव र व्यक्तिगत नियन्त्रणको सट्टा सहमति-संचालित मापदण्डहरूमा फोकस, जसले अनुप्रयोग विकासकर्ताहरूलाई विशिष्ट कार्यान्वयनहरूमा बाँध्नुको सट्टा मानकहरू प्रयोग गर्न उत्प्रेरित गर्दछ। यसैले मुसलका लेखक LLVM मा आफ्नो पुस्तकालय समावेश गर्ने विरुद्ध छन्, साथै LLVM भित्र libc को विकासको विरुद्धमा छन्, किनकि यस अवस्थामा libc को स्वतन्त्र प्रकृति हराएको छ र एक निश्चित कार्यान्वयन पहिलो-स्तरीय समाधान हुन्छ। LLVM, र अरू सबै दोस्रो-कक्षा समाधान बन्छन्।

स्रोत: opennet.ru