हो सकता है कि आधुनिक hardware युग में microkernel पर फिर से विचार करना चाहिए

• पहले उच्च overhead की वजह से व्यावहारिकता कम रखने वाला microkernel आज व्यापक हो चुके IOMMU और shared memory की बदौलत फिर से एक यथार्थवादी विकल्प बन सकता है
• drivers और subsystems को user space में isolate करने से खामी या हमले के प्रभाव-क्षेत्र को सीमित किया जा सकता है, जिससे security·reliability·modularity बढ़ती है
• 1980~90 के दशक में user space process devices तक सीधे पहुंच नहीं सकते थे, इसलिए disk read जैसे हर काम के साथ system call और context switch, lock, memory copy जुड़ जाते थे
• IOMMU और shared command queue का उपयोग करने पर सामान्य path में context switch, address spaces के बीच copy और lock के बिना asynchronous IPC और device access संभाला जा सकता है
• Xen, FreeBSD, Linux DRM जैसे मौजूदा components का उपयोग किया जा सकता है, इसलिए hypervisor और system server को शुरू से फिर बनाने का बोझ भी बहुत बड़ा नहीं है

---

microkernel की संरचना और isolation का प्रभाव

• microkernel scheduling, I/O device access management, process-के-बीच communication (IPC) को छोड़कर बाकी functions को user space में चलाने वाली kernel architecture है
• subsystem isolation तीन फायदे देता है
  • security: किसी एक driver की vulnerability हमलावर को पूरे system के बजाय सिर्फ उसी subsystem या driver की access permission दे सकती है
  • reliability: एक subsystem के crash का असर पूरे system पर नहीं, सिर्फ उसी हिस्से पर पड़ता है
  • modularity: Linux kernel team पर सभी hardware drivers को merge करने और हर chip के internal behavior तक review करने का बोझ कम हो सकता है
• अगर Windows एक microkernel system होता, तो CrowdStrike bug शायद सिर्फ कुछ IT security कर्मियों के telemetry data collection को रोकने तक सीमित रहता

पुरानी performance सीमाएं और IOMMU का समाधान

• पहले के microkernel में user space process किसी खास device तक सीधे नहीं पहुंच सकते थे, इसलिए हर काम के लिए system call और context switch की जरूरत पड़ती थी, और उसके साथ महंगे lock और memory copy भी जुड़ जाते थे
  • Mach ने performance problems की वजह से user space processes को धीरे-धीरे फिर kernel के अंदर ले जाना शुरू किया, और आखिरकार वह सामान्य monolithic kernel के करीब पहुंच गया
• आज के PCs में करीब 10 साल से IOMMU standard रूप से मौजूद है, और shared memory के साथ इसका उपयोग करने पर पर्याप्त core होने वाले सामान्य path में context switch को पूरी तरह हटाया जा सकता है
  • थोड़ी latency स्वीकार करने पर कुल मिलाकर context switch लगभग खत्म किए जा सकते हैं
  • virtualization technology आधारित scheduler को Xen hypervisor जैसी संरचना में बनाया जा सकता है
  • I/O device access को IOMMU hardware manage करता है
• IPC को processes के बीच shared buffer allocate करके और integer atomic compare-and-swap उपलब्ध कराकर implement किया जा सकता है
  • shared buffer को ring buffer के रूप में command queue की तरह इस्तेमाल किया जाता है और start·end pointers को atomically update किया जाता है
  • सामान्य path में context switch, address spaces के बीच copy और lock के बिना asynchronous messages पहुंचाए जा सकते हैं, और GPU driver में भी यह तरीका व्यापक रूप से इस्तेमाल होता है

library संरचना और मौजूदा code का उपयोग

• process अगर VM guest environment में हो, तो shared libraries को program start पर link किया जा सकता है, और जिन functions को दूसरे process में चलाने की जरूरत नहीं है उन्हें exokernel तरीके से local रूप से संभाला जा सकता है
  • आज के दौर में, जहां Electron की तरह applications अपने साथ operating system components भी bundle करके ship करती हैं, memory में duplicated libraries 30 साल पहले जितनी बड़ी समस्या नहीं हैं
• implementation के लिए जरूरी मुख्य आधार भी पहले से मौजूद हैं
  • Xen में hypervisor layer के लिए जरूरी अधिकतर functions पहले से हैं
  • Mach की तरह network और filesystem server बनाए जा सकते हैं, लेकिन उनके लिए FreeBSD code लाया और इस्तेमाल किया जा सकता है
  • DRM पहले से asynchronous command buffer पर आधारित है, इसलिए Linux graphics subsystem को user space में चलाया जा सकता है
  • सुविधा के लिए display server और graphics subsystem को एक ही process में चलाने वाली संरचना भी संभव है

[GN⁺]

Lobste.rs की राय

• Linux में सभी drivers शामिल होने की वजह यह है कि out-of-tree kernel modules के लिए stable API नहीं है, और ऐसा API देने के लिए microkernel अनिवार्य नहीं है

  • microkernel भी internal API की अस्थिरता को नहीं रोकता, बस उसे process boundaries के पार ले जाता है
    मुझे याद है कि LKML पर शिकायतें देखी थीं कि अगर सभी Linux drivers को user space में भी ले जाया जाए, तब भी internal API changes करना मुश्किल हो जाएगा

• क्या L4 परिवार के kernels तेज़ नहीं माने जाते? Redox OS या Fuchsia के बारे में भी जानना दिलचस्प होगा

  • L4 kernel तेज़ हो सकता है, लेकिन व्यवहार में यह बहुत fixed configuration वाले embedded systems में ही काम का लगता है
    Genode कई kernels को support करता है, लेकिन seL4 आदि पर इसका performance हास्यास्पद रूप से खराब है. जब सहकर्मियों ने Linux VM boot करके देखा, तो सिर्फ 32-bit support था, और आधा boot होने में भी कई मिनट लग गए
    NOVA microhypervisor का Genode fork default platform है, इसकी वजह यही है कि वह वास्तव में काम करता है और performance भी पर्याप्त है
  • Redox docs को देखें तो request messages assemble करते समय अब भी context switch होता है, शायद verification step के रूप में
    यह circular buffer इस्तेमाल करता है, इसलिए अगर receiver पहले से किसी दूसरे core पर चल रहा हो तो दूसरा context switch ज़रूरी न भी हो. Context switch के बिना message interpret करने पर receiver को message verify करना पड़ेगा, जिससे attack surface बहुत बढ़ सकती है, लेकिन kernel-provided dynamic libraries से इसे कुछ हद तक कम किया जा सकता है
    मैं विशेषज्ञ नहीं हूँ, लेकिन लगता है कि मूल लेख में कुछ महत्वपूर्ण बातों को छोड़ दिया गया है

• QNX को तेज़ microkernel के रूप में जाना जाता था, तो यह जानना दिलचस्प होगा कि उसने सही क्या किया

  • मैंने खुद जो QNX इस्तेमाल किया, वह तेज़ नहीं था
    पहले मैं और मेरा एक दोस्त microkernels, खासकर QNX की elegance, से बहुत प्रभावित थे और हमने FireWire-आधारित video processing problem को उस पर implement किया. Code सरल और सुंदर था, लेकिन speed बेहद खराब थी. बाद में Linux के 1394 driver में DMA-based isochronous transfer support लगभग 12 घंटे में जोड़ दिया गया, तो performance बहुत बेहतर हो गई, और उसी अनुभव से कंपनी के optical sorting equipment में Linux इस्तेमाल करने को लेकर संदेह भी खत्म हो गया
    QNX, microkernel और message passing का आदर्श अब भी शानदार है, लेकिन इसे व्यापक रूप से अपनाए जाने के लिए processes के बीच data transfer की cost को बहुत कम करना होगा
    अब मैं Elixir में web applications बनाता हूँ और QNX जैसी process isolation का लाभ लेता हूँ. Optical processing जैसी performance-critical workload नहीं है, इसलिए ठीक है, लेकिन Elixir/BEAM में भी data copying की वही समस्या है

• सुना है कि भले ही Mach अपने मूल विचार के अनुसार components को पूरी तरह अलग न कर पाया हो, फिर भी वह साधारण monolithic kernel नहीं बना, और उसकी architecture अब भी कुछ फायदे देती है
  क्लासिक POSIX file listing benchmark की तरह अगर हर item पर readdir() और stat() कॉल किया जाए, तो microkernel को नुकसान होना तय है. लेकिन अगर io_uring जैसी batching API से system calls की आवृत्ति कम कर दी जाए, तो high latency इतनी बड़ी कमजोरी न भी हो सकती है

  • Liedtke का “on μ-Kernel Construction”, 1995 कहता है कि Mach के धीमे होने का कारण बड़ा cache footprint था, यानी design पर्याप्त छोटा नहीं था
    Linux भी हर network packet पर एक system call करे तो line rate के साथ नहीं चल सकता. Batching, Linux और microkernel दोनों में महत्वपूर्ण है

• इस क्षेत्र में एक दिलचस्प नया entrant HongMeng है, लेकिन अफसोस कि यह proprietary software है

• जब तक data movement cost में एक order of magnitude या उससे अधिक की कमी नहीं आती, microkernel के लिए पर्याप्त प्रतिस्पर्धी बनना मुश्किल लगता है
  सिद्धांत में यह elegant और साफ़-सुथरा है, लेकिन वास्तविक दुनिया जटिल है, इसलिए शायद उस जटिलता को संभालने के लिए kernel को भी कुछ हद तक जटिल होना पड़े

• मुझे सही architecture पसंद है, लेकिन Linux के dominant position तक पहुँचने में सिर्फ तकनीक नहीं बल्कि दूसरे सहायक कारक भी बहुत महत्वपूर्ण रहे होंगे. मैं इस पर कई दृष्टिकोणों से विश्लेषण करने वाला लेख पढ़ना चाहूँगा