मैनपेज में कई अनुभाग हैं। उनमें से दो हैं:"सी सिस्टम कॉल" और "सी लाइब्रेरी दिनचर्या" के बीच क्या अंतर है?
2 Unix and C system calls 3 C Library routines for C programs
उदाहरण के लिए वहाँ है getmntinfo(3) और getfsstat(2), दोनों देखो की तरह वे एक ही बात करते हैं। किसी को कब उपयोग करना चाहिए और क्या अंतर है?
सिस्टम कॉल ऑपरेटिंग सिस्टम फ़ंक्शंस हैं, जैसे यूनिक्स, malloc() फ़ंक्शन sbrk() सिस्टम कॉल (प्रक्रिया मेमोरी स्पेस का आकार बदलने के लिए) के शीर्ष पर बनाया गया है।
पुस्तकालय केवल एप्लिकेशन कोड हैं जो ऑपरेटिंग सिस्टम का हिस्सा नहीं हैं और अक्सर एक से अधिक ओएस पर उपलब्ध होंगे। वे मूल रूप से आपके स्वयं के कार्यक्रम में फ़ंक्शन कॉल के समान होते हैं।
लाइन थोड़ा धुंधला हो सकता है लेकिन सिस्टम कॉल को कर्नेल-स्तरीय कार्यक्षमता के रूप में देखें।
सिस्टम कॉल उपयोगकर्ता-स्तर कोड और कर्नेल के बीच इंटरफ़ेस हैं। सी लाइब्रेरी दिनचर्या लाइब्रेरी कॉल किसी अन्य की तरह हैं, वे वास्तव में आमतौर पर प्रदान की जाती हैं (काफी सार्वभौमिक रूप से)। बहुत सारे मानक लाइब्रेरी दिनचर्या सिस्टम कॉल के चारों ओर रैपर (पतली या अन्यथा) होती हैं, जो रेखा को थोड़ा धुंधला करती हैं।
सामान्य नियम के रूप में, किसके लिए उपयोग करना है, उस व्यक्ति का उपयोग करें जो आपकी आवश्यकताओं के अनुरूप सर्वोत्तम है।
मैनुअल के सेक्शन 2 में वर्णित कॉल कर्नेल को जाल वाली सिस्टम सेवाओं के वास्तविक कॉल के आसपास अपेक्षाकृत पतली रैपर हैं। मैन्युअल के सेक्शन 3 में वर्णित सी मानक लाइब्रेरी दिनचर्या क्लाइंट-साइड लाइब्रेरी फ़ंक्शंस हैं जो वास्तव में सिस्टम कॉल का उपयोग कर सकती हैं या नहीं।
This posting में सिस्टम कॉल का विवरण है और कर्नेल (थोड़ा अलग संदर्भ में) में फंस रहा है और कुछ संदर्भों के साथ सिस्टम कॉल के पीछे अंतर्निहित तंत्र बताता है।
सामान्य कार्यों के पुस्तकालय सिस्टम कॉल इंटरफ़ेस के शीर्ष पर बनाए जाते हैं, लेकिन एप्लिकेशन दोनों का उपयोग करने के लिए स्वतंत्र हैं।
सिस्टम कॉल प्रमाणीकरण कुंजी की तरह हैं जिनके पास कर्नेल संसाधनों का उपयोग करने की पहुंच है।
छवि से ऊपर उन्नत लिनक्स प्रोग्रामिंग से है और समझने के लिए कैसे उपयोगकर्ता क्षुधा कर्नेल के साथ सहभागिता करने में सहायता।
एक सामान्य नियम के रूप में, आपको हमेशा सी पुस्तकालय संस्करण का उपयोग करना चाहिए। उनके पास अक्सर रैपर होते हैं जो गूढ़ चीजों को संभालते हैं जैसे सिग्नल पर पुनरारंभ होता है (यदि आपने अनुरोध किया है)। यह विशेष रूप से सच है यदि आप पहले ही लाइब्रेरी से जुड़े हुए हैं। सभी नियमों को तोड़ने के कारण हैं। प्रत्यक्ष कॉल का उपयोग करने के कारण,
libc अज्ञेयवादी बनना चाहते हैं; शायद एक इंस्टॉलर के साथ। इस तरह के कोड एंड्रॉइड (bionic), uClibc, और अधिक पारंपरिक glibc/eglibc सिस्टम पर चलाया जा सकता है, लाइब्रेरी का उपयोग किए बिना। इसके अलावा, एक दोहरी एंड्रॉइड/लिनक्स बाइनरी की अनुमति देने के लिए एक रन-टाइम ग्लिब/बायोनिक परत बनाने के लिए रैपर के साथ गतिशील लोडिंग।libc कभी-कभी कर सकता है।initramfs या init कोड लिख रहे हैं; एक छोटी छवि बनाने या तेजी से बूट करने के लिए।initramfs के समान ही।libc दिनचर्या का उपयोग करना चाहते हैं।libc में ज्ञात बग से बचने के लिए।libc के माध्यम से उपलब्ध नहीं है।क्षमा करें, अधिकांश उदाहरण लिनक्स विशिष्ट हैं, लेकिन राशन अन्य यूनिक्स रूपों पर लागू होना चाहिए। आखिरी वस्तु काफी आम है जब कर्नेल में नई विशेषताएं पेश की जाती हैं। उदाहरण के लिए जब kqueue या epoll जहां पहली बार पेश किया गया था, तो उन्हें समर्थन देने के लिए libc नहीं था। यह तब भी हो सकता है जब सिस्टम की पुरानी लाइब्रेरी है, लेकिन एक नया कर्नेल और आप इस कार्यक्षमता का उपयोग करना चाहते हैं।
यदि आपकी प्रक्रिया ने libc का उपयोग नहीं किया है, तो संभवतः सिस्टम में कुछ ऐसा होगा। अपने स्वयं के रूपों को कोड करके, आप एक ही अंत लक्ष्य के लिए दो पथ प्रदान करके कैश को अस्वीकार कर सकते हैं। इसके अलावा, यूनिक्स प्रक्रियाओं के बीच कोड पृष्ठों को साझा करेगा। आम तौर पर libc संस्करण का उपयोग न करने का कोई कारण नहीं है।
अन्य उत्तरों पहले से ही libc और सिस्टम कॉल के बीच अंतर पर एक तारकीय नौकरी कर चुके हैं।
भयानक तस्वीर। बहुत साफ़ – henryyao