लिनक्स सिस्टम कॉल संख्याएँ x86 और x86_64 में भिन्न क्यों हैं?

Question

मुझे पता है कि सिस्टम कॉल इंटरफ़ेस निम्न स्तर पर लागू किया गया है और इसलिए आर्किटेक्चर / प्लेटफॉर्म पर निर्भर है, न कि "सामान्य" कोड।

फिर भी, मैं स्पष्ट रूप से इस कारण को नहीं देख पा रहा हूं कि लिनक्स में सिस्टम कॉल 32-बिट x86 कर्नेल की संख्या क्यों है जो समान आर्किटेक्चर 64-बिट x86_64 में समान नहीं रखी जाती हैं? इस निर्णय के पीछे प्रेरणा / कारण क्या है?

मेरा पहला अनुमान है कि एक पृष्ठभूमि का कारण एक x86_64 सिस्टम पर 32-बिट अनुप्रयोगों को चलाने योग्य रखा गया है, ताकि सिस्टम कॉल नंबर के लिए एक उचित ऑफसेट के माध्यम से सिस्टम को पता चले कि उपयोगकर्ता-स्थान 32-बिट या 64-बिट है क्रमशः। हालांकि मामला यह नहीं है। कम से कम मुझे ऐसा लगता है कि x86_64 में सिस्टम कॉल नंबर 0 पढ़ा जा रहा है () इस विचार के साथ संरेखित नहीं किया जा सकता है।

एक और अनुमान लगाया गया है कि सिस्टम कॉल नंबरों को बदलने से सुरक्षा / सख्त पृष्ठभूमि हो सकती है, कुछ ऐसा जिसकी मैं खुद पुष्टि नहीं कर पा रहा था।

वास्तुकला पर निर्भर कोड भागों को लागू करने की चुनौतियों से अनभिज्ञ होने के नाते, मुझे अभी भी आश्चर्य है कि सिस्टम कॉल नंबरों को कैसे बदलना है , जब कोई आवश्यकता नहीं लगती है (जैसा कि 16-बिट रजिस्टर भी काफी हद तक स्टोर करेगा तो वर्तमान में ~ 346 नंबर सभी का प्रतिनिधित्व करने के लिए। कॉल), कुछ भी हासिल करने में मदद करेगा, ब्रेक कम्पैटिबिलिटी के अलावा (हालांकि लाइब्रेरी, लिबक के माध्यम से सिस्टम कॉल का उपयोग करके इसे कम करता है)।

Comments

मुझे लगता है कि आप गलत सवाल पूछ रहे हैं। सही सवाल यह है कि उन्हें समान क्यों रखें: जवाब संगतता। इसलिए अगर x86 और x86_64 असंगत हैं, तो उन्हें बदलने से रोकने के लिए कोई ताकत नहीं है। अब पिछले 20 वर्षों की सभी ताकतें जो बदलाव चाहती थीं, वे हावी होंगी (हमें उन्हें बदलने का मौका मिलेगा)। [ध्यान दें कि यह केवल राय है और नई प्रणाली के डिजाइनरों के आंतरिक मन पर आधारित नहीं है।]

— ctrl-alt-delor-

Answer 1

विशिष्ट संख्या के पीछे तर्क के लिए, जो किसी अन्य वास्तुकला से मेल नहीं खाता है ["x32" को छोड़कर जो वास्तव में x86_64 वास्तुकला का सिर्फ एक हिस्सा है]: x86_64 के बहुत शुरुआती दिनों में लिनक्स कर्नेल में समर्थन, इससे पहले कि कोई भी हो गंभीर पश्चगामी संगतता बाधाएं, सभी सिस्टम कॉल को कैशलाइन उपयोग स्तर पर इसे अनुकूलित करने के लिए फिर से सेट किया गया था ।

मैं इन विकल्पों के विशिष्ट आधार को जानने के लिए कर्नेल विकास के बारे में पर्याप्त नहीं जानता, लेकिन जाहिर तौर पर मौजूदा आर्किटेक्चर से सूची को कॉपी करने के बजाय इन विशेष नंबरों के साथ सबकुछ फिर से चुनने के पीछे कुछ तर्क है। ऐसा लगता है कि यह आदेश आम तौर पर कैसे कहा जाता है पर आधारित हो सकता है - उदाहरण के लिए पढ़ा / लिखा / खुला / बंद सामने हैं। बाहर निकलें और कांटा "मौलिक" लग सकता है, लेकिन वे प्रत्येक को केवल एक बार प्रति प्रक्रिया कहा जाता है।

सिस्टम कॉल को रखने के बारे में भी कुछ हो सकता है जो आमतौर पर एक ही कैश लाइन के भीतर एक साथ उपयोग किए जाते हैं (ये मान केवल पूर्णांक होते हैं, लेकिन हर एक के लिए फ़ंक्शन पॉइंटर्स के साथ कर्नेल में एक तालिका होती है, इसलिए 8 सिस्टम कॉल का प्रत्येक समूह व्याप्त होता है उस तालिका के लिए 64-बाइट कैश लाइन)

Comments

fork may seem "fundamental", but [...] called only once per process.ओह क्या? मैं समझता हूँ कि आप एक बार बाहर निकलने के कॉल करने के लिए अपेक्षा कर सकते हैं, लेकिन आप माता-पिता और एक के बच्चे के अंदर कांटा हो सकता है fork()कॉल

— बिल्ली

@cat यदि आप forkबच्चे की प्रक्रिया के हिसाब से देखे जा रहे हैं (यानी इसे प्रक्रिया निर्माण कॉल के रूप में देखें), बजाय मूल प्रक्रिया के तो रेंडम 832 का कथन सही है।

— इकारस

@ ठीक है, आप दो या तीन बार कांटा (शायद कुछ और) कह सकते हैं। लेकिन आप लाखों या अरबों बार पढ़ सकते हैं।

— माइकल हैम्पटन

हां, मेरा यही मतलब है। कांटा कॉल की संख्या और सिस्टम के जीवनकाल में प्रक्रियाओं की संख्या समान होने जा रही है,

— इनिट

Answer 2

प्रश्न का वह उत्तर देखें "क्यों सिस्टम कॉल संख्याएं amd64 linux में भिन्न हैं?" स्टैक ओवरफ्लो पर।

इसे योग करने के लिए: अनुकूलता के लिए, सिस्टम कॉल सूची स्थिर है और केवल बढ़ सकती है। जब x86 64 आर्किटेक्चर दिखाई दिया, तो एबीआई (तर्क पारित करना, वापस लौटना मूल्य) अलग था, इस प्रकार कर्नेल डेवलपर्स ने उन परिवर्तनों को लाने का अवसर लिया जो लंबे समय से प्रतीक्षित थे।

Comments

कूल मेरा अनुमान सही था।

— ctrl-alt-delor

आपके द्वारा लिंक किए गए अन्य उत्तर सट्टा है: यह कहता है "लिनक्स लोग सबसे अधिक संभावना का फैसला करते हैं ..." (जोर दिया)। मुझे लगता है कि यह मदद करेगा यदि आपका जवाब यहाँ कुछ संकेत प्रदान करता है कि यह स्पष्ट रूप से सबूतों के बजाय अटकलों पर आधारित है। संयोग से, हाल ही में लिंक किए गए उत्तर के तहत पोस्ट की गई एक टिप्पणी इस बात का प्रमाण देती है कि सही कारण क्रूफ की सामान्य सफाई नहीं है (जैसा कि उत्तर में अटकलें लगती हैं), लेकिन विशेष रूप से "कैशलाइन उपयोग" के बारे में है, जैसा कि यहां अन्य उत्तर में बताया गया है ।

— डीडब्ल्यू

Answer 3

संक्षेप में, क्योंकि किसी ने सोचा था कि " N+1इसे करने के तरीके असंगत तरीके तरीके से बेहतर Nहैं"। ऐतिहासिक मेहराबों के लिए, आमतौर पर कुछ विरासत मालिकाना यूनिक्स से मेल करने के लिए syscall नंबरों को चुना गया था। लेकिन x86_64 के लिए कर्नेल डेवलपर्स किसी भी नंबरिंग को चुनने के लिए स्वतंत्र थे जो उन्हें पसंद था। सरल विकल्प बनाने और मौजूदा नंबरिंग का पुन: उपयोग करने के बजाय, उन्होंने एक नए मानक का आविष्कार करने का विकल्प बनाया। फिर उन्होंने इसे फिर से अराजकता 64 और दूसरों के एक समूह के लिए किया। यह लिनक्स कर्नेल विकास में एक बार-बार दोहराया जाने वाला पैटर्न है।

Comments

यह परिवर्तन गंभीर नहीं था । ठोस तकनीकी कारण हैं। यदि यह पश्च-अनुकूलता आवश्यकताओं के लिए नहीं थे, तो मौजूदा आर्किटेक्चरों पर भी इसी तरह के बदलाव लागू किए गए होंगे।

— जोर्ग डब्ल्यू मित्तग

नंबरिंग में अंतर 100% gratuitous है। किसी विशेष नंबरिंग का कोई तकनीकी लाभ नहीं है।

— आर ..

जैसा कि इस अन्य उत्तर में बताया गया है, syscalls को इस तरह से वर्गीकृत किया जाता है कि syscalls जो आमतौर पर एक साथ उपयोग किए जाते हैं, syscall तालिका में समान कैशलाइन को साझा करते हैं। और syscall नंबर ऐसे चुने जाते हैं कि वे उस तालिका में सरल सूचक होते हैं। सैद्धांतिक रूप से, हम syscall तालिका से syscall तालिका में एक syscall की स्थिति को कम करने के लिए अप्रत्यक्ष की एक परत का उपयोग कर सकते हैं, लेकिन संभवतः उसी कैशलाइन में हॉट syscalls लगाने से हमें प्राप्त होने वाले प्रदर्शन लाभ का एक हिस्सा खा जाएगा।

— जॉर्ज डब्ल्यू मित्तग

@ JörgWMittag: और यह स्पष्ट रूप से समय से पहले अनुकूलन है और एक औसत दर्जे का सुधार नहीं है। जरा देखिए कि साइकिल कितने साइकल लेती है और कितनी कैश लाइन निकालती है। तालिका के आदेश से सर्वश्रेष्ठ एक कैश लाइन पर बचत करने से कोई फर्क नहीं पड़ने वाला है।

— आर ..

@R .. "मैंने लोकप्रिय DBMS और कुछ नेटवर्क और डेस्कटॉप एप्लिकेशन के स्ट्रेस आउटपुट के साथ tpcc कर्नेल प्रोफाइलिंग जानकारी के कार्य में नंबरिंग को चुना।" निश्चित रूप से ध्वनि करता है जैसे कि माप थे। हालाँकि लेखक ने कोई संख्या नहीं दी या पर्याप्त रूप से कार्यप्रणाली की व्याख्या नहीं की।

— user45891