क्या लिनक्स विभाजन का उपयोग नहीं करता है, लेकिन केवल पेजिंग करता है?

24

लिनक्स प्रोग्रामिंग इंटरफेस एक प्रक्रिया के वर्चुअल एड्रेस स्पेस का लेआउट दिखाता है। क्या प्रत्येक क्षेत्र आरेख में एक खंड है?

लिनक्स कर्नेल को समझने से ,

क्या यह सही है कि एमएमयू में सेगमेंटेशन यूनिट सेगमेंट और ऑफ़सेट को वर्चुअल मेमोरी एड्रेस में सेगमेंट और मैपिंग यूनिट में मैप करता है, और पेजिंग यूनिट फ़िज़िकल मेमोरी एड्रेस को वर्चुअल मेमोरी एड्रेस को मैप करता है?

मेमोरी मैनेजमेंट यूनिट (MMU) एक तार्किक पते को एक रेखीय पते में एक हार्डवेयर सर्किट द्वारा एक विभाजन इकाई के रूप में बदल देता है; बाद में, एक दूसरी हार्डवेयर सर्किट जिसे पेजिंग यूनिट कहा जाता है, रैखिक पते को एक भौतिक पते में बदल देती है (चित्र 2-1 देखें)।

फिर यह क्यों कहता है कि लिनक्स विभाजन का उपयोग नहीं करता है, लेकिन केवल पेजिंग करता है?

सेगमेंटेशन को 80x86 माइक्रोप्रोसेसरों में शामिल किया गया है ताकि प्रोग्रामर को अपने एप्लिकेशन को तार्किक रूप से संबंधित संस्थाओं, जैसे कि सबरूटीन या वैश्विक और स्थानीय डेटा क्षेत्रों में विभाजित करने के लिए प्रोत्साहित किया जा सके। हालांकि, लिनक्स बहुत सीमित तरीके से विभाजन का उपयोग करता है। वास्तव में, विभाजन और पेजिंग कुछ हद तक बेमानी हैं, क्योंकि दोनों का उपयोग प्रक्रियाओं के भौतिक पता स्थान को अलग करने के लिए किया जा सकता है: विभाजन प्रत्येक प्रक्रिया के लिए एक अलग रेखीय पता स्थान असाइन कर सकता है, जबकि पेजिंग एक ही रैखिक पता स्थान को विभिन्न भौतिक पता स्थानों में मैप कर सकता है । लिनक्स निम्नलिखित कारणों से विभाजन के लिए पेजिंग पसंद करता है:

• मेमोरी प्रबंधन तब सरल होता है जब सभी प्रक्रियाएं समान खंड रजिस्टर मानों का उपयोग करती हैं - अर्थात, जब वे समान रैखिक पते का एक सेट साझा करते हैं।

• लिनक्स के डिजाइन उद्देश्यों में से एक आर्किटेक्चर की एक विस्तृत श्रृंखला के लिए पोर्टेबिलिटी है; RISC आर्किटेक्चर, विशेष रूप से, विभाजन के लिए सीमित समर्थन है।

लिनक्स का 2.6 संस्करण 80x86 आर्किटेक्चर द्वारा आवश्यक होने पर ही विभाजन का उपयोग करता है।

linux kernel virtual-memory

— टिम
स्रोत

क्या आप कृपया संस्करण निर्दिष्ट कर सकते हैं। लेखक के नाम निर्दिष्ट करने में भी यह सहायक हो सकता है। मुझे पता है कि कम से कम एक प्रमुख व्यक्ति से है। हालाँकि, दोनों शीर्षक नाम थोड़े सामान्य हैं, यह मेरे लिए पहले स्पष्ट नहीं था कि आप पुस्तकों के बारे में बात कर रहे थे :-)।

— sourcejedi

2

"सेगमेंटेशन को 80x86 माइक्रोप्रोसेसर में शामिल किया गया है ...": यह सिर्फ सच नहीं है। यह 808x प्रोसेसर की विरासत है, जिसमें 16-बिट डेटा पॉइंटर्स और 64 Kb मेमोरी सेगमेंट थे। खंड बिंदुओं ने आपको अधिक मेमोरी को संबोधित करने के लिए सेगमेंट स्विच करने की अनुमति दी। उस वास्तुकला को 80x86 तक ले जाया गया (सूचक आकार के साथ 33 बिट तक बढ़ गया)। आजकल x86_64 मॉडल में, आपके पास 64 बिट पॉइंटर्स हैं (सैद्धांतिक रूप से - मुझे लगता है कि केवल 48 बिट्स वास्तव में उपयोग किए जाते हैं) 16 एक्सैबाइट्स को संबोधित करते हैं, इसलिए सेगमेंट आवश्यक नहीं हैं।

— jamesqf

2

@jamesqf, अच्छी तरह से, 386 में 32-बिट संरक्षित मोड उन खंडों का समर्थन करता है जो कि 80-बाइट वाले स्केल पॉइंट्स से अलग हैं जो वे 8086 में हैं, इसलिए यह केवल सादे विरासत नहीं है। यह निश्चित रूप से उनकी उपयोगिता के बारे में कुछ नहीं कहना है।

— ilkachachu

@jamesqf 80186 में 8086 के समान मेमोरी मॉडल था, कोई "33 बिट्स" नहीं

— जैसन

जवाब के योग्य नहीं है, इसलिए सिर्फ एक टिप्पणी: सेगमेंट और पेज केवल स्वैपिंग के संदर्भ में तुलनीय हैं (उदाहरण के लिए पेज स्वैपिंग बनाम सेगमेंट स्वैपिंग) और उस संदर्भ में पेज स्वैपिंग सिर्फ ब्लो सेगमेंट को पानी से बाहर स्वैप करता है। यदि आप खंडों को / बाहर स्वैप करते हैं, तो आपको पूरे खंड को स्वैप करना होगा , जो 2-4GB हो सकता है। यह x86 पर उपयोग की जाने वाली वास्तविक चीज़ नहीं है। पृष्ठों के साथ आप हमेशा 4KB इकाइयों पर काम कर सकते हैं। जब मेमोरी एक्सेस करने की बात आती है, तो सेगमेंट और पेज पेज टेबल के माध्यम से संबंधित होते हैं और तुलना संतरे के लिए सेब होगी।

— विभू १

20

X86-64 आर्किटेक्चर लंबे मोड (64-बिट मोड) में विभाजन का उपयोग नहीं करता है।

खंड के चार रजिस्टर: सीएस, एसएस, डीएस, और ईएस को 0, और 2 ^ 64 की सीमा के लिए मजबूर किया जाता है।

https://en.wikipedia.org/wiki/X86_memory_segmentation#Later_developments

ओएस के लिए यह सीमित करना संभव नहीं है कि "रैखिक पते" की कौन सी सीमाएं उपलब्ध हैं। इसलिए यह स्मृति संरक्षण के लिए विभाजन का उपयोग नहीं कर सकता है; यह पूरी तरह से पेजिंग पर निर्भर होना चाहिए।

X86 सीपीयू के विवरण के बारे में चिंता न करें जो केवल 32-बिट मोड में चलने पर लागू होगा। 32-बिट मोड के लिए लिनक्स का उतना उपयोग नहीं किया जाता है। इसे "कई वर्षों के लिए सौम्य उपेक्षा की स्थिति" में भी माना जा सकता है। देखफेडोरा [LWN.net, 2017] में 32-बिट x86 समर्थन ।

(ऐसा होता है कि 32-बिट लिनक्स विभाजन का उपयोग नहीं करता है। लेकिन आपको मुझ पर भरोसा करने की आवश्यकता नहीं है, आप बस इसे अनदेखा कर सकते हैं :-)

— sourcejedi
स्रोत

वह थोड़ा ओवरस्टेट है। विरासत / 8086 सेगमेंट (CS / DS / ES / SS) के लिए बेस / लिमिट लॉन्ग मोड में तय की गई है, लेकिन FS और GS के पास अभी भी मनमाना सेगमेंट बेस है। और CS में लोड किया गया सेगमेंट डिस्क्रिप्टर यह निर्धारित करता है कि सीपीयू 32 या 64-बिट मोड में निष्पादित होता है या नहीं। और x86-64 लिनक्स पर यूजर-स्पेस थ्रेड-लोकल स्टोरेज ( mov eax, [fs:rdi + 16]) के लिए FS का उपयोग करता है । कर्नेल प्रविष्टि बिंदु swapgsमें वर्तमान प्रक्रिया के कर्नेल स्टैक को खोजने के लिए GS (बाद में ) का उपयोग करता है syscall। लेकिन हाँ, विभाजन का उपयोग मुख्य OS मेमोरी प्रबंधन / मेमोरी-सुरक्षा तंत्र के हिस्से के रूप में नहीं किया जाता है।

— पीटर कॉर्ड्स

यह मूल रूप से उस प्रश्न का उद्धरण है जिसका अर्थ है "लिनक्स का 2.6 संस्करण 80x86 वास्तुकला द्वारा आवश्यक होने पर ही विभाजन का उपयोग करता है।" लेकिन आपका दूसरा पैराग्राफ मूल रूप से गलत है। लिनक्स 32 और 64-बिट मोड में मूल रूप से समान रूप से विभाजन का उपयोग करता है। आधार = 0 / सीमा = 2 ^ 32 या 2 ^ 64 क्लासिक सेगमेंट (सीएस / डीएस / ईएस / एसएस) के लिए जो सामान्य निर्देशों द्वारा अनुमानित रूप से उपयोग किए जाते हैं। 32-बिट लिनक्स कोड में चिंता करने के लिए "अतिरिक्त" कुछ भी नहीं है; HW कार्यक्षमता वहाँ है, लेकिन इसका उपयोग नहीं किया गया है।

— पीटर कॉर्ड्स

@PeterCordes आप मूल रूप से गलत उत्तर की व्याख्या कर रहे हैं :-) इसलिए मैंने इसे अपने तर्क को कम अस्पष्ट बनाने की कोशिश करने के लिए संपादित किया है।

— sourcejedi

अच्छा सुधार, अब यह भ्रामक नहीं है। मैं पूरी तरह से आपके वास्तविक बिंदु से सहमत हूं, जो यह है कि आप x86 विभाजन को पूरी तरह से अनदेखा कर सकते हैं और करना चाहिए, क्योंकि यह केवल ऑसदेव प्रणाली-प्रबंधन चीजों के लिए और टीएलएस के लिए उपयोग किया जाता है। यदि आप अंततः इसके बारे में सीखना चाहते हैं, तो यह समझने में बहुत आसान है कि आप पहले से ही एक फ्लैट मेमोरी मॉडल के साथ x86 asm को समझते हैं।

— पीटर कॉर्ड्स

8

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

यह नहीं कहता कि लिनक्स x86 पर विभाजन का उपयोग नहीं करता है, क्योंकि यह संभव नहीं होगा। आपने पहले से ही एक हिस्से पर प्रकाश डाला है, लिनक्स बहुत ही सीमित तरीके से विभाजन का उपयोग करता है । 80x86 आर्किटेक्चर द्वारा आवश्यक होने पर ही दूसरा भाग लिनक्स विभाजन का उपयोग करता है

आपने पहले ही कारणों का हवाला दिया, पेजिंग आसान और अधिक पोर्टेबल है।

— RalfFriedl
स्रोत

7

क्या प्रत्येक क्षेत्र आरेख में एक खंड है?

नहीं।

जबकि विभाजन प्रणाली (एक x86 पर 32-बिट संरक्षित मोड में) को अलग कोड, डेटा और स्टैक सेगमेंट का समर्थन करने के लिए डिज़ाइन किया गया है, व्यवहार में सभी खंड एक ही मेमोरी क्षेत्र में सेट हैं। यही है, वे 0 से शुरू होते हैं और स्मृति ^(*) के अंत में समाप्त होते हैं । यह तार्किक पतों और रैखिक पतों को समान बनाता है।

इसे "फ्लैट" मेमोरी मॉडल कहा जाता है, और यह उस मॉडल की तुलना में कुछ सरल है जहां आपके पास अलग-अलग खंड हैं और फिर उनके भीतर संकेत हैं। विशेष रूप से, एक खंड वाले मॉडल को लंबे समय तक पॉइंटर्स की आवश्यकता होती है, क्योंकि सेगमेंट चयनकर्ता को ऑफसेट पॉइंटर के अलावा शामिल करना पड़ता है। (16-बिट खंड चयनकर्ता + 32 बिट ऑफ़सेट कुल 48 बिट पॉइंटर; बनाम सिर्फ 32-बिट फ़्लैट पॉइंटर।)

64-बिट लंबा मोड वास्तव में फ्लैट मेमोरी मॉडल के अलावा विभाजन का समर्थन नहीं करता है।

यदि आप 286 पर 16-बिट संरक्षित मोड में प्रोग्राम करते हैं, तो आपको सेगमेंट की अधिक आवश्यकता होगी, क्योंकि एड्रेस स्पेस 24 बिट्स है, लेकिन पॉइंटर्स केवल 16 बिट्स हैं।

^{(* ध्यान दें कि मैं याद नहीं कर सकता कि 32-बिट लिनक्स कर्नेल / यूजर्स सेपरेशन को कैसे हैंडल करता है। सेगमेंटेशन यह अनुमति देगा कि यूज़र्सस्पेस सेगमेंट की सीमा निर्धारित करके ताकि वे कर्नेल स्पेस को शामिल न करें। पेजिंग इसके लिए अनुमति देता है क्योंकि यह प्रदान करता है। प्रति-पृष्ठ सुरक्षा स्तर।)}

फिर यह क्यों कहता है कि लिनक्स विभाजन का उपयोग नहीं करता है, लेकिन केवल पेजिंग करता है?

X86 में अभी भी सेगमेंट हैं और आप उन्हें अक्षम नहीं कर सकते। वे बस के रूप में संभव के रूप में कम उपयोग किया जाता है। 32-बिट संरक्षित मोड में, खंडों को फ्लैट मॉडल के लिए सेट करने की आवश्यकता होती है, और 64-बिट मोड में भी वे अभी भी मौजूद हैं।

— ilkkachu
स्रोत

हुह, मुझे लगता है कि एक 32-बिट कर्नेल शायद सीएसडी / डीएस / ईएस / एसएस पर खंड सीमाएं तय करके मेल टेबल बदलने की तुलना में मेल्टडाउन को सस्ते में कम कर सकता है जो उपयोगकर्ता-स्थान को 2 जी या 3 जी से ऊपर पहुंचने से रोकता है। (मेल्टडाउन वील पेज-टेबल प्रविष्टियों में कर्नेल / यूजर बिट के लिए एक वर्कअराउंड है, जो यूजर-स्पेस को उन पेजों से पढ़ने की अनुमति देता है, जो कर्नेल-ओनली हैं। VDSO पृष्ठों को 4 जी के शीर्ष पर मैप किया जा सकता है, हालांकि: wrfsbaseसंरक्षित / कॉम्पिटिटर मोड में गैरकानूनी है, केवल लंबी मोड, इसलिए 32-बिट कर्नेल उपयोगकर्ता-स्थान पर एफएस बेस उच्च सेट नहीं किया जा सकता है।

— पीटर कॉर्ड्स

64-बिट कर्नेल पर, 32-बिट उपयोगकर्ता-स्थान संभावित रूप से 64-बिट कोड सेगमेंट में कूद सकता है, इसलिए आप मेल्टडाउन सुरक्षा के लिए खंड सीमाओं पर निर्भर नहीं हो सकते, केवल एक शुद्ध 32-बिट कर्नेल में। (जिसमें भौतिक रैम के बहुत से मशीनों पर बड़े नुकसान हैं, जैसे कि थ्रेड स्टैक के लिए कम मेम से बाहर चल रहा है।) वैसे भी, हाँ लिनक्स कर्नेल मेमोरी को पेजिंग के साथ बचाता है, जो सामान्य के लिए उपयोगकर्ता-अंतरिक्ष में आधार / सीमा = 0 / -1 को छोड़ देता है। खंड (एफएस / जीएस नहीं जो थ्रेड-लोकल स्टोरेज के लिए उपयोग किए जाते हैं)।

— पीटर कॉर्ड्स

हार्डवेयर पेज टेबल (पीएई) में एनएक्स बिट का समर्थन करने से पहले, कुछ प्रारंभिक सुरक्षा पैच ने उपयोगकर्ता-अंतरिक्ष कोड के लिए गैर-निष्पादन योग्य स्टैक बनाने के लिए विभाजन का उपयोग किया। उदा। linux.com/news/exec-shield-new-linux-security-feature (इंगो मोलनार के पोस्ट में "सोलर डिज़ाइनर की उत्कृष्ट" नॉन-एक्स्ट्रीम स्टैक पैच ") का उल्लेख किया गया है।)

— पीटर कॉर्डेस

3

लिनक्स x86 / 32 इस अर्थ में विभाजन का उपयोग नहीं करता है कि यह सभी खंडों को एक ही रैखिक पते और सीमा से आरंभ करता है। x86 आर्किटेक्चर को सेगमेंट होने के लिए प्रोग्राम की आवश्यकता होती है: कोड केवल कोड सेगमेंट से निष्पादित किया जा सकता है, स्टैक केवल स्टैक सेगमेंट में स्थित हो सकता है, डेटा केवल डेटा सेगमेंट में से एक में हेरफेर किया जा सकता है। लिनक्स इस तंत्र को सभी खंडों को एक ही तरह से सेट करता है (अपवादों के साथ जो आपकी पुस्तक में किसी भी तरह का उल्लेख नहीं करता है), ताकि किसी भी खंड में एक ही तार्किक पता मान्य हो। यह वास्तव में कोई खंड नहीं होने के बराबर है।

— दिमित्री ग्रिगोरीव
स्रोत

2

क्या प्रत्येक क्षेत्र आरेख में एक खंड है?

ये "सेगमेंट" शब्द के 2 लगभग पूरी तरह से अलग-अलग उपयोग हैं।

x86 विभाजन / खंड रजिस्टर: आधुनिक x86 OS एक समतल मेमोरी मॉडल का उपयोग करते हैं, जहां सभी खंडों का आधार = 0 और सीमा = अधिकतम 32-बिट मोड में होता है, वही हार्डवेयर लागू करता है जो 64-बिट मोड में , विभाजन के प्रकार को क्रमिक बनाता है । (एफएस या जीएस को छोड़कर, थ्रेड-स्थानीय भंडारण के लिए 64-बिट मोड में भी उपयोग किया जाता है।)
लिंकर / प्रोग्राम-लोडर सेक्शन / सेगमेंट। ( ईएलएफ फ़ाइल प्रारूप में अनुभाग और खंड का अंतर क्या है )

Usages की एक सामान्य उत्पत्ति है: यदि आप खंडित मेमोरी मॉडल (विशेष रूप से पृष्ठांकित वर्चुअल मेमोरी के बिना) का उपयोग कर रहे थे , तो आपके पास डेटा हो सकता है और बीएसएस पते डीएस सेगमेंट बेस के सापेक्ष हो सकते हैं, एसएस आधार के सापेक्ष ढेर हो सकते हैं, और कोड के सापेक्ष सीएस आधार पता।

तो कई अलग-अलग कार्यक्रमों को अलग-अलग रैखिक पतों में लोड किया जा सकता है, या यहां तक कि शुरू करने के बाद भी स्थानांतरित किया जा सकता है, खंड आधारों के सापेक्ष 16 या 32-बिट ऑफ़सेट को बदले बिना।

लेकिन फिर आपको यह जानना होगा कि सूचक किस खंड के सापेक्ष है, इसलिए आपके पास "बहुत दूर" और इतने पर हैं। (वास्तविक 16-बिट x86 प्रोग्राम को अक्सर अपने कोड को डेटा के रूप में एक्सेस करने की आवश्यकता नहीं होती है, इसलिए कहीं 64k कोड सेगमेंट का उपयोग कर सकता है, और शायद डीएस = एसएस के साथ एक और 64k ब्लॉक, उच्च ऑफसेट से नीचे बढ़ने के साथ, और डेटा पर। नीचे। या सभी खंड आधारों वाला एक छोटा कोड मॉडल)।

कैसे x86 विभाजन पेजिंग के साथ बातचीत करता है

32/64-बिट मोड में पता मानचित्रण है:

सेगमेंट: ऑफ़सेट (सेगमेंट बेस जो आंसर को पकड़े हुए है, या एक निर्देश उपसर्ग के साथ ओवरराइड किया गया है)
32 या 64-बिट रैखिक आभासी पता = आधार + ऑफसेट। (लिनक्स जैसे फ्लैट मेमोरी मॉडल में, पॉइंटर्स / ऑफसेट = लीनियर एड्रेस भी। एफएस या जीएस के सापेक्ष टीएलएस को एक्सेस करते समय छोड़कर।)
पेज टेबल (टीएलबी द्वारा कैश किया गया) 32 (लीगेसी मोड), 36 (विरासत पीएई), या 52-बिट (x86-64) भौतिक पते के लिए रैखिक रेखांकन। ( /programming/46509152/why-in-64bit-the-virtual-address-are-4-bits-short-48bit-long-compared-with-the )।

यह चरण वैकल्पिक है: बूटिंग के दौरान नियंत्रण रजिस्टर में थोड़ी सी सेटिंग करके पेजिंग को सक्षम किया जाना है। पेजिंग के बिना, रैखिक पते भौतिक पते हैं।

ध्यान दें कि विभाजन आपको एक ही प्रक्रिया (या थ्रेड) में 32 या 64 बिट से अधिक वर्चुअल एड्रेस स्पेस का उपयोग करने की अनुमति नहीं देता है , क्योंकि फ्लैट (रैखिक) एड्रेस स्पेस में केवल मैप किए गए बिट्स की संख्या खुद ऑफसेट के रूप में होती है। (यह 16-बिट x 86 के लिए मामला नहीं था, जहां विभाजन वास्तव में 16-बिट रजिस्टरों और ऑफ़सेट्स के साथ 64k से अधिक मेमोरी का उपयोग करने के लिए उपयोगी था।)

सीपीयू कैश सेगमेंट डिस्क्रिप्टर को जीडीटी (या एलडीटी) से लोड करता है, जिसमें सेगमेंट बेस शामिल है। जब आप एक पॉइंटर को डिफाइन करते हैं, तो यह किस रजिस्टर पर निर्भर करता है, यह सेगमेंट के रूप में डीएस या एसएस के लिए डिफॉल्ट करता है। रजिस्टर वैल्यू (पॉइंटर) को सेगमेंट बेस से ऑफसेट के रूप में माना जाता है।

चूंकि सेगमेंट बेस सामान्य रूप से शून्य है, इसलिए सीपीयू विशेष-केस करते हैं। या किसी अन्य के नजरिए से, यदि आप ऐसा एक गैर शून्य खंड आधार है, भार अतिरिक्त विलंबता है, क्योंकि "विशेष" (सामान्य) जोड़ने आधार पते पर लागू नहीं होता को दरकिनार करने का मामला।

लिनक्स x86 सेगमेंट रजिस्टर को कैसे सेट करता है:

CS / DS / ES / SS का आधार और सीमा 32 में सभी 0 / -1 और 64-बिट मोड हैं। इसे फ्लैट मेमोरी मॉडल कहा जाता है क्योंकि सभी पॉइंटर्स एक ही एड्रेस स्पेस में जाते हैं।

(एएमडी सीपीयू आर्किटेक्ट्स ने 64-बिट मोड के लिए एक फ्लैट मेमोरी मॉडल लागू करके विभाजन को रोक दिया क्योंकि मुख्यधारा के OSes वैसे भी इसका उपयोग नहीं कर रहे थे, बिना किसी क्रियान्वयन संरक्षण के जो PAE या x86- के साथ पेजिंग करके बहुत बेहतर तरीके से प्रदान किया गया था- 64 पृष्ठ-तालिका प्रारूप।)

टीएलएस (थ्रेड लोकल स्टोरेज): एफएस और जीएस को लंबे मोड में आधार = 0 पर तय नहीं किया जाता है। (वे 386 के साथ नए थे, और किसी भी निर्देश द्वारा स्पष्ट रूप से उपयोग नहीं किए गए थे, rep-स्ट्रिंग निर्देश भी नहीं जो ईएस का उपयोग करते हैं)। x86-64 लिनक्स टीएलएस ब्लॉक के पते पर प्रत्येक थ्रेड के लिए एफएस आधार पता सेट करता है।

उदाहरण के mov eax, [fs: 16]लिए, इस धागे के लिए टीएलएस ब्लॉक में 16 बाइट्स से 32-बिट मान लोड करता है।
CS सेगमेंट डिस्क्रिप्टर चुनता है कि CPU किस मोड में है (16/32/64-बिट संरक्षित मोड / लॉन्ग मोड)। लिनक्स सभी 64-बिट उपयोगकर्ता-अंतरिक्ष प्रक्रियाओं के लिए एकल GDT प्रविष्टि का उपयोग करता है, और सभी 32-बिट उपयोगकर्ता-स्थान प्रक्रियाओं के लिए एक और GDT प्रविष्टि। (सही काम करने के लिए सीपीयू के लिए, डीएस / ईएस को भी मान्य प्रविष्टियों को सेट करना होगा, और इसी तरह एसएस)। यह विशेषाधिकार स्तर (कर्नेल (रिंग 0) बनाम उपयोगकर्ता (रिंग 3)) भी चुनता है, इसलिए 64-बिट उपयोगकर्ता-स्थान पर लौटने पर भी, कर्नेल को CS को सामान्य के बजाय बदलने, उपयोग करने iretया व्यवस्थित करने की व्यवस्था करनी होती sysretहै) कूदना या हिदायत देना।
X86-64 में, syscallप्रविष्टि बिंदु swapgsउपयोगकर्ता-स्पेस के जीएस से कर्नेल के लिए जीएस फ्लिप करने के लिए उपयोग करता है, जिसका उपयोग वह इस थ्रेड के लिए कर्नेल स्टैक को खोजने के लिए करता है। (धागा-स्थानीय भंडारण का एक विशेष मामला)। syscallअनुदेश गिरी ढेर पर बात करने के लिए ढेर सूचक परिवर्तन नहीं करता है; जब कर्नेल प्रवेश बिंदु ¹ तक पहुँचता है तब भी यह उपयोगकर्ता के ढेर की ओर इशारा करता है ।
CPU / DS / ES / SS को भी संरक्षित मोड / लॉन्ग मोड में काम करने के लिए CPU के लिए मान्य सेगमेंट डिस्क्रिप्टर पर सेट करना होता है, भले ही उन डिस्क्रिप्टर से आधार / सीमा को लॉन्ग मोड में अनदेखा किया गया हो।

तो मूल रूप से x86 विभाजन का उपयोग TLS के लिए किया जाता है, और अनिवार्य x86 osdev सामान के लिए जिसे हार्डवेयर को करने की आवश्यकता होती है।

फुटनोट 1: मजेदार इतिहास: एएमडी 64 सिलिकॉन रिलीज होने से कुछ साल पहले कर्नेल देवों और एएमडी आर्किटेक्ट्स के बीच संदेशों की मेलिंग सूची अभिलेखागार हैं, जिसके परिणामस्वरूप डिजाइन करने के लिए टीकियों syscallका उपयोग किया गया था। विवरण के लिए इस उत्तर में लिंक देखें ।

— पीटर कॉर्डेस
स्रोत