मैं एक खिलौना ओएस लिख रहा हूं (नींद के कार्यान्वयन के बारे में)

एक खिलौना ओएस पर काम करने के लिए समर्पित ब्लॉग के लिए एक और पोस्ट। पिछली बार मैंने एक साधारण AHCI (SATA) ड्राइवर की आवश्यकता के बारे में लिखा था। इस दिशा में आगे बढ़ने से पहले, मैंने ड्राइवर बुनियादी ढांचे को रेखांकित करने का फैसला किया: सामान्य ड्राइवर इंटरफ़ेस + अपडेटेड स्टोरेज डिवाइस ड्राइवर इंटरफ़ेस। इन इंटरफेस के निर्माण से एक समस्या सामने आई, जिस पर मैंने पहले ध्यान नहीं दिया था - पोर्टेबिलिटी की समस्या।

प्लेटफ़ॉर्म-इंडिपेंडेंट कोड (उदाहरण के लिए, अधिकांश शेड्यूलर, सहायक कोड जैसे kprintf, ...) कोड के साथ मिलाता है जो केवल x86_64 (सिस्टम डिस्क्रिप्टर टेबल, APIC, इंटरप्ट, ...) के लिए है। हालाँकि मुझे ड्राइवर इंटरफ़ेस तैयार करने से कुछ भी नहीं रोक रहा था, जो कि x86_64 (विशेष रूप से पीसीआई पते के साथ स्वतंत्र रूप से संचालित करने के लिए) के लिए कसकर बाध्य था, यह मेरे लिए स्पष्ट हो गया कि स्पष्ट रूप से कोड को सामान्य पोर्टेबल कोड से एक विशिष्ट प्लेटफ़ॉर्म से अलग किए बिना, मैं केवल स्थिति को बढ़ाऊंगा। इसलिए, मैंने सामान्य रूप से (रूट src /) कोड को विशिष्ट से अलग करके, प्लेटफ़ॉर्म के लिए (src / x86_64 /) में कोड से रूट करने का निर्णय लिया। यह मैं पिछले दो सप्ताह से कर रहा हूं।

मैं एक अनुसूचक के उदाहरण का उपयोग करके कोड पृथक्करण के तंत्र का संक्षेप में वर्णन करूंगा। Src / Schedule.h अनुसूचक इंटरफ़ेस में (#include) एक विशेष src / x86_64 / schedule.inc फ़ाइल शामिल है, जिसमें प्लेटफ़ॉर्म-निर्भर स्थिर इनलाइन फ़ंक्शंस (इंटरफ़ेस और आंतरिक दोनों) शामिल हैं। सभी आंतरिक वर्ण (इंटरफ़ेस से संबंधित नहीं, लेकिन स्थिर नहीं हैं) "__" उपसर्ग के साथ उपसर्ग किए गए हैं। मुख्य अनुसूचक कार्यान्वयन src / Schedule.c में है, अलग आंतरिक कार्य और कोडांतरक कोड src / x86_64 / schedule.c में हैं। इस प्रकार, शेड्यूलर कोड "स्प्रीड" दो निर्देशिकाओं में है। बेशक, यह जटिलता केवल सामान्य मामले के लिए है, जबकि कई मॉड्यूल एक सरलीकृत योजना के अनुसार बनाए गए हैं। उदाहरण के लिए, cpu_info (तार्किक प्रोसेसर जानकारी) के लिए, हेडर src / में स्थित है, और कार्यान्वयन src / x86_64 / में स्थित है। या एक पूरी तरह से प्लेटफ़ॉर्म-विशिष्ट APIC पूरी तरह से src / x86_64 / में रखा गया है।

अब वादा किया नींद समारोह के बारे में। म्यूटेक्स के विपरीत, नींद के कार्यान्वयन को अनुसूचक (यद्यपि न्यूनतम) के कुछ संशोधन की आवश्यकता थी। निम्नलिखित भाग इंटरफ़ेस भाग ( src / schedule.h ) में जोड़े गए थे:

typedef void (*timer_proc)(uint64_t ticks); uint64_t get_ticks(void); timer_proc get_timer_proc(void); uint64_t get_timer_ticks(void); // is zeroed after triggering void set_timer_proc(timer_proc proc); // called within a timer interrupt void set_timer_ticks(uint64_t ticks); // not thread-safe 

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

 static inline void handle_timer(int cpu) { if (cpu == get_bsp_cpu()) ticks++; if (timer_ticks[cpu] && timer_ticks[cpu] <= ticks) { uint64_t prev_ticks = timer_ticks[cpu]; timer_ticks[cpu] = 0; set_outer_spinlock(true); timer_proc_(prev_ticks); set_outer_spinlock(false); } } 

प्रत्येक टाइमर रुकावट पर handle_timer फ़ंक्शन को कहा जाता है। इस तथ्य के बावजूद कि टिक काउंटर केवल बूटस्ट्रैप प्रोसेसर के लिए बढ़ा हुआ है, टाइमर प्रत्येक तार्किक प्रोसेसर के लिए स्वतंत्र रूप से प्रोग्राम किया गया है। Set_outer_spinlock में हैंडलर कॉल को लपेटना आवश्यक है ताकि हैंडलर के अंदर release_spinlock कॉल गलती से STI निर्देश को निष्पादित न करें (यह मत भूलो कि हम एक रुकावट के संदर्भ में हैं)।

अब, शेड्यूलर की इस उन्नत कार्यक्षमता का उपयोग करके, हम नींद ( src / Sync.c ) को लागू कर सकते हैं।

 struct sleep_node { struct sleep_node *next; thread_id thread; uint64_t ticks; }; static struct sleep_data { struct sleep_node *tail; struct mem_pool pool; struct spinlock lock; } sleeping[CONFIG_CPUS_MAX]; static void sleep_timer_proc(UNUSED uint64_t ticks) { struct sleep_data *slp = &sleeping[get_cpu()]; if (slp->tail) { struct sleep_node *node = slp->tail; slp->tail = slp->tail->next; if (slp->tail) set_timer_ticks(slp->tail->ticks); resume_thread(node->thread); free_block(&slp->pool, node); } } err_code sleep(uint64_t period) { struct sleep_data *slp = &sleeping[get_cpu()]; err_code err = ERR_NONE; acquire_spinlock(&slp->lock, 0); struct sleep_node *node = alloc_block(&slp->pool); if (node) { node->thread = get_thread(); node->ticks = get_ticks() + period / CONFIG_SCHEDULER_TICK_INTERVAL; if (!slp->tail || slp->tail->ticks > node->ticks) { // is first to wake up node->next = slp->tail, slp->tail = node; set_timer_ticks(node->ticks); } else { struct sleep_node *prev = slp->tail; while (prev->next && prev->next->ticks <= node->ticks) prev = prev->next; node->next = prev->next, prev->next = node; } pause_this_thread(&slp->lock); } else err = ERR_OUT_OF_MEMORY; if (err) release_spinlock(&slp->lock); return err; } 

उपरोक्त कोड को कुछ स्पष्टीकरण की आवश्यकता है:

1. स्लीप_डेटा संरचना का एक उदाहरण तार्किक प्रोसेसर से मेल खाता है। Sleep_node के लिए पूल प्रत्येक प्रोसेसर के लिए स्वतंत्र है, क्योंकि mem_pool थ्रेड सुरक्षित नहीं है।

यही कारण है कि मुझे म्यूटेक्स कोड में छिपाने की एक गंभीर गलती है: सभी म्यूटेक्स के लिए, म्यूटेक्स_नोड के लिए एक एकल पूल प्रदान किया गया है, लेकिन यह आवश्यक है कि प्रत्येक म्यूटेक्स का अपना पूल हो। मैं निकट भविष्य में इसे ठीक करने की योजना बना रहा हूं।

2. जैसा कि आप कोड से देख सकते हैं, जब सूची में जोड़ा जाता है, तो धाराओं को उस समय तक रैंक किया जाता है जब वे जागते हैं (टिक्स में)।

3. Sleep_timer_proc फ़ंक्शन हैंडलर है जिसे टाइमर रुकावट के संदर्भ में अनुसूचक द्वारा बुलाया जाता है। उसका काम वांछित प्रवाह को जगाना है।

बाकी काफी पारदर्शी लगता है।