व्याख्या_एलसीए2010 - क्लाउड में ऑनलाइन

कार्यक्रम:

नाम

व्याख्या_एलसीए2010 - कोई माध्यम नहीं मिला: जब पढ़ने का प्रयास बंद करने का समय हो strerror(3) एस
मन।

प्रेरणा

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

क्या यह इतना आसान हो सकता है?

त्रुटि संदेश as चालाकी
अच्छे त्रुटि संदेश अक्सर वे "एक प्रतिशत" कार्य होते हैं जो शेड्यूल के समय छूट जाते हैं
दबाव आपके प्रोजेक्ट को दबा देता है। हालाँकि, एक अच्छा त्रुटि संदेश बहुत बड़ा परिणाम दे सकता है,
उपयोगकर्ता के अनुभव में असमानुपातिक सुधार, जब उपयोगकर्ता भयभीत हो जाता है
अज्ञात क्षेत्र आमतौर पर सामना नहीं किया जाता है। यह कोई आसान काम नहीं है।

एक लार्वा प्रोग्रामर के रूप में, लेखक को (पूरी तरह से सटीक) त्रुटि वाली समस्या नहीं दिखी
इस तरह के संदेश:
फ़्लोटिंग अपवाद (कोर डंप)
जब तक वैकल्पिक गैर-प्रोग्रामर व्याख्या की ओर इशारा नहीं किया गया। लेकिन वह नहीं है
यूनिक्स त्रुटि संदेशों में केवल एक चीज गलत है। आप कितनी बार त्रुटि संदेश देखते हैं जैसे:
$ ।/मूर्ख
फ़ाइल नहीं खुल सकती
$
इस बिंदु पर डेवलपर के लिए दो विकल्प हैं:

1.
आप डिबगर चला सकते हैं, जैसे कि जी.डी.बी.(1), या

2.
आप उपयोग कर सकते हैं स्ट्रेस(1) या पुलिंदा(1)अंदर देखना.

· याद रखें कि आपके उपयोगकर्ताओं के पास इन उपकरणों तक पहुंच भी नहीं हो सकती है, क्षमता तो दूर की बात है
उनका उपयोग करने के लिए. (तब से यह बहुत लंबा समय है यूनिक्स नौसिखिया मतलब “केवल लिखा है।” एक
डिवाइस ड्राइवर"।)

हालाँकि, इस उदाहरण में, का उपयोग कर रहे हैं स्ट्रेस(1) प्रकट करता है
$ स्ट्रेस -e ट्रेस = खुला ।/मूर्ख
open("कुछ/फ़ाइल", O_RDONLY) = -1 ENOENT (ऐसी कोई फ़ाइल या निर्देशिका नहीं)
फ़ाइल नहीं खुल सकती
$
यह त्रुटि संदेश द्वारा प्रदान की गई जानकारी से काफी अधिक जानकारी है। आमतौर पर,
मूर्खतापूर्ण स्रोत कोड इस तरह दिखता है
int fd = खुला("कुछ", O_RDONLY);
यदि (एफडी < 0)
{
fprintf(stderr, "फ़ाइल नहीं खोल सकता\n");
निकास; (1)
}
उपयोगकर्ता को नहीं बताया गया है कौन कौन से फ़ाइल, और उपयोगकर्ता को बताने में भी विफल रहती है कौन कौन से गलती। फ़ाइल थी
वहाँ पर भी? क्या कोई अनुमति समस्या थी? यह आपको बताता है कि यह खोलने का प्रयास कर रहा था
फ़ाइल, लेकिन वह संभवतः दुर्घटनावश था।

अपना क्लू स्टिक पकड़ें और उससे लार्वा प्रोग्रामर को हराएं। उसके बारे में बताओ आतंक(3).
अगली बार जब आप प्रोग्राम का उपयोग करेंगे तो आपको एक भिन्न त्रुटि संदेश दिखाई देगा:
$ ।/मूर्ख
खुला: ऐसी कोई फ़ाइल या निर्देशिका नहीं
$
प्रगति, लेकिन वह नहीं जिसकी हमें उम्मीद थी। त्रुटि संदेश आने पर उपयोगकर्ता समस्या को कैसे ठीक कर सकता है
उसे यह नहीं बताता कि समस्या क्या थी? स्रोत को देखते हुए, हम देखते हैं
int fd = खुला("कुछ", O_RDONLY);
यदि (एफडी < 0)
{
पेरर ("खुला");
निकास; (1)
}
सुराग छड़ी के साथ एक और दौड़ का समय। इस बार, त्रुटि संदेश एक कदम उठाता है
आगे और एक कदम पीछे:
$ ।/मूर्ख
कुछ: ऐसी कोई फ़ाइल या डायरेक्टरी नहीं है
$
अब हम उस फ़ाइल को जानते हैं जिसे वह खोलने का प्रयास कर रहा था, लेकिन अब हमें यह जानकारी नहीं है कि वह खुल रही थी खुला(2)
वह असफल रहा. इस मामले में यह संभवतः महत्वपूर्ण नहीं है, लेकिन यह महत्वपूर्ण हो सकता है
अन्य सिस्टम कॉल. यह भी हो सकता है मूल्य बना(2) इसके बजाय, एक ऑपरेशन जिसका अर्थ है
विभिन्न अनुमतियाँ आवश्यक हैं.
स्थिरांक चार * फ़ाइल नाम = "कुछ";
int fd = खुला (फ़ाइल नाम, O_RDONLY);
यदि (एफडी < 0)
{
पेरर(फ़ाइल नाम);
निकास; (1)
}
उपरोक्त उदाहरण कोड दुर्भाग्य से गैर-लार्वा प्रोग्रामर के लिए भी विशिष्ट है। समय
हमारे पदावन शिक्षार्थी को इसके बारे में बताने के लिए strerror(3) सिस्टम कॉल.
$ ।/मूर्ख
खुला कुछ: ऐसी कोई फ़ाइल या डायरेक्टरी नहीं है
$
यह उपयोगकर्ता के समक्ष प्रस्तुत की जा सकने वाली जानकारी को अधिकतम करता है। कोड जैसा दिखता है
इस:
स्थिरांक चार * फ़ाइल नाम = "कुछ";
int fd = खुला (फ़ाइल नाम, O_RDONLY);
यदि (एफडी < 0)
{
fprintf(stderr, "open %s: %s\n", फ़ाइल नाम, strerror(errno));
निकास; (1)
}
अब हमारे पास सिस्टम कॉल, फ़ाइल नाम और त्रुटि स्ट्रिंग है। इसमें सब कुछ शामिल है
जानकारी है कि स्ट्रेस(1) मुद्रित। यह उतना ही अच्छा है जितना इसे मिलता है।

या यह है?

सीमाओं of आतंक और strerror
1980 के दशक में लेखक ने जो समस्या देखी, वह यह थी कि त्रुटि संदेश अधूरा है।
क्या "ऐसी कोई फ़ाइल या निर्देशिका" का संदर्भ नहीं है?कुछ"निर्देशिका, या "बात" में फाइल
"कुछ" निर्देशिका?

इसके लिए मैन पेज पर एक त्वरित नज़र डालें strerror(3) बता रहा है:
strerror - त्रुटि संख्या का वर्णन करने वाली रिटर्न स्ट्रिंग
ध्यान दें: यह त्रुटि का वर्णन कर रहा है संख्या, त्रुटि नहीं.

दूसरी ओर, कर्नेल जानता है त्रुटि क्या थी. में एक खास बात थी
कर्नेल कोड, एक विशिष्ट स्थिति के कारण होता है, जहां कर्नेल कोड शाखाबद्ध होता है और "नहीं" कहता है।
क्या कोई उपयोगकर्ता-अंतरिक्ष प्रोग्राम विशिष्ट स्थिति का पता लगा सकता है और एक बेहतर त्रुटि लिख सकता है
संदेश?

हालाँकि, समस्या और भी गहरी हो गई है। यदि समस्या इस दौरान होती है तो क्या होगा? पढ़ना(2) तंत्र
के बजाय कॉल करें खुला(2) बुलाओ? इससे जुड़े त्रुटि संदेश के लिए यह सरल है
खुला(2) फ़ाइल नाम शामिल करने के लिए, यह वहीं है। लेकिन फ़ाइल नाम शामिल करने में सक्षम होने के लिए
से जुड़ी त्रुटि में पढ़ना(2) सिस्टम कॉल, आपको फ़ाइल नाम सभी को पास करना होगा
कॉल स्टैक के नीचे का रास्ता, साथ ही फ़ाइल डिस्क्रिप्टर।

और यहां वह बिट है जो ग्रेट करता है: कर्नेल को पहले से ही पता है कि फ़ाइल का नाम क्या है
डिस्क्रिप्टर सम्बंधित है. एक प्रोग्रामर को अनावश्यक डेटा क्यों पास करना चाहिए?
केवल एक त्रुटि संदेश को सुधारने के लिए कॉल स्टैक को नीचे लाने का तरीका जो कभी जारी नहीं किया जा सकता है? में
वास्तविकता, कई प्रोग्रामर परेशान नहीं होते हैं, और परिणामी त्रुटि संदेश उनके लिए और भी बदतर हैं
यह।

लेकिन वह 1980 का दशक था, पीडीपी11 पर, सीमित संसाधनों और कोई साझा पुस्तकालय नहीं था। पीछे
फिर, यूनिक्स का कोई स्वाद शामिल नहीं है / proc यहां तक ​​कि प्रारंभिक रूप में भी, और एलसोफे(1) कार्यक्रम
एक दशक से अधिक दूर था. इसलिए इस विचार को अव्यावहारिक बताकर टाल दिया गया।

स्तर अनन्तता सहायता
कल्पना करें कि आप स्तर अनंत समर्थन हैं। आपकी नौकरी का विवरण कहता है कि आप कभी नहीं
कभी उपयोगकर्ताओं से बात करनी होगी. तो फिर, अभी भी चाहने वाले लोगों का तांता क्यों लगा रहता है?
आप, स्थानीय यूनिक्स गुरु, एक और त्रुटि संदेश को समझने के लिए?

आश्चर्यजनक रूप से, 25 साल बाद, एक सरल अनुमति प्रणाली के बावजूद, इसे पूर्णता के साथ लागू किया गया
स्थिरता, अधिकांश यूनिक्स उपयोगकर्ताओं को अभी भी पता नहीं है कि "ऐसी कोई फ़ाइल या निर्देशिका नहीं" को कैसे डिकोड किया जाए।
या कोई अन्य गुप्त त्रुटि संदेश जो वे हर दिन देखते हैं। या, कम से कम, गूढ़
उन्हें.

क्या यह अच्छा नहीं होगा यदि प्रथम स्तर के तकनीकी समर्थन के लिए त्रुटि संदेशों को समझने की आवश्यकता न हो?
क्या यह अच्छा नहीं होगा कि ऐसे त्रुटि संदेश हों जिन्हें उपयोगकर्ता बिना कॉल किए समझ सकें
तकनीकी समर्थन?

इन दिनों / proc लिनक्स डिकोड करने के लिए आवश्यक जानकारी प्रदान करने में सक्षम है
अधिकांश त्रुटि संदेश, और उपयोगकर्ता को उनके संभावित कारण की ओर संकेत करते हैं
संकट। सीमित वाले सिस्टम पर / proc कार्यान्वयन, एलसोफे(1) कमांड भर सकते हैं
बहुत सारे अंतराल.

2008 में, लेखक के पास अनुवाद अनुरोधों का सिलसिला बहुत बार हुआ। वह था
उस 25 साल पुराने विचार की फिर से जाँच करने का समय आ गया है, और libexplain उसका परिणाम है।

का उपयोग करते हुए THE लाइब्रेरी

जहां संभव हो, लाइब्रेरी का इंटरफ़ेस सुसंगत रहने का प्रयास करता है। आइये एक से शुरू करते हैं
उदाहरण का उपयोग करना strerror(3)
यदि (नाम बदलें (पुराना_पथ, नया_पथ) < 0)
{
fprintf(stderr, "%s %s का नाम बदलें: %s\n", पुराना_पथ, नया_पथ,
strerror(errno));
निकास; (1)
}
Libexplain के पीछे का विचार एक प्रदान करना है strerror(3) के लिए समतुल्य से प्रत्येक सिस्टम कॉल,
विशेष रूप से उस सिस्टम कॉल के अनुरूप बनाया गया है, ताकि यह अधिक विस्तृत त्रुटि प्रदान कर सके
संदेश, जिसमें अधिकांश जानकारी आपको अनुभाग के "त्रुटियाँ" शीर्षक के अंतर्गत दिखाई देती है
2 और 3 आदमी पृष्ठ, वास्तविक स्थितियों, वास्तविक तर्क के बारे में जानकारी के साथ पूरक
मूल्य, और सिस्टम सीमाएँ।

RSI सरल मामला
RSI strerror(3) प्रतिस्थापन:
यदि (नाम बदलें (पुराना_पथ, नया_पथ) < 0)
{
fprintf(stderr, "%s\n", explore_rename(old_path, new_path));
निकास; (1)
}

RSI एर्नो मामला
स्पष्ट पारित करना भी संभव है गलत(3) मूल्य, यदि आपको पहले कुछ करना है
प्रसंस्करण जो परेशान करेगा गलत, जैसे त्रुटि पुनर्प्राप्ति:
यदि (नाम बदलें(पुराना_पथ, नया_पथ < 0))
{
int Old_errno = errno;
...कोड कि परेशान गलत...
fprintf(stderr, "%s\n", explore_errno_rename(old_errno,
पुराना_पथ, नया_पथ));
निकास; (1)
}

RSI अनेक परतदार केसेस
कुछ एप्लिकेशन मल्टी-थ्रेडेड हैं, और इस प्रकार लिबएक्सप्लेन के आंतरिक भाग को साझा करने में असमर्थ हैं
बफ़र. आप अपने स्वयं के बफर का उपयोग करके आपूर्ति कर सकते हैं
यदि (अनलिंक(पथनाम))
{
चार संदेश[3000];
व्याख्या_संदेश_अनलिंक(संदेश, इस आकार का(संदेश), पथनाम);
त्रुटि_संवाद(संदेश);
वापसी -1;
}
और संपूर्णता के लिए, दोनों गलत(3) और थ्रेड-सुरक्षित:
ssize_t nbytes = read(fd, data, sizeof(data));
यदि (nbytes < 0)
{
चार संदेश[3000];
int Old_errno = errno;
...त्रुटि वसूली...
व्याख्या_संदेश_त्रुटि_पढ़ें(संदेश, इस आकार का(संदेश),
Old_errno, fd, डेटा, sizeof(डेटा));
त्रुटि_संवाद(संदेश);
वापसी -1;
}

ये इनके लिए प्रतिस्थापन हैं strerror_r(3), उन प्रणालियों पर जिनमें यह है।

इंटरफेस चीनी
प्रोग्रामर्स को उपयोग करने के लिए लुभाने के लिए सुविधा कार्यों के रूप में कार्यों का एक सेट जोड़ा गया
libexplain पुस्तकालय, लेखक का सबसे अधिक उपयोग किया जाने वाला libexplain फ़ंक्शन बन गया है
कमांड लाइन प्रोग्राम:
int fd = explore_creat_or_die(फ़ाइल नाम, 0666);
यह फ़ंक्शन एक नई फ़ाइल बनाने का प्रयास करता है। यदि ऐसा नहीं हो पाता है, तो यह एक त्रुटि संदेश प्रिंट करता है
EXIT_FAILURE के साथ बाहर निकलता है। यदि कोई त्रुटि नहीं है, तो यह नया फ़ाइल डिस्क्रिप्टर लौटाता है।

एक संबंधित कार्य:
int fd = व्याख्या_क्रिएट_ऑन_त्रुटि (फ़ाइल नाम, 0666);
विफलता पर त्रुटि संदेश प्रिंट करेगा, लेकिन मूल त्रुटि परिणाम भी लौटाएगा, और
गलत(3) छेड़छाड़ रहित भी है।

सब la अन्य प्रणाली कॉल
सामान्य तौर पर, प्रत्येक सिस्टम कॉल की अपनी स्वयं की सम्मिलित फ़ाइल होती है
#शामिल करनानाम.h>
यह छह कार्यों के लिए फ़ंक्शन प्रोटोटाइप को परिभाषित करता है:

· व्याख्या करना_नाम,

· व्याख्या_त्रुटि_नाम,

· व्याख्या_संदेश_नाम,

· व्याख्या_संदेश_त्रुटि_नाम,

· व्याख्या करना_नाम_या_मरो और

· व्याख्या करना_नाम_त्रुटि पर.

प्रत्येक फ़ंक्शन प्रोटोटाइप में डॉक्सीजन दस्तावेज़ीकरण और यह दस्तावेज़ीकरण होता है is नहीं छीन लिया
जब शामिल फ़ाइलें स्थापित की जाती हैं।

RSI प्रतीक्षा(2) सिस्टम कॉल (और दोस्तों) के कुछ अतिरिक्त प्रकार हैं जो विफलता की व्याख्या भी करते हैं
एक निकास स्थिति होना जो EXIT_SUCCESS नहीं है। यह इस पर लागू होता है प्रणाली(3) और pबंद करें(3) के रूप में
अच्छी तरह से।

कवरेज में 221 सिस्टम कॉल और 547 ioctl अनुरोध शामिल हैं। और भी कई सिस्टम हैं
कार्यान्वयन के लिए कॉल अभी बाकी है। सिस्टम कॉल जो कभी वापस नहीं आतीं, जैसे निकास(2), मौजूद नहीं हैं
पुस्तकालय में, और कभी नहीं होगा। कार्यकारी सिस्टम कॉल का परिवार रहे समर्थित, क्योंकि
कोई त्रुटि होने पर वे लौट आते हैं।

बिल्ली
पूर्ण त्रुटि रिपोर्टिंग के साथ एक काल्पनिक "बिल्ली" कार्यक्रम इस तरह दिख सकता है,
libexplain का उपयोग करना।
#शामिल करना
#शामिल
#शामिल करना
इसमें लिबएक्सप्लेन के अलावा सामान्य संदिग्धों के लिए भी एक शामिल है। (यदि आप कम करना चाहते हैं
प्रीप्रोसेसर लोड, आप विशिष्ट का उपयोग कर सकते हैंनाम.h> शामिल है।)
स्थिर शून्य
प्रक्रिया(फ़ाइल*fp)
{
के लिए (;;)
{
चार बफ़र[4096];
साइज_टी एन = एक्सप्लेन_फ्रेड_ऑर_डाई(बफर, 1, साइजऑफ(बफर), एफपी);
यदि (!n)
तोड़;
व्याख्या_fwrite_or_die(बफ़र, 1, n, stdout);
}
}
RSI प्रक्रिया फ़ंक्शन फ़ाइल स्ट्रीम को मानक आउटपुट पर कॉपी करता है। क्या कोई त्रुटि होनी चाहिए
पढ़ने या लिखने के लिए, इसकी रिपोर्ट की जाती है (और पथनाम इसमें शामिल किया जाएगा)।
त्रुटि) और आदेश EXIT_FAILURE के साथ बाहर निकलता है। हमें ट्रैकिंग की भी चिंता नहीं है
पथनाम, या उन्हें कॉल स्टैक के नीचे भेजना।
int
मुख्य(int argc, char **argv)
{
के लिए (;;)
{
int c = getopt(argc, argv, "o:");
अगर (सी == ईओएफ)
तोड़;
स्विच (सी)
{
केस 'ओ':
व्याख्या_फ़्रीओपन_या_डाई(ऑप्टार्ग, "डब्ल्यू", स्टडआउट);
तोड़;
इस कोड का मज़ेदार हिस्सा यह है कि libexplain त्रुटियों की रिपोर्ट कर सकता है समेत la पथ नाम भी
आप अगर नहीं है स्पष्ट रूप से स्टडआउट को फिर से खोलें जैसा कि यहां किया गया है। हमें इसकी चिंता भी नहीं है
फ़ाइल नाम को ट्रैक करना।
चूक:
fprintf(stderr, "उपयोग: %ss [ -o ] ...\एन",
argv[0]);
वापसी EXIT_FAILURE;
}
}
यदि (optind == argc)
प्रक्रिया(stdin);
अन्य
{
जबकि (ऑप्टिंड <argc)
{
फ़ाइल *fp = व्याख्या_fopen_or_die(argv[optind]++, "r");
प्रक्रिया(एफपी);
व्याख्या_fclose_or_die(fp);
}
}
मानक आउटपुट परोक्ष रूप से बंद कर दिया जाएगा, लेकिन त्रुटि रिपोर्ट आने के लिए बहुत देर हो चुकी है
जारी किया गया है, इसलिए हम यहां ऐसा करते हैं, यदि बफ़र किए गए I/O ने अभी तक कुछ भी नहीं लिखा है, और
कोई ENOSPC त्रुटि या कुछ और है।
व्याख्या_फ़लश_या_डाई(स्टडआउट);
वापसी EXIT_SUCCESS;
}
बस इतना ही। पूर्ण त्रुटि रिपोर्टिंग, स्पष्ट कोड।

जंग खाए हुए स्केल of इंटरफेस अच्छाई
आपमें से जो लोग इससे परिचित नहीं हैं, उनके लिए रस्टी रसेल की "हाउ डू आई मेक दिस हार्ड टू मिसयूज?"
एपीआई डिजाइनरों के लिए पेज अवश्य पढ़ें।
http://ozlabs.org/~rusty/index.cgi/tech/2008‐03‐30.html

10. आईटी इस असंभव सेवा मेरे मिल गलत।

लक्ष्य ऊँचे, महत्त्वाकांक्षी ऊँचे निर्धारित करने की ज़रूरत है, ऐसा न हो कि आप उन्हें पूरा कर लें और सोचें कि आप हैं
ख़त्म जब तुम नहीं हो.

लिबएक्सप्लेन लाइब्रेरी फर्जी पॉइंटर्स और कई अन्य फर्जी सिस्टम कॉल पैरामीटर का पता लगाती है,
और आम तौर पर सबसे कठिन परिस्थितियों में भी सेगफॉल्ट से बचने की कोशिश करता है।

लिबएक्सप्लेन लाइब्रेरी को थ्रेड सुरक्षित बनाने के लिए डिज़ाइन किया गया है। अधिक वास्तविक-विश्व उपयोग की संभावना होगी
उन स्थानों का खुलासा करें जिनमें सुधार किया जा सकता है।

सबसे बड़ी समस्या वास्तविक फ़ंक्शन नामों के साथ है। क्योंकि C के पास नहीं है
नाम-स्थान, लिबएक्सप्लेन लाइब्रेरी हमेशा एक एक्सप्लेन_ नाम उपसर्ग का उपयोग करती है। यह है
प्रतीक टकराव से बचने के लिए छद्म-नाम-स्थान बनाने का पारंपरिक तरीका।
हालाँकि, इसके परिणामस्वरूप कुछ अप्राकृतिक-ध्वनि वाले नाम सामने आते हैं।

9. RSI संकलक or संयोजक नहीं होगा चलो इसलिए आप मिल it गलत।

एक सामान्य गलती है जहाँ explore_open_or_die का इरादा था वहां explore_open का उपयोग करना।
सौभाग्य से, कंपाइलर अक्सर इस बिंदु पर एक प्रकार की त्रुटि जारी करेगा (जैसे असाइन नहीं कर सकते
const char * rvalue से int lvalue)।

8. RSI संकलक मर्जी चेतावनी देना if इसलिए आप मिल it गलत।

यदि एक्सप्लेन_रीनेम का उपयोग तब किया जाता है जब एक्सप्लेन_रीनेम_ऑर_डाई का इरादा था, तो यह अन्य कारण पैदा कर सकता है
समस्या। जीसीसी में एक उपयोगीwarn_unused_result फ़ंक्शन विशेषता और libexplain है
लाइब्रेरी इसे सभी व्याख्याओं से जोड़ती है_नाम जब आप चेतावनी उत्पन्न करने के लिए फ़ंक्शन कॉल करते हैं
ये गलती करो. इसे इसके साथ मिलाएं जीसीसी -आतंक इसे स्तर 9 की अच्छाई तक बढ़ावा देने के लिए।

7. RSI स्पष्ट उपयोग is (शायद) la सही एक।

फ़ंक्शन नाम उनका अर्थ बताने के लिए चुने गए हैं, लेकिन ऐसा हमेशा नहीं होता है
सफल। समझाते समय_नाम_या_मर जाओ और समझाओ_नाम_on_error काफी वर्णनात्मक हैं,
कम उपयोग किए जाने वाले थ्रेड सुरक्षित वेरिएंट को डिकोड करना कठिन होता है। फ़ंक्शन प्रोटोटाइप मदद करते हैं
समझने की दिशा में संकलक, और हेडर फ़ाइलों में डॉक्सिजन टिप्पणियाँ उपयोगकर्ता की मदद करती हैं
समझने की ओर.

6. RSI नाम बताता है इसलिए आप कैसे सेवा मेरे उपयोग यह।

व्याख्या पढ़ना विशेष रूप से महत्वपूर्ण है_नाम_या_मरें "स्पष्ट करें" के रूप में (नाम या मरो)"।
लगातार व्याख्या_नाम-स्पेस उपसर्ग का उपयोग करने से कुछ दुर्भाग्यपूर्ण दुष्प्रभाव होते हैं
स्पष्टता विभाग, साथ ही।

नामों में शब्दों का क्रम तर्कों के क्रम को भी दर्शाता है। तर्क
सूचियाँ हमेशा समाप्त सिस्टम कॉल को दिए गए समान तर्कों के साथ; सब of उन. अगर
_errno_ नाम में दिखाई देता है, इसका तर्क हमेशा सिस्टम कॉल तर्क से पहले होता है। अगर
_message_ नाम में दिखाई देता है, इसके दो तर्क हमेशा पहले आते हैं।

5. Do it सही or it मर्जी तोड़ना at रनटाइम।

लिबएक्सप्लेन लाइब्रेरी फर्जी पॉइंटर्स और कई अन्य फर्जी सिस्टम कॉल पैरामीटर का पता लगाती है,
और आम तौर पर सबसे कठिन परिस्थितियों में भी सेगफॉल्ट से बचने की कोशिश करता है। आवश्यक
रनटाइम पर कभी भी ब्रेक न लगाएं, लेकिन अधिक वास्तविक दुनिया के उपयोग से निस्संदेह इसमें सुधार होगा।

कुछ त्रुटि संदेश अंतिम उपयोगकर्ताओं के बजाय डेवलपर्स और अनुरक्षकों के लिए लक्षित होते हैं
बग समाधान में सहायता कर सकता है. इतना अधिक "रनटाइम पर ब्रेक" नहीं बल्कि "जानकारीपूर्ण होना"।
रनटाइम" (सिस्टम कॉल बार्फ़्स के बाद)।

4. का पालन करें सामान्य सम्मेलन और आप करेंगे मिल it सही।

क्योंकि C में नाम-स्थान नहीं है, लिबएक्सप्लेन लाइब्रेरी हमेशा एक एक्सप्लेन_ नाम का उपयोग करती है
उपसर्ग. इससे बचने के लिए छद्म-नाम-स्थान बनाने का यह पारंपरिक तरीका है
प्रतीक संघर्ष.

सभी libexplain कॉल के अनुगामी तर्क सिस्टम कॉल के समान हैं
वर्णन कर रहे हैं. इसका उद्देश्य समान रूप से एक सुसंगत सम्मेलन प्रदान करना है
सिस्टम स्वयं को कॉल करता है।

3. पढ़ना la दस्तावेज़ीकरण और आप करेंगे मिल it सही।

लिबएक्सप्लेन लाइब्रेरी का लक्ष्य प्रत्येक के लिए संपूर्ण डॉक्सीजन दस्तावेज़ीकरण करना है
सार्वजनिक एपीआई कॉल (और आंतरिक रूप से भी)।

संदेश कंटेंट

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

हमारे पहले उदाहरण पर दोबारा गौर करते हुए, यदि यह libexplain का उपयोग करता है तो कोड को यह पसंद आएगा:
int fd = explore_open_or_die("कुछ/चीज़", O_RDONLY, 0);
इस तरह के त्रुटि संदेश के साथ विफल हो जाएगा
open(pathname = "some/file", flags = O_RDONLY) विफल, ऐसी कोई फ़ाइल या निर्देशिका नहीं
(2, ENOENT) क्योंकि वर्तमान निर्देशिका में कोई "कुछ" निर्देशिका नहीं है
यह तीन टुकड़ों में टूट जाता है
सिस्टम-कॉल असफल, सिस्टम त्रुटि क्योंकि
स्पष्टीकरण

से पहले क्योंकि
संदेश के भाग को "क्योंकि" से पहले देखना अत्यधिक तकनीकी से लेकर गैर-तकनीकी के रूप में देखना संभव है।
तकनीकी उपयोगकर्ता, ज्यादातर सिस्टम कॉल को सटीक रूप से प्रिंट करने के परिणामस्वरूप ही कॉल करते हैं
त्रुटि संदेश की शुरुआत. और ऐसा दिखता है स्ट्रेस(1) आउटपुट, बोनस गीक के लिए
अंक.
open(pathname = "some/file", flags = O_RDONLY) विफल, ऐसी कोई फ़ाइल या निर्देशिका नहीं
(2, एनोएंट)
त्रुटि संदेश का यह भाग डेवलपर के लिए आवश्यक है जब वह कोड लिख रहा हो,
और अनुरक्षक के लिए भी उतना ही महत्वपूर्ण है जिसे बग रिपोर्ट पढ़ना है और बग को ठीक करना है
कोड. यह बिल्कुल वही बताता है जो असफल हुआ।

यदि यह पाठ उपयोगकर्ता के सामने प्रस्तुत नहीं किया जाता है तो उपयोगकर्ता इसे कॉपी-पेस्ट नहीं कर सकता है
बग रिपोर्ट, और यदि यह बग रिपोर्ट में नहीं है तो अनुरक्षक यह नहीं जान सकता कि वास्तव में क्या हुआ
गलत।

अक्सर तकनीकी कर्मचारी उपयोग करेंगे स्ट्रेस(1) या पुलिंदा(1) यह सटीक जानकारी प्राप्त करने के लिए, लेकिन
बग रिपोर्ट पढ़ते समय यह रास्ता खुला नहीं है। बग रिपोर्टर का सिस्टम बहुत दूर है
दूर, और, अब तक, एक बहुत अलग स्थिति में। इस प्रकार, यह जानकारी इसमें होनी चाहिए
बग रिपोर्ट, जिसका अर्थ है कि यह त्रुटि संदेश में होनी चाहिए।

सिस्टम कॉल प्रतिनिधित्व शेष संदेश को भी संदर्भ देता है। जरूरत है अगर
उत्पन्न होने पर, आपत्तिजनक सिस्टम कॉल तर्क को स्पष्टीकरण में नाम से संदर्भित किया जा सकता है
"क्योंकि" के बाद. इसके अलावा, सभी स्ट्रिंग पूरी तरह से उद्धृत हैं और सी स्ट्रिंग से बच गए हैं
एम्बेडेड न्यूलाइन और गैर-प्रिंटिंग वर्ण उपयोगकर्ता के टर्मिनल को बंद नहीं करेंगे
हेवायर।

RSI सिस्टम त्रुटि वही है जो बाहर आता है strerror(2), साथ ही त्रुटि चिह्न। अधीर और
विशेषज्ञ सिस्टम एडमिन इस बिंदु पर पढ़ना बंद कर सकते हैं, लेकिन लेखक का अब तक का अनुभव यही है
आगे पढ़ना फायदेमंद है। (यदि यह लाभप्रद नहीं है, तो संभवतः यह का एक क्षेत्र है
libसमझाएं कि इसमें सुधार किया जा सकता है। बेशक, कोड योगदान का स्वागत है।)

बाद क्योंकि
यह गैर-तकनीकी उपयोगकर्ताओं के लिए लक्षित त्रुटि संदेश का भाग है। यह परे दिखता है
सरल सिस्टम कॉल तर्क, और कुछ अधिक विशिष्ट की तलाश करता है।
वर्तमान निर्देशिका में कोई "कुछ" निर्देशिका नहीं है
यह भाग त्रुटि के निकटतम कारण को स्पष्ट भाषा में समझाने का प्रयास करता है
यहाँ अंतर्राष्ट्रीयकरण आवश्यक है।

सामान्य तौर पर, नीति में यथासंभव अधिक से अधिक जानकारी शामिल करना है, ताकि उपयोगकर्ता
इसकी तलाश करने की आवश्यकता नहीं है (और इसे बग रिपोर्ट से बाहर नहीं रखा गया है)।

अंतर्राष्ट्रीयकरण
लिबएक्सप्लेन लाइब्रेरी में अधिकांश त्रुटि संदेशों का अंतर्राष्ट्रीयकरण कर दिया गया है। वहाँ
अभी तक कोई स्थानीयकरण नहीं है, इसलिए यदि आप अपनी मूल भाषा में स्पष्टीकरण चाहते हैं,
कृपया योगदान करें.

उपरोक्त "अधिकांश" योग्यता इस तथ्य से संबंधित है कि अवधारणा का प्रमाण
कार्यान्वयन में अंतर्राष्ट्रीयकरण समर्थन शामिल नहीं था। कोड बेस हो रहा है
उत्तरोत्तर संशोधित किया जाता है, आमतौर पर प्रत्येक त्रुटि के लिए संदेशों को पुनः सक्रिय करने के परिणामस्वरूप
संदेश स्ट्रिंग कोड में बिल्कुल एक बार दिखाई देती है।

उन भाषाओं के लिए प्रावधान किया गया है जिनके हिस्सों को इकट्ठा करने की आवश्यकता है
सिस्टम-कॉल असफल, सिस्टम त्रुटि क्योंकि स्पष्टीकरण
स्थानीयकृत त्रुटि संदेशों में सही व्याकरण के लिए अलग-अलग क्रम में।

पोस्टमार्टम
ऐसे समय होते हैं जब किसी प्रोग्राम में अभी तक libexplain का उपयोग नहीं किया जाता है, और आप इसका उपयोग नहीं कर सकते हैं स्ट्रेस(1)
दोनों में से एक। वहाँ है एक समझाना(1) कमांड libexplain के साथ शामिल है जिसका उपयोग किया जा सकता है
यदि अंतर्निहित सिस्टम की स्थिति बहुत अधिक नहीं बदली है, तो त्रुटि संदेशों को समझें।
$ समझाना नाम बदलने foo /tmp/बार/baz -e ENOENT
नाम बदलें(oldpath = "foo", newpath = "/tmp/bar/baz") विफल, ऐसी कोई फ़ाइल या निर्देशिका नहीं
(2, ENOENT) क्योंकि न्यूपाथ में कोई "बार" निर्देशिका नहीं है "/ Tmp" निर्देशिका
$
ध्यान दें कि सिस्टम कॉल तर्क नाम का उपयोग करके पथ अस्पष्टता को कैसे हल किया जाता है। का
बेशक, आपको त्रुटि और सिस्टम कॉल को जानना होगा समझाना(1) उपयोगी होना । एक के रूप में
एक तरफ, यह सत्यापित करने के लिए लिबएक्सप्लेन स्वचालित परीक्षण सूट द्वारा उपयोग किए जाने वाले तरीकों में से एक है
लिबएक्सप्लेन काम कर रहा है।

दर्शन
"मुझे वह सब कुछ बताएं, जिसमें वह सामान भी शामिल है जिसे मैं खोजना नहीं जानता था।"

लाइब्रेरी को इस तरह से कार्यान्वित किया जाता है कि जब स्थिर रूप से लिंक किया जाता है, तो केवल आपका कोड
वास्तव में उपयोग को जोड़ा जाएगा। यह प्रति स्रोत फ़ाइल में एक फ़ंक्शन होने से प्राप्त होता है,
जब भी संभव हो.

जब अधिक जानकारी प्रदान करना संभव होगा, तो libexplain ऐसा करेगा। उपयोगकर्ता उतना ही कम
अपने लिए ट्रैक करना होगा, बेहतर होगा। इसका मतलब है कि यूआईडी के साथ हैं
उपयोगकर्ता नाम, जीआईडी ​​समूह नाम के साथ हैं, पीआईडी ​​प्रक्रिया के साथ हैं
नाम, फ़ाइल डिस्क्रिप्टर और स्ट्रीम पथनाम के साथ हैं, आदि.

पथों को हल करते समय, यदि कोई पथ घटक मौजूद नहीं है, तो libexplain समान खोजेगा
मुद्रण संबंधी त्रुटियों के लिए विकल्प सुझाने के लिए नाम।

लिबएक्सप्लेन लाइब्रेरी यथासंभव कम हीप का उपयोग करने का प्रयास करती है, और आमतौर पर कोई भी नहीं। यह है
जहां तक ​​संभव हो, प्रक्रिया की स्थिति में गड़बड़ी से बचने के लिए, हालांकि कभी-कभी ऐसा होता है
अनुपयोगी।

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

लिबएक्सप्लेन लाइब्रेरी किसी प्रक्रिया के सिग्नल हैंडलर को परेशान नहीं करती है। यह बनाता है
यह निर्धारित करना कि क्या कोई सूचक किसी चुनौती को सेगफॉल्ट करेगा, लेकिन असंभव नहीं है।

जब जानकारी सिस्टम कॉल के साथ-साथ ए के माध्यम से भी उपलब्ध हो / proc
प्रविष्टि, सिस्टम कॉल को प्राथमिकता दी जाती है। यह प्रक्रिया की स्थिति में गड़बड़ी से बचने के लिए है।
ऐसे भी समय होते हैं जब कोई फ़ाइल डिस्क्रिप्टर उपलब्ध नहीं होता है।

लिबएक्सप्लेन लाइब्रेरी को बड़े फ़ाइल समर्थन के साथ संकलित किया गया है। कोई बड़ा/छोटा नहीं है
एक प्रकार का मानसिक विकार। जहां यह एपीआई में तर्क प्रकारों को प्रभावित करता है, और त्रुटि जारी की जाएगी
यदि आवश्यक बड़ी फ़ाइल डिफाइन अनुपस्थित हैं।

FIXME: यह सुनिश्चित करने के लिए काम करने की आवश्यकता है कि फ़ाइल सिस्टम कोटा कोड में प्रबंधित किया जाता है। यह
कुछ पर लागू होता है गेटरलिमिट(2) सीमाएँ भी।

ऐसे मामले होते हैं जब रिश्तेदारों के रास्ते सूचनाप्रद नहीं होते। उदाहरण के लिए: सिस्टम डेमॉन,
सर्वर और पृष्ठभूमि प्रक्रियाएँ। इन मामलों में, त्रुटि में निरपेक्ष पथ का उपयोग किया जाता है
स्पष्टीकरण।

पथ संकल्प

लघु संस्करण: देखें पथ_संकल्प(7).

लंबा संस्करण: अधिकांश उपयोगकर्ताओं ने इसके बारे में कभी नहीं सुना है पथ_संकल्प(7), और कई उन्नत उपयोगकर्ता
इसे कभी नहीं पढ़ा. यहाँ एक एनोटेटेड संस्करण है:

कदम 1: प्रारंभ of la संकल्प प्रक्रिया
यदि पथनाम स्लैश ("/") वर्ण से प्रारंभ होता है, तो प्रारंभिक लुकअप निर्देशिका है
कॉलिंग प्रक्रिया की मूल निर्देशिका।

यदि पथनाम स्लैश(“/”) वर्ण से प्रारंभ नहीं होता है, तो आरंभिक लुकअप
समाधान प्रक्रिया की निर्देशिका प्रक्रिया की वर्तमान कार्यशील निर्देशिका है।

कदम 2: चलना साथ में la पथ
वर्तमान लुकअप निर्देशिका को प्रारंभिक लुकअप निर्देशिका पर सेट करें। अब, प्रत्येक गैर के लिए-
पथनाम का अंतिम घटक, जहां एक घटक स्लैश ("/") द्वारा सीमांकित एक सबस्ट्रिंग है
वर्ण, इस घटक को वर्तमान लुकअप निर्देशिका में देखा जाता है।

यदि प्रक्रिया में वर्तमान लुकअप निर्देशिका पर खोज की अनुमति नहीं है, तो EACCES
त्रुटि लौटा दी गई है ("अनुमति अस्वीकृत")।
खुला(पथनाम = "/home/archives/.ssh/private_key", झंडे = O_RDONLY) विफल,
अनुमति अस्वीकृत (13, EACCES) क्योंकि प्रक्रिया में खोज की अनुमति नहीं है
पथनाम "/home/archives/.ssh" निर्देशिका में, प्रक्रिया प्रभावी GID 1000
"पीमिलर" निर्देशिका स्वामी 1001 "अभिलेखागार" से मेल नहीं खाता है इसलिए स्वामी
अनुमति मोड "आरडब्ल्यूएक्स" को नजरअंदाज कर दिया गया है, अन्य अनुमति मोड "---" है, और
प्रक्रिया विशेषाधिकार प्राप्त नहीं है (इसमें DAC_READ_SEARCH क्षमता नहीं है)

यदि घटक नहीं मिलता है, तो एक ENOENT त्रुटि दी जाती है ("ऐसी कोई फ़ाइल या निर्देशिका नहीं")।
अनलिंक(पथनाम = "/होम/माइक्रोसॉफ्ट/रबिश") विफल, ऐसी कोई फ़ाइल या निर्देशिका नहीं (2,
ENOENT) क्योंकि पथनाम में कोई "माइक्रोसॉफ्ट" निर्देशिका नहीं है "/ होम" निर्देशिका

उपयोगकर्ताओं के लिए कुछ समर्थन भी है जब वे पथनाम गलत टाइप करते हैं, सुझाव देते हैं
ENOENT लौटाया गया है:
open(pathname = "/user/include/fcntl.h", flags = O_RDONLY) विफल, ऐसी कोई फ़ाइल या
निर्देशिका (2, ENOENT) क्योंकि पथनाम "/" में कोई "उपयोगकर्ता" निर्देशिका नहीं है
निर्देशिका, क्या आपका मतलब इसके बजाय "usr" निर्देशिका था?

यदि घटक पाया जाता है, लेकिन न तो कोई निर्देशिका है और न ही कोई प्रतीकात्मक लिंक है, तो एक ENOTDIR
त्रुटि लौटा दी गई है ("निर्देशिका नहीं")।
खुला(पथनाम = "/home/pmiller/.netrc/lca", झंडे = O_RDONLY) विफल, नहीं
निर्देशिका (20, ENOTDIR) क्योंकि पथनाम में ".netrc" नियमित फ़ाइल है
"/home/pmiller" निर्देशिका का उपयोग निर्देशिका के रूप में किया जा रहा है जबकि ऐसा नहीं है

यदि घटक पाया जाता है और एक निर्देशिका है, तो हम वर्तमान लुकअप निर्देशिका को उसमें सेट करते हैं
निर्देशिका, और अगले घटक पर जाएँ।

यदि घटक पाया जाता है और एक प्रतीकात्मक लिंक (सिम्लिंक) है, तो हम पहले इस प्रतीकात्मक को हल करते हैं
लिंक (प्रारंभिक लुकअप निर्देशिका के रूप में वर्तमान लुकअप निर्देशिका के साथ)। गलती होने पर, वह
त्रुटि वापस आ गई है। यदि परिणाम कोई निर्देशिका नहीं है, तो एक ENOTDIR त्रुटि लौटा दी जाती है।
अनलिंक(पथनाम = "/tmp/dangling/बकवास") विफल, ऐसी कोई फ़ाइल या निर्देशिका नहीं (2,
ENOENT) क्योंकि पथनाम में "लटकता हुआ" प्रतीकात्मक लिंक "/ Tmp" निर्देशिका
"कहीं नहीं" को संदर्भित करता है जिसका अस्तित्व नहीं है
यदि सिम्लिंक का रिज़ॉल्यूशन सफल होता है और एक निर्देशिका लौटाता है, तो हम करंट सेट करते हैं
उस निर्देशिका में निर्देशिका खोजें, और अगले घटक पर जाएँ। ध्यान दें कि
यहां समाधान प्रक्रिया में पुनरावर्तन शामिल है। कर्नेल को स्टैक से बचाने के लिए
अतिप्रवाह, और सेवा से इनकार से बचाने के लिए, अधिकतम सीमाएँ हैं
प्रत्यावर्तन गहराई, और अनुसरण किए गए प्रतीकात्मक लिंक की अधिकतम संख्या पर। एक ELOOP त्रुटि है
अधिकतम सीमा पार होने पर लौटाया जाता है ("प्रतीकात्मक लिंक के बहुत सारे स्तर")।
open(pathname = "/tmp/dangling", flags = O_RDONLY) विफल, बहुत सारे स्तर
प्रतीकात्मक लिंक (40, ELOOP) क्योंकि एक प्रतीकात्मक लिंक लूप का सामना करना पड़ा था
पथनाम, "/tmp/dangling" से प्रारंभ
यदि बहुत अधिक सिम्लिंक हैं तो ELOOP या EMLINK त्रुटि प्राप्त करना भी संभव है, लेकिन नहीं
लूप का पता चला।
खुला (पथनाम = "/tmp/खरगोश-छेद", झंडे = O_RDONLY) विफल, बहुत सारे स्तर
प्रतीकात्मक लिंक (40, ELOOP) क्योंकि इसमें बहुत सारे प्रतीकात्मक लिंक सामने आए थे
पथनाम (8)
ध्यान दें कि वास्तविक सीमा भी कैसे मुद्रित की जाती है।

कदम 3: खोज la अंतिम प्रविष्टि
पथनाम के अंतिम घटक का लुकअप अन्य सभी की तरह ही होता है
घटक, जैसा कि पिछले चरण में वर्णित है, दो अंतरों के साथ:

(i) अंतिम घटक को एक निर्देशिका होने की आवश्यकता नहीं है (कम से कम जहां तक ​​पथ रिज़ॉल्यूशन की बात है)।
प्रक्रिया का संबंध है. इसे एक निर्देशिका, या एक गैर-निर्देशिका होना पड़ सकता है, क्योंकि
विशिष्ट सिस्टम कॉल की आवश्यकताएँ)।

(Ii)
यदि अंतिम घटक नहीं मिला तो यह आवश्यक रूप से एक त्रुटि नहीं है; शायद हम बस हैं
इसे बनाना. अंतिम प्रविष्टि के उपचार का विवरण इसमें वर्णित है
विशिष्ट सिस्टम कॉल के मैनुअल पेज।

(Iii)
यदि यह एक प्रतीकात्मक लिंक है तो अंतिम घटक के साथ समस्या होना भी संभव है
और इसका पालन नहीं किया जाना चाहिए. उदाहरण के लिए, का उपयोग करना खुला(2) O_NOFOLLOW ध्वज:
open(pathname = "a‐symlink", flags = O_RDONLY | O_NOFOLLOW) विफल, बहुत सारे स्तर
प्रतीकात्मक लिंक (ELOOP) क्योंकि O_NOFOLLOW निर्दिष्ट किया गया था लेकिन पथनाम a को संदर्भित करता है
प्रतीकात्मक लिंक

(Iv)
पथनाम टाइप करते समय उपयोगकर्ताओं से गलतियाँ होना आम बात है। लिबएक्सप्लेन लाइब्रेरी
ENOENT लौटाए जाने पर सुझाव देने का प्रयास, उदाहरण के लिए:
खुला (पथनाम = "/usr/include/filecontrl.h", झंडे = O_RDONLY) विफल, ऐसी कोई फ़ाइल या
निर्देशिका (2, ENOENT) क्योंकि पथनाम में कोई "filecontrl.h" नियमित फ़ाइल नहीं है
"/ usr / शामिल हैं"निर्देशिका, क्या आपका मतलब इसके बजाय "fcntl.h" नियमित फ़ाइल से था?

(v) यह भी संभव है कि अंतिम घटक के अलावा कुछ और होना आवश्यक है
नियमित फ़ाइल:
रीडलिंक(पथनाम = "सिर्फ‐एक‐फ़ाइल", डेटा = 0x7F930A50, डेटा_आकार = 4097) विफल,
अमान्य तर्क (22, EINVAL) क्योंकि पथनाम एक नियमित फ़ाइल है, प्रतीकात्मक लिंक नहीं

(Vi)
FIXME: "t" बिट का प्रबंधन।

सीमाएं
पथनाम और फ़ाइलनाम के संबंध में कई सीमाएँ हैं।

पथनाम लंबाई सीमा
पथनामों के लिए अधिकतम लंबाई है. यदि पथनाम (या कुछ मध्यवर्ती
प्रतीकात्मक लिंक को हल करते समय प्राप्त पथनाम) बहुत लंबा है, एक ENAMETOOLONG
त्रुटि लौटा दी गई है ("फ़ाइल का नाम बहुत लंबा है")। ध्यान दें कि सिस्टम सीमा कैसे शामिल की गई है
त्रुटि संदेश में.
खुला (पथनाम = "बहुत लम्बा", झंडे = O_RDONLY) विफल, फ़ाइल का नाम बहुत लंबा है (36,
ENAMETOOLONG) क्योंकि पथनाम सिस्टम की अधिकतम पथ लंबाई (4096) से अधिक है

फ़ाइल नाम की लंबाई सीमा
कुछ यूनिक्स वेरिएंट में प्रत्येक पथ घटक में बाइट्स की संख्या की एक सीमा होती है।
उनमें से कुछ चुपचाप इससे निपटते हैं, और कुछ एनामेटूलॉन्ग देते हैं; लिबएक्सप्लेन
पुस्तकालय का उपयोग करता है pathconf(3)_PC_NO_TRUNC कौन सा बताना है। यदि यह त्रुटि होती है, तो
libexplain लाइब्रेरी त्रुटि संदेश में सीमा बताएगी, सीमा है
प्राप्त हुआ pathconf(3) _PC_NAME_MAX. ध्यान दें कि सिस्टम सीमा कैसे शामिल की गई है
त्रुटि संदेश में.
खुला (पथनाम = "system7/केवल-में-14-वर्ण थे", झंडे = O_RDONLY) विफल, फ़ाइल
नाम बहुत लंबा है (36, एनामेटूलॉन्ग) क्योंकि "केवल-14-अक्षर वाला" घटक है
सिस्टम सीमा से अधिक लंबा (14)

खाली पथनाम
मूल यूनिक्स में, खाली पथनाम वर्तमान निर्देशिका को संदर्भित करता है।
आजकल POSIX का आदेश है कि एक खाली पथनाम को सफलतापूर्वक हल नहीं किया जाना चाहिए।
खुला(पथनाम = "", झंडे = O_RDONLY) विफल, ऐसी कोई फ़ाइल या निर्देशिका नहीं (2,
ENOENT) क्योंकि POSIX का आदेश है कि एक खाली पथनाम का समाधान नहीं किया जाना चाहिए
सफलतापूर्वक

अनुमतियाँ
किसी फ़ाइल की अनुमति बिट्स में तीन बिट्स के तीन समूह होते हैं। का पहला समूह
तीन का उपयोग तब किया जाता है जब कॉलिंग प्रक्रिया की प्रभावी उपयोगकर्ता आईडी मालिक की आईडी के बराबर होती है
फ़ाइल। तीन के दूसरे समूह का उपयोग तब किया जाता है जब फ़ाइल की समूह आईडी या तो बराबर होती है
कॉलिंग प्रक्रिया की प्रभावी समूह आईडी, या पूरक समूह आईडी में से एक है
कॉलिंग प्रक्रिया. जब कोई भी नहीं टिकता, तो तीसरे समूह का उपयोग किया जाता है।
खुला (पथनाम = "/ Etc / पासवर्ड", झंडे = O_WRONLY) विफल, अनुमति अस्वीकृत (13,
EACCES) क्योंकि इस प्रक्रिया में नियमित रूप से "passwd" को लिखने की अनुमति नहीं है
पथनाम में फ़ाइल करें "/आदि"निर्देशिका, प्रक्रिया प्रभावी यूआईडी 1000 "पीमिलर"
नियमित फ़ाइल स्वामी 0 "रूट" से मेल नहीं खाता है इसलिए स्वामी अनुमति मोड "rw-"
अनदेखा कर दिया गया है, अन्य अनुमति मोड "r--" है, और प्रक्रिया विशेषाधिकार प्राप्त नहीं है
(DAC_OVERRIDE क्षमता नहीं है)
इस स्पष्टीकरण को कुछ महत्वपूर्ण स्थान दिया गया है, क्योंकि अधिकांश उपयोगकर्ता यह नहीं जानते हैं
अनुमति प्रणाली इस प्रकार काम करती है। विशेष रूप से: स्वामी, समूह और अन्य
अनुमतियाँ अनन्य हैं, वे एक साथ "OR" नहीं हैं।

अजीब और दिलचस्प प्रणाली कॉल

प्रत्येक सिस्टम कॉल के लिए एक विशिष्ट त्रुटि हैंडलर लिखने की प्रक्रिया अक्सर सामने आती है
दिलचस्प विचित्रताएँ और सीमा स्थितियाँ, या अस्पष्ट गलत(3) मान.

एनोमेडियम, नहीं मध्यम पाया
एक सीडी की प्रतिलिपि बनाने का कार्य इस पेपर के शीर्षक का स्रोत था।
$ dd if=/dev/cdrom of=fubar.iso
dd: "/dev/cdrom" खोलना: कोई माध्यम नहीं मिला
$
लेखक को आश्चर्य हुआ कि उसका कंप्यूटर उसे यह क्यों बता रहा था कि मानसिक रोगी जैसी कोई चीज़ नहीं होती
मध्यम। इस तथ्य से बिल्कुल अलग कि बड़ी संख्या में देशी अंग्रेजी बोलने वाले नहीं हैं
यह जानते हुए भी कि "मीडिया" एक बहुवचन है, यह तो छोड़ ही दें कि "माध्यम" इसका एकवचन, स्ट्रिंग है
द्वारा लौटा strerror(3) एनोमेडियम इतना संक्षिप्त है कि लगभग पूरी तरह से मुक्त हो गया है
सामग्री.

. खुला(2) एनोमेडियम लौटाता है, यह अच्छा होगा यदि लिबएक्सप्लेन लाइब्रेरी का विस्तार हो सके
इस पर बहुत कम, यह ड्राइव के प्रकार पर आधारित है। उदाहरण के लिए:
... क्योंकि फ़्लॉपी ड्राइव में कोई डिस्क नहीं है
...क्योंकि CD‐ROM ड्राइव में कोई डिस्क नहीं है
... क्योंकि टेप ड्राइव में कोई टेप नहीं है
... क्योंकि कार्ड रीडर में कोई मेमोरी स्टिक नहीं है

और इस प्रकार ऐसा हुआ...
खुला(पथनाम = "/dev/cdrom", झंडे = O_RDONLY) विफल, कोई माध्यम नहीं मिला (123,
ENOMEDIUM) क्योंकि CD‐ROM ड्राइव में कोई डिस्क प्रतीत नहीं होती है
वह तरकीब, जिसके बारे में लेखक पहले से अनजान था, का उपयोग करके डिवाइस को खोलना था
O_NONBLOCK ध्वज, जो आपको बिना किसी माध्यम वाली ड्राइव खोलने की अनुमति देगा। उसके बाद तुमने
डिवाइस विशिष्ट जारी करें ioctls(2) तब तक अनुरोध करता हूं जब तक आप यह समझ नहीं लेते कि यह क्या है। (नहीं
यकीन है कि यह POSIX है, लेकिन ऐसा लगता है कि यह BSD और सोलारिस में भी इसी तरह काम करता है
la वोडिम(1) स्रोत।)

संदर्भ में "डिस्क" और "डिस्क" के अलग-अलग उपयोगों पर भी ध्यान दें। सीडी मानक की उत्पत्ति हुई
फ़्रांस में, लेकिन बाकी सभी चीज़ों में "k" होता है।

अंतिम, बुरा पता
कोई भी सिस्टम कॉल जो पॉइंटर तर्क लेता है वह EFAULT लौटा सकता है। लिबएक्सप्लेन लाइब्रेरी
यह पता लगा सकता है कि किस तर्क में गलती है, और यह प्रक्रिया को परेशान किए बिना ऐसा करता है
(या थ्रेड) सिग्नल हैंडलिंग।

जब उपलब्ध हो, तो mincore(2) सिस्टम कॉल का उपयोग यह पूछने के लिए किया जाता है कि क्या मेमोरी क्षेत्र वैध है।
यह तीन परिणाम लौटा सकता है: मैप किया गया लेकिन भौतिक मेमोरी में नहीं, मैप किया गया और भौतिक में
मेमोरी, और मैप नहीं किया गया। किसी सूचक की वैधता का परीक्षण करते समय, पहले दो "हाँ" होते हैं
और आखिरी वाला "नहीं" है।

C स्ट्रिंग्स की जाँच करना अधिक कठिन है, क्योंकि एक सूचक और एक आकार के बजाय, हम केवल
एक सूचक है. आकार निर्धारित करने के लिए हमें एनयूएल ढूंढना होगा, और वह कर सकता है
सेगफॉल्ट, कैच-22।

इसके आसपास काम करने के लिए, लिबएक्सप्लेन लाइब्रेरी का उपयोग करता है lstat(2) सिस्टम कॉल (किसी ज्ञात के साथ)।
अच्छा दूसरा तर्क) वैधता के लिए सी स्ट्रिंग्स का परीक्षण करने के लिए। एक विफलता वापसी && त्रुटि == EFAULT
एक "नहीं" है, और कुछ भी "हाँ" है। यह, निश्चित रूप से स्ट्रिंग्स को PATH_MAX तक सीमित करता है
अक्षर, लेकिन यह आमतौर पर libexplain लाइब्रेरी के लिए कोई समस्या नहीं है, क्योंकि यह है
यह लगभग हमेशा सबसे लंबे तारों की परवाह करता है।

ईएमफ़ाइल, बहुत बहुत खुला फ़ाइलों
यह त्रुटि तब होती है जब किसी प्रक्रिया में पहले से ही अधिकतम संख्या में फ़ाइल डिस्क्रिप्टर खुले होते हैं।
यदि वास्तविक सीमा मुद्रित की जानी है, और libexplain लाइब्रेरी ऐसा करने का प्रयास करती है, तो आप नहीं खोल सकते
में एक फ़ाइल / proc यह क्या है इसे पढ़ने के लिए.
open_max = sysconf(_SC_OPEN_MAX);
यह इतना कठिन नहीं होगा, एक है sysconf(3) सीमा प्राप्त करने का तरीका।

एनफ़ाइल, बहुत बहुत खुला फ़ाइलों in प्रणाली
यह त्रुटि तब होती है जब सिस्टम में खुली फ़ाइलों की कुल संख्या सीमित हो जाती है
पहुँच गया। इस मामले में कोई सुविधा नहीं है sysconf(3) सीमा प्राप्त करने का तरीका।

गहराई से जानने पर, कोई यह जान सकता है कि लिनक्स पर एक है / proc प्रविष्टि जिसे हम पढ़ सकते हैं
यह मान प्राप्त करें. पकड़‐22: हमारे पास फ़ाइल डिस्क्रिप्टर नहीं हैं, इसलिए हम फ़ाइल नहीं खोल सकते
सीमा पढ़ें.

लिनक्स पर इसे प्राप्त करने के लिए एक सिस्टम कॉल है, लेकिन इसमें कोई [e]glibc रैपर फ़ंक्शन नहीं है, इसलिए
आपको यह सब बहुत सावधानी से करना होगा:
लंबा
व्याख्या_मैक्सफ़ाइल(शून्य)
{
#ifdef __linux__
संरचना __sysctl_args args;
int32_t मैक्सफ़ाइल;
size_t maxfile_size = इस आकार का(मैक्सफ़ाइल);
int नाम[] = { CTL_FS, FS_MAXFILE };
मेमसेट(&args, 0, sizeof(struct __sysctl_args));
args.name = नाम;
args.nlen = 2;
args.oldval = &maxfile;
args.oldlenp = &maxfile_size;
यदि (syscall(SYS__sysctl, &args) >= 0)
मैक्सफाइल लौटें;
#endif
वापसी -1;
}
यह उपलब्ध होने पर त्रुटि संदेश में सीमा को शामिल करने की अनुमति देता है।

EINVAL "अमान्य तर्क" vs एनोसिस "समारोह नहीं कार्यान्वित"
असमर्थित कार्रवाइयाँ (जैसे सिमलिंक(2) एफएटी फ़ाइल सिस्टम पर) रिपोर्ट नहीं की जाती है
एक सिस्टम कॉल से दूसरे सिस्टम कॉल तक लगातार। यह या तो EINVAL या होना संभव है
एनोसिस वापस आ गया।

परिणामस्वरूप, विशेष रूप से इन त्रुटि मामलों को ठीक करने के लिए उन पर ध्यान दिया जाना चाहिए
क्योंकि EINVAL एक या अधिक सिस्टम कॉल तर्कों की समस्याओं का भी उल्लेख कर सकता है।

नोट कि गलत(3) is नहीं हमेशा सेट
ऐसे समय होते हैं जब यह निर्धारित करने के लिए कि कैसे और कैसे, glibc स्रोतों को पढ़ना आवश्यक होता है
जब कुछ सिस्टम कॉल के लिए त्रुटियाँ लौटाई जाती हैं।

feof(3) कोई फ़ाइल नहीं(3)
अक्सर यह माना जाता है कि ये फ़ंक्शन कोई त्रुटि नहीं लौटा सकते। यह तभी सत्य है यदि
la धारा तर्क वैध है, हालाँकि वे अमान्य का पता लगाने में सक्षम हैं
सूचक।

fpathconf(3) pathconf(3)
का वापसी मूल्य return fpathconf(2) और pathconf(2) वैध रूप से -1 हो सकता है, इसलिए यह है
यह देखना आवश्यक है कि क्या गलत(3) स्पष्ट रूप से निर्धारित किया गया है।

ioctls(2)
का वापसी मूल्य return ioctls(2) वैध रूप से -1 हो सकता है, इसलिए यह देखना आवश्यक है कि क्या
गलत(3) स्पष्ट रूप से निर्धारित किया गया है।

readdir(3)
का वापसी मूल्य return readdir(3) त्रुटियों और फ़ाइल के अंत दोनों के लिए शून्य है। यह है
यह देखना आवश्यक है कि क्या गलत(3) स्पष्ट रूप से निर्धारित किया गया है।

सेटबफ(3) सेटबफ़र(3) सेटलाइनबफ़(3) setvbuf(3)
इनमें से अंतिम को छोड़कर सभी फ़ंक्शन शून्य हो जाते हैं। और setvbuf(3) के रूप में केवल प्रलेखित है
त्रुटि पर "गैर-शून्य" लौटाना। यह देखना जरूरी है कि क्या गलत(3) स्पष्ट रूप से किया गया है
निर्धारित किया है.

स्ट्रटोड(3) स्ट्रोटोल(3) स्ट्रटोल्ड(3) स्ट्रोटोल(3) strtoul(3) strtoul(3)
ये फ़ंक्शन त्रुटि पर 0 लौटाते हैं, लेकिन यह भी एक वैध रिटर्न मान है। यह है
यह देखना आवश्यक है कि क्या गलत(3) स्पष्ट रूप से निर्धारित किया गया है।

ungetc(3)
जबकि एएनएसआई सी मानक द्वारा बैकअप का केवल एक ही अक्षर अनिवार्य है, यह बदल जाता है
वह यह कि [e]glibc अधिक अनुमति देता है... लेकिन इसका मतलब है कि यह ENOMEM के साथ विफल हो सकता है। यह
यदि EBADF के साथ भी विफल हो fp फर्जी है. सबसे कठिन, यदि आप ईओएफ पास करते हैं तो कोई त्रुटि होती है
वापसी होती है, लेकिन इरनो सेट नहीं है।

लिबएक्सप्लेन लाइब्रेरी इन सभी त्रुटियों का सही ढंग से पता लगाती है, यहां तक ​​​​कि उन मामलों में भी जहां
त्रुटि मान खराब तरीके से प्रलेखित हैं, यदि हैं भी तो।

ईएनओएसपीसी, नहीं अंतरिक्ष बाएं on युक्ति
जब यह त्रुटि फ़ाइल सिस्टम पर किसी फ़ाइल को संदर्भित करती है, तो libexplain लाइब्रेरी माउंट को प्रिंट करती है
समस्या के साथ फ़ाइल सिस्टम का बिंदु। इससे त्रुटि का स्रोत बहुत कुछ हो सकता है
अधिक स्पष्ट.
लिखें (फिल्डेस = 1 "उदाहरण", डेटा = 0xbfff2340, डेटा_आकार = 5) विफल, कोई स्थान नहीं बचा
डिवाइस पर (28, ENOSPC) क्योंकि फ़ाइल सिस्टम में फ़िल्ड्स ("/ होम") है कोई
डेटा के लिए अधिक स्थान
जैसे-जैसे अधिक विशेष डिवाइस समर्थन जोड़ा जाता है, त्रुटि संदेशों में डिवाइस शामिल होने की उम्मीद है
डिवाइस का नाम और वास्तविक आकार।

ईआरओएफएस, केवल पढ़ने के लिए पट्टिका प्रणाली
जब यह त्रुटि फ़ाइल सिस्टम पर किसी फ़ाइल को संदर्भित करती है, तो libexplain लाइब्रेरी माउंट को प्रिंट करती है
समस्या के साथ फ़ाइल सिस्टम का बिंदु। इससे त्रुटि का स्रोत बहुत कुछ हो सकता है
अधिक स्पष्ट.

जैसे-जैसे अधिक विशेष डिवाइस समर्थन जोड़ा जाता है, त्रुटि संदेशों में डिवाइस शामिल होने की उम्मीद है
नाम और प्रकार.
खुला(पथनाम = "/dev/fd0", O_RDWR, 0666) विफल, केवल पढ़ने योग्य फ़ाइल सिस्टम (30, EROFS)
क्योंकि फ्लॉपी डिस्क में राइट प्रोटेक्ट टैब सेट होता है

...क्योंकि CD‐ROM लिखने योग्य नहीं है
...क्योंकि मेमोरी कार्ड में राइट प्रोटेक्ट टैब सेट है
...क्योंकि ½ इंच चुंबकीय टेप में राइट रिंग नहीं होती है

नाम बदलने
RSI नाम बदलने(2) सिस्टम कॉल का उपयोग किसी फ़ाइल का स्थान या नाम बदलने, उसे स्थानांतरित करने के लिए किया जाता है
यदि आवश्यक हो तो निर्देशिकाओं के बीच। यदि गंतव्य पथनाम पहले से मौजूद है तो यह होगा
परमाणु रूप से प्रतिस्थापित, ताकि ऐसा कोई बिंदु न हो जिस पर कोई अन्य प्रक्रिया प्रयास कर रही हो
इसे एक्सेस करें, यह गायब मिलेगा।

हालाँकि, कुछ सीमाएँ हैं: आप केवल एक निर्देशिका का नाम दूसरी निर्देशिका के ऊपर रख सकते हैं
यदि गंतव्य निर्देशिका खाली नहीं है तो निर्देशिका।
नाम बदलें(पुरानापथ = "फू", नयापथ = "बार") विफल, निर्देशिका खाली नहीं (39,
ENOTEMPTY) क्योंकि न्यूपाथ एक खाली निर्देशिका नहीं है; अर्थात्, इसमें प्रविष्टियाँ शामिल हैं
के अलावा अन्य "।" और ".."
आप किसी गैर-निर्देशिका के शीर्ष पर किसी निर्देशिका का नाम भी नहीं बदल सकते।
नाम बदलें(oldpath = "foo", newpath = "bar") विफल, कोई निर्देशिका नहीं (20, ENOTDIR)
क्योंकि पुराना पथ एक निर्देशिका है, लेकिन नया पथ एक नियमित फ़ाइल है, निर्देशिका नहीं
न ही इसके विपरीत की अनुमति है
नाम बदलें(oldpath = "foo", newpath = "bar") विफल, एक निर्देशिका है (21, EISDIR)
क्योंकि न्यूपाथ एक निर्देशिका है, लेकिन ओल्डपाथ एक नियमित फ़ाइल है, निर्देशिका नहीं

यह, निश्चित रूप से, लिबएक्सप्लेन लाइब्रेरी के काम को और अधिक जटिल बना देता है, क्योंकि
उतारना(2) या rmdir(2) सिस्टम कॉल को परोक्ष रूप से कहा जाता है नाम बदलने(2), और इसी प्रकार सभी
उतारना(2) या rmdir(2) त्रुटियों का भी पता लगाया जाना चाहिए और उन्हें संभाला जाना चाहिए।

डुप2
RSI डुप2(2) सिस्टम कॉल का उपयोग दूसरी फ़ाइल डिस्क्रिप्टर बनाने के लिए किया जाता है जो संदर्भ देता है
पहली फ़ाइल डिस्क्रिप्टर के समान ऑब्जेक्ट। आमतौर पर इसका उपयोग शेल इनपुट को लागू करने के लिए किया जाता है
और आउटपुट पुनर्निर्देशन।

मजे की बात तो यह है कि, ठीक वैसे ही नाम बदलने(2) परमाणु रूप से किसी फ़ाइल का नाम बदल सकता है
मौजूदा फ़ाइल और पुरानी फ़ाइल को हटा दें, डुप2(2) इसे पहले से खुली फ़ाइल पर कर सकते हैं
वर्णनकर्ता।

एक बार फिर, यह लिबएक्सप्लेन लाइब्रेरी के काम को और अधिक जटिल बना देता है, क्योंकि बंद करे(2)
सिस्टम कॉल को परोक्ष रूप से कॉल किया जाता है डुप2(2), और इसी प्रकार सभी बंद करे(2) की त्रुटियाँ अवश्य होंगी
पता लगाया और संभाला भी।

रोमांच IN आईओसीटीएल समर्थन

RSI ioctls(2) सिस्टम कॉल डिवाइस ड्राइवर लेखकों को संचार करने का एक तरीका प्रदान करता है
उपयोगकर्ता-स्थान जो मौजूदा कर्नेल एपीआई में फिट नहीं होता है। देखना ioctl_list(2).

डिकोडिंग निवेदन नंबर
एक सरसरी नजर से ioctls(2) इंटरफ़ेस, एक बड़ा लेकिन सीमित प्रतीत होगा
संभव की संख्या ioctls(2) अनुरोध. प्रत्येक अलग ioctls(2) अनुरोध प्रभावी है
एक अन्य सिस्टम कॉल, लेकिन बिना किसी प्रकार की सुरक्षा के - कंपाइलर मदद नहीं कर सकता
प्रोग्रामर को ये सही लगता है। शायद इसके पीछे यही प्रेरणा थी टीसीफ्लश(3) और
दोस्तों।

प्रारंभिक धारणा यह है कि आप डिकोड कर सकते हैं ioctls(2) एक विशाल स्विच का उपयोग करके अनुरोध
कथन। यह अव्यवहार्य साबित होता है क्योंकि व्यक्ति को बहुत तेजी से पता चलता है कि यह है
विभिन्न को परिभाषित करने वाले सभी आवश्यक सिस्टम हेडर को शामिल करना असंभव है ioctls(2)
अनुरोध करते हैं, क्योंकि उन्हें एक-दूसरे के साथ अच्छा खेलने में कठिनाई होती है।

गहराई से देखने पर पता चलता है कि "निजी" अनुरोध संख्या और डिवाइस की एक श्रृंखला है
ड्राइवर लेखकों को उनका उपयोग करने के लिए प्रोत्साहित किया जाता है। इसका मतलब यह है कि कहीं अधिक बड़ी संभावना है
अनुरोधों का समूह, अस्पष्ट अनुरोध संख्याओं के साथ, तुरंत स्पष्ट हो जाता है। भी,
कुछ ऐतिहासिक अस्पष्टताएँ भी हैं।

हम पहले से ही जानते थे कि स्विच अव्यावहारिक था, लेकिन अब हम जानते हैं कि इसका चयन करना है
उचित अनुरोध नाम और स्पष्टीकरण पर हमें न केवल अनुरोध संख्या पर विचार करना चाहिए
फ़ाइल डिस्क्रिप्टर भी।

इसका कार्यान्वयन ioctls(2) लिबएक्सप्लेन लाइब्रेरी के भीतर समर्थन की एक तालिका होनी चाहिए
की ओर संकेत करता है ioctls(2) वर्णनकर्ताओं का अनुरोध करें। इनमें से प्रत्येक वर्णनकर्ता में एक वैकल्पिक शामिल है
एक असंबद्धता समारोह के लिए सूचक.

प्रत्येक अनुरोध वास्तव में एक अलग स्रोत फ़ाइल में कार्यान्वित किया जाता है, ताकि आवश्यक हो
फ़ाइलों को शामिल करने से दूसरों के साथ अच्छा खेलने की बाध्यता से मुक्ति मिल जाती है।

प्रतिनिधित्व
लिबएक्सप्लेन लाइब्रेरी के पीछे का दर्शन अधिक से अधिक जानकारी प्रदान करना है
संभव है, जिसमें सिस्टम कॉल का सटीक प्रतिनिधित्व भी शामिल है। के मामले में
ioctls(2) इसका मतलब है सही अनुरोध संख्या (नाम से) और एक सही (या) प्रिंट करना
कम से कम उपयोगी) तीसरे तर्क का प्रतिनिधित्व।

RSI ioctls(2) प्रोटोटाइप इस तरह दिखता है:
int ioctl(int fildes, int request,...);
जिसमें आपके प्रकार के सुरक्षा अलार्म बजने चाहिए। [e]glibc के आंतरिक, इसे बदल दिया गया है
विभिन्न रूपों में:
int __ioctl(int fildes, int request, long arg);
int __ioctl (int fildes, int अनुरोध, शून्य * तर्क);
और लिनक्स कर्नेल सिस्कल इंटरफ़ेस की अपेक्षा करता है
asmlinkage long sys_ioctl(unsigned int fildes, unsigned int request, unsigned long
आर्ग);
तीसरे तर्क की चरम परिवर्तनशीलता एक चुनौती है, जब लिबएक्सप्लेन लाइब्रेरी
उस तीसरे तर्क का प्रतिनिधित्व मुद्रित करने का प्रयास करता है। हालाँकि, एक बार अनुरोध संख्या
स्पष्ट कर दिया गया है, libexplain लाइब्रेरी की ioctl तालिका में प्रत्येक प्रविष्टि में एक है
कस्टम प्रिंट_डेटा फ़ंक्शन (OO मैन्युअल रूप से किया गया)।

स्पष्टीकरण
उपयोग किए जाने वाले स्पष्टीकरण को निर्धारित करने में कम समस्याएं हैं। एक बार अनुरोध संख्या
स्पष्ट कर दिया गया है, libexplain लाइब्रेरी की ioctl तालिका में प्रत्येक प्रविष्टि का एक रिवाज है
print_explanation फ़ंक्शन (फिर से, OO मैन्युअल रूप से किया गया)।

धारा 2 और धारा 3 सिस्टम कॉल के विपरीत, अधिकांश ioctls(2) अनुरोधों में कोई त्रुटि नहीं है
प्रलेखित. इसका मतलब है, अच्छा त्रुटि विवरण देने के लिए कर्नेल को पढ़ना आवश्यक है
खोजने के लिए स्रोत

· क्या गलत(3) मान लौटाए जा सकते हैं, और

· प्रत्येक त्रुटि का कारण.

कर्नेल के साथ फ़ंक्शन कॉल डिस्पैचिंग की OO प्रकृति के कारण, आपको पढ़ने की आवश्यकता है
सब उस पर अमल करने वाले सूत्र ioctls(2) अनुरोध, केवल सामान्य कार्यान्वयन नहीं। यह
उम्मीद की जानी चाहिए कि अलग-अलग कर्नेल में अलग-अलग त्रुटि संख्याएँ और सूक्ष्मताएँ होंगी
विभिन्न त्रुटि कारण.

EINVAL vs ईनॉटी
के लिए स्थिति और भी बदतर है ioctls(2) सिस्टम कॉल के लिए अनुरोध, EINVAL और के साथ
ENOTTY दोनों का उपयोग यह इंगित करने के लिए किया जा रहा है कि a ioctls(2) उसमें निवेदन अनुचित है
संदर्भ, और कभी-कभी ENOSYS, ENOTSUP और EOPNOTSUPP (सॉकेट के लिए उपयोग किए जाने के लिए) जैसे
कुंआ। लिनक्स कर्नेल स्रोतों में ऐसी टिप्पणियाँ हैं जो प्रगतिशीलता का संकेत देती प्रतीत होती हैं
सफ़ाई चल रही है. अतिरिक्त अराजकता के लिए, बीएसडी भ्रम में ENOIOCTL जोड़ता है।

परिणामस्वरूप, विशेष रूप से इन त्रुटि मामलों को ठीक करने के लिए उन पर ध्यान दिया जाना चाहिए
क्योंकि EINVAL एक या अधिक सिस्टम कॉल तर्कों की समस्याओं का भी उल्लेख कर सकता है।

intptr_t
C99 मानक एक पूर्णांक प्रकार को परिभाषित करता है जो किसी भी सूचक को पकड़ने में सक्षम होने की गारंटी देता है
प्रतिनिधित्व हानि के बिना.

उपरोक्त फ़ंक्शन सिस्कल प्रोटोटाइप बेहतर ढंग से लिखा जाएगा
लंबी sys_ioctl (अहस्ताक्षरित int fildes, अहस्ताक्षरित int अनुरोध, intptr_t arg);
समस्या डिवाइस-विशिष्ट या फ़ाइल-सिस्टम-विशिष्ट द्वारा प्रेरित संज्ञानात्मक असंगति है
ioctls(2) कार्यान्वयन, जैसे:
लंबी vfs_ioctl (संरचना फ़ाइल *filp, अहस्ताक्षरित int cmd, अहस्ताक्षरित लंबी arg);
अधिकांश ioctls(2) अनुरोधों में वास्तव में एक int *arg तीसरा तर्क होता है। लेकिन यह होना
long घोषित करने से कोड इसे long *arg मानता है। यह 32‐बिट्स पर हानिरहित है
(sizeof(long) == sizeof(int)) लेकिन 64‐बिट्स पर बुरा (sizeof(long) != sizeof(int))।
अंतहीनता के आधार पर, आपको वह मूल्य मिलता है या नहीं मिलता जिसकी आप अपेक्षा करते हैं, लेकिन आप हमेशा मिल
एक मेमोरी स्क्रिबल या स्टैक स्क्रिबल भी।

इन सभी को इस प्रकार लिख रहा हूँ
int ioctl(int fildes, int request,...);
int __ioctl (int fildes, int अनुरोध, intptr_t arg);
लंबी sys_ioctl (अहस्ताक्षरित int fildes, अहस्ताक्षरित int अनुरोध, intptr_t arg);
लंबी vfs_ioctl (संरचना फ़ाइल *filp, अहस्ताक्षरित int cmd, intptr_t arg);
इस बात पर जोर देता है कि पूर्णांक केवल एक ऐसी मात्रा का प्रतिनिधित्व करने वाला पूर्णांक है जो लगभग है
हमेशा एक असंबद्ध सूचक प्रकार।

निष्कर्ष

libexplain का प्रयोग करें, आपके उपयोगकर्ता इसे पसंद करेंगे।

कॉपीराइट

libexplain संस्करण 1.4
कॉपीराइट (सी) 2008, 2009, 2010, 2011, 2012, 2013, 2014 पीटर मिलर

onworks.net सेवाओं का उपयोग करके explore_lca2010 का ऑनलाइन उपयोग करें