Recientemente एक ईमेल जारी किया गया था लिनक्स कर्नेल मेलिंग सूची के माध्यम से और इस ईमेल का मुख्य उद्देश्य है x32 सबरेल्टक्चर कार्यान्वयन से कोड निकालें (x86 IA-32 के साथ भ्रमित होने की नहीं)।
जो आपको 32-बिट मेमोरी एड्रेसिंग मॉडल का उपयोग करने की अनुमति देता है (हाइब्रिड x86 और x86_64) x86 64-बिट सिस्टम पर।
X32 वास्तुकला क्या है?
यह उल्लेख करना महत्वपूर्ण है कि x32 उप-वास्तुकला एक संकर x86_64 ABI है, जो 32-बिट मेमोरी एड्रेसिंग मॉडल को 64-बिट सिस्टम (प्रोसेसर 64-बिट मोड में संचालित होता है, लेकिन 32-बिट पॉइंटर्स और अंकगणितीय संचालन का उपयोग करता है) की अनुमति देता है।
एबीआई एक्स 32 एप्लिकेशन को x86_64 आर्किटेक्चर का पूर्ण लाभ लेने की अनुमति देता है, जैसे कि अतिरिक्त रजिस्टर और तेज निर्देश, PIC ABI।
उसी समय, एबीआई एक्स 32 32-बिट मेमोरी पॉइंटर्स का समर्थन करता है, जो मेमोरी को बचाता है, प्रोसेसर कैश के अधिक कुशल भरने में योगदान देता है, और कोड निष्पादन की समग्र गति पर सकारात्मक प्रभाव पड़ता है।
ABI X32 की सीमा आवेदन से 4 जीबी से अधिक मेमोरी को निर्देशित करने की असंभवता है।
मई 32 में गठित 3.4 रिलीज के बाद से X2012 समर्थन लिनक्स कर्नेल का हिस्सा रहा है।
डेवलपर्स इस वास्तुकला के रखरखाव के साथ जारी रखने के लिए बहस करेंगे या नहीं
डेवलपर के अनुसार x32 तकनीक को हटाने का प्रस्ताव यह उचित नहीं है और आधुनिक औद्योगिक लेआउट में व्यावहारिक अनुप्रयोग नहीं मिला है।
इसके अलावा, औरl x32 कोड सिस्टम कॉल के साथ काम करने के काफी विवादास्पद तरीके का उपयोग करता है, जो सिस्टम कॉल कार्यान्वयन को संसाधित करने के बाद सामान्य ऑपरेशन को बाधित करने का जोखिम पैदा करता है।
लिनुस टॉर्वाल्ड्स ने कहा कि अगर कोई तर्क प्रस्तुत नहीं किया जाता है तो वह x32 को हटाने के लिए सहमत होंगे या यदि सिस्टम जिसमें x32 सबरेल्टक्चर लागू किया गया है, प्रस्तुत नहीं किया गया है।
लिनस यह भी ध्यान दिया कि एक्स 32 वास्तुकला का उपयोग स्पष्ट रूप से चरम प्रदर्शन परीक्षण तक सीमित थाएस, इस उप-सेवा के लिए समर्थन के रूप में वितरण और विकास के माहौल को बनाए रखने में जटिलताओं का एक बड़ा सौदा के साथ जुड़ा हुआ है।
द मेल:
सभी को नमस्कार।
मैं गंभीरता से लिनक्स से x32 समर्थन को हटाने के लिए एक पैच सबमिट करने पर विचार कर रहा हूं। यहाँ इस के साथ कुछ मुद्दे हैं:
- यह पूरी तरह से स्पष्ट नहीं है कि इसमें उपयोगकर्ता हैं। जहां तक मुझे पता है, यह जेंटू और डेबियन पर समर्थित है
- कॉलिंग सिस्टम के काम करने का तरीका बहुत अजीब है। X32 पर अधिकांश syscalls प्रविष्टि बिंदु के साथ अपने * देशी * (यानी COMPAT_SYSCALL_DEFINE) के माध्यम से प्रवेश करते हैं, और यह जानबूझकर है।
उदाहरण के लिए, adjtimex () नेटिव इनपुट का उपयोग करता है, न कि कॉमपिट इनपुट का, क्योंकि x32 स्ट्रक्चर टाइमएक्स x86-64 लेआउट से मेल खाता है। लेकिन मुट्ठी भर syscalls में अलग प्रवेश बिंदु हैं - ये 512 में शुरू होने वाले syscalls हैं।
ये COMPAT_SYSCALL_DEFINE प्रविष्टि बिंदुओं के माध्यम से दर्ज करते हैं।
X32 syscalls जो 512 रेंज में * नहीं * हैं कर्नेल syscall सम्मेलन के प्रत्येक समानता का उल्लंघन करते हैं।
Syscall हैंडलर में, in_compat_syscall () सही है, लेकिन COMPAT_SYSCALL_DEFINE प्रविष्टि को स्वीकार नहीं किया जाता है यह पागल है और जब लोग अपने syscall कार्यान्वयन को रद्द करते हैं तो आप चीजों को तोड़ने का जोखिम उठाते हैं।
और इन सबसे ऊपर, कोई भी इन चीजों की कोशिश नहीं करता है।
एक मौके पर X32 का परीक्षण करते समय, Gentoo डेवलपर्स में से एक ने निष्कर्ष निकाला कि ABI x32 पर स्विच करने पर प्रदर्शन में सुधार सिंथेटिक परीक्षण शो के रूप में महान नहीं है। ABI x32 के निर्माताओं से:
पिछले x86 आर्किटेक्चर की तुलना में महत्वपूर्ण प्रगति तभी देखी जाती है, लेकिन जब वर्तमान x86-64 आर्किटेक्चर की तुलना में, लाभ नगण्य होता है (x32 के रचनाकारों द्वारा विशेष परीक्षण 40% त्वरण की तुलना में दिखाया गया है, जबकि क्लासिक ABI x 86_64 के साथ, परीक्षण H.264 कोडेक के साथ 15-20% का त्वरण दिखाया गया है)।