Google के डेवलपर्स ने LLVM के लिए अपना स्वयं का libc विकसित करने का सुझाव दिया

Google के डेवलपर्स में से एक उठा लिया एलएलवीएम प्रोजेक्ट के हिस्से के रूप में मल्टी-प्लेटफॉर्म मानक सी लाइब्रेरी (लिबसी) के विकास के बारे में एलएलवीएम मेलिंग सूची पर। कई कारणों से, Google वर्तमान libc (glibc, musl) से संतुष्ट नहीं है और कंपनी एक नया कार्यान्वयन विकसित करने की राह पर है, जिसे LLVM के भाग के रूप में विकसित करने का प्रस्ताव है।

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

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

परियोजना अभी भी विकास के प्रारंभिक चरण में है, लेकिन बुनियादी लक्ष्य पहले ही परिभाषित किए जा चुके हैं:

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

सक्रिय एलएलवीएम डेवलपर्स में से एक मेरे पास हैयह स्पष्ट है कि एलएलवीएम टूलकिट के हिस्से के रूप में libc को शिप करना समझ में आता है, लेकिन आमतौर पर, जब ऐसी आवश्यकता उत्पन्न होती है, तो वे मसल लाइब्रेरी का उपयोग करते हैं, जो अच्छी तरह से लिखा गया है, विभिन्न आर्किटेक्चर का समर्थन करता है, और गतिशील के लिए समर्थन सहित आवश्यक कार्यक्षमता प्रदान करता है लिंक करना. एलएलवीएम में मसल को एम्बेड करना और इसे मुख्य प्रोजेक्ट के साथ सिंक्रनाइज़ किए गए फोर्क के रूप में विकसित करना उचित हो सकता है।

आपकी भी राय उन्होंने व्यक्त मसल प्रोजेक्ट के लेखक, जिन्होंने यह तर्क देने की कोशिश की कि Google का प्रस्ताव और एलएलवीएम वितरण में लिबसी को शामिल करना बहुत बुरे विचार क्यों हैं:

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

स्रोत: opennet.ru