OS-এর গঠন — monolithic, microkernel, hybrid আর module

১ · OS কী সেবা দেয় — আর কোন দরজা দিয়ে

পর্ব ০১-এ দেখেছেন, OS হলো কম্পিউটারের ব্যবস্থাপক। পর্ব ০৫-এ দেখেছেন, প্রোগ্রাম OS-এর কাছে কিছু চাইলে system call করে, আর CPU তখন user mode থেকে kernel mode-এ যায়। এই পর্বের প্রশ্নটি তার এক ধাপ ওপরে: OS নামের এই বিশাল সফটওয়্যারটি — বিশেষ করে তার কেন্দ্রীয় অংশ kernel — ভেতরে কীভাবে সাজানো? কোন অংশ কোথায় থাকে, কে কাকে ডাকে, আর একটি অংশ ভেঙে পড়লে বাকিদের কী হয়?

গঠন বোঝার আগে দেখে নিই OS আসলে কী কী কাজ দেয়। প্রায় সব OS-এর পাঠ্যবইয়ে একই তালিকা পাবেন। প্রথম দলটি ব্যবহারকারী ও প্রোগ্রামের সরাসরি সুবিধার জন্য:

দ্বিতীয় দলটি সিস্টেমকে দক্ষ ও নিরাপদ রাখার জন্য: resource বণ্টন (কে কতক্ষণ CPU, কত মেমরি পাবে), হিসাব রাখা (কে কতটা ব্যবহার করল, log), আর সুরক্ষা ও নিরাপত্তা (একজনের ফাইল আরেকজন যেন না পড়ে, বাইরের আক্রমণ যেন না ঢোকে)।

তিনটি দরজা: CLI, GUI আর API

এই সেবাগুলো পাওয়ার জন্য OS তিন রকম দরজা খোলা রাখে। মানুষের জন্য দুটি, প্রোগ্রামের জন্য একটি।

একটি মজার ও কাজের পার্থক্য খেয়াল করুন। Linux তার system call-এর নম্বরগুলো স্থির রাখে — কয়েক দশক পুরোনো প্রোগ্রামও নতুন kernel-এ চলে, কারণ Linus Torvalds-এর বিখ্যাত নিয়ম “user space ভাঙা চলবে না”. Windows উল্টো পথে হাঁটে: ভেতরের system call নম্বর Windows-এর এক build থেকে আরেক build-এ বদলাতে পারে, তাই প্রোগ্রামকে সবসময় Win32 API-র (ভেতরে ntdll.dll) মাধ্যমেই যেতে হয়। macOS-এও Apple শুধু library-র মাধ্যমে যাওয়াকেই সমর্থিত পথ বলে। অর্থাৎ “স্থির চুক্তি” কোথায় — kernel-এর দরজায়, নাকি library-র দরজায় — সেটি OS-ভেদে ভিন্ন।

Policy বনাম mechanism — নকশার প্রথম নীতি

ঢাকার একটি ব্যস্ত ট্রাফিক মোড়ের কথা ভাবুন। খুঁটিতে লাগানো লাল-সবুজ বাতি, তার ভেতরের টাইমার আর তার — এগুলো হলো mechanism: কীভাবে গাড়ি থামানো বা ছাড়া হবে। আর সকাল ৯টায় মিরপুর রোডের দিকে ৯০ সেকেন্ড সবুজ, রাতে ৩০ সেকেন্ড — এটি policy: কী করা হবে, কাকে কতটা অগ্রাধিকার। ভালো নকশায় policy বদলাতে বাতির খুঁটি ভাঙতে হয় না, শুধু নিয়মটি বদলালেই চলে।

২ · সরল গঠন আর monolithic kernel — MS-DOS, Unix, Linux

প্রথমে সবচেয়ে সরল উত্তরটি দেখি: “আলাদা করার দরকার কী? সব এক জায়গায় রাখি।”

সরল গঠন: MS-DOS

১৯৮১ সালে IBM PC-র সাথে আসা MS-DOS-এ কোনো স্পষ্ট স্তর বা সীমানা ছিল না। প্রোগ্রাম চাইলে OS-এর ফাংশন ডাকত, আবার চাইলে সরাসরি স্ক্রিনের মেমরিতে লিখত বা ডিস্ক কন্ট্রোলারের পোর্টে নির্দেশ পাঠাত। কারণটি হার্ডওয়্যারেও: Intel 8088 CPU-তে user mode আর kernel mode-এর পার্থক্যই ছিল না (পর্ব ০৪)। ফল — একটি প্রোগ্রামের ভুলে পুরো কম্পিউটার আটকে যেত, আর “রিস্টার্ট করুন” ছিল নিত্যদিনের সমাধান। ছোট, সস্তা মেশিনের জন্য এটি তখন যুক্তিসংগত ছিল; কিন্তু একসাথে অনেক প্রোগ্রাম আর অনেক ব্যবহারকারীর যুগে চলে না।

Monolithic kernel: সব এক ছাদের নিচে, কিন্তু user-এর থেকে আলাদা

Monolithic kernel-এ একটি বড় সীমানা আছে: নিচে kernel, ওপরে user program. কিন্তু kernel-এর ভেতরে process ব্যবস্থাপনা, মেমরি, file system, নেটওয়ার্ক stack, device driver — সব একটি প্রোগ্রাম, একটি address space, একই kernel mode-এর পূর্ণ ক্ষমতা নিয়ে চলে। এক অংশ আরেক অংশকে ডাকে সাধারণ C ফাংশন কলের মতো — কোনো মধ্যস্থতা নেই।

১৯৭০-এর দশকে Bell Labs-এর মূল Unix এই ধাঁচের — একটি kernel, তার ওপরে shell আর ছোট ছোট system program. ১৯৯১ সালে ফিনল্যান্ডের ছাত্র Linus Torvalds Linux লেখা শুরু করেন একই monolithic ধাঁচে। আজকের Linux kernel কয়েক কোটি লাইনের — তার বড় অংশ, সাধারণত অর্ধেকেরও বেশি, শুধু device driver. Android ফোন, বেশিরভাগ ওয়েব সার্ভার, ক্লাউড, সুপারকম্পিউটার — সবখানে এই monolithic kernel চলছে। অর্থাৎ “পুরোনো ধাঁচ” মানেই বাতিল নয়; এর গতির সুবিধা খুব বাস্তব।

আপনি যে কম্পিউটারে কোড চালাচ্ছেন, তার kernel নিজের পরিচয় কী দেয়? নিচের স্ক্রিপ্টটি চালিয়ে দেখুন। এটি একটি container-এর ভেতরে চলে, তাই কিছু ফাইল লুকানো বা খালি থাকতে পারে — সেজন্য প্রতিটি পড়া 2>/dev/null || echo … দিয়ে সাবধানে করা:

echo "== uname -a =="
uname -a
echo "== /proc/version =="
cat /proc/version 2>/dev/null || echo "/proc/version not readable here"
echo "== /proc/sys/kernel (first 10 entries) =="
ls /proc/sys/kernel 2>/dev/null | head || echo "/proc/sys/kernel not available"
echo "== ostype and osrelease =="
cat /proc/sys/kernel/ostype /proc/sys/kernel/osrelease 2>/dev/null || echo "not available"
echo "== loaded modules =="
if [ -r /proc/modules ] && [ -s /proc/modules ]; then
  echo "visible modules: $(wc -l < /proc/modules)"
else
  echo "/proc/modules is empty or hidden here (container)"
fi
echo "== /sys/module =="
if [ -d /sys/module ]; then
  echo "entries: $(ls /sys/module | wc -l)"
  ls /sys/module | head -5
else
  echo "/sys/module not mounted here"
fi
echo "tainted = $(cat /proc/sys/kernel/tainted 2>/dev/null || echo unknown)"

Linux 7d2d0558be46 6.8.0-137-generic #137-Ubuntu SMP PREEMPT_DYNAMIC Fri Jul 17 20:28:23 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
Linux version 6.8.0-137-generic (buildd@lcy02-amd64-064) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) ...
acct
acpi_video_flags
apparmor_display_secid_mode
...
Linux
6.8.0-137-generic
/proc/modules is empty or hidden here (container)
entries: 247
8021q
8250
...
tainted = 0

৩ · Layered — Dijkstra-র THE সিস্টেম

সব এক জায়গায় রাখলে বড় সমস্যা হলো বোঝা আর প্রমাণ করা কঠিন — যেকোনো অংশ যেকোনো অংশকে ডাকতে পারে। ১৯৬৮ সালে নেদারল্যান্ডসের আইন্দহোফেন প্রযুক্তি বিশ্ববিদ্যালয়ে (Technische Hogeschool Eindhoven) Edsger W. Dijkstra ও তাঁর দল একটি ভিন্ন পথ দেখান। তাঁদের “THE multiprogramming system”-এর বিবরণ সে বছর Communications of the ACM-এ প্রকাশিত হয়। নিয়মটি সহজ: OS-কে কয়েকটি স্তরে (layer) ভাগ করুন। প্রতিটি স্তর শুধু নিজের নিচের স্তরগুলোর সেবা ব্যবহার করতে পারবে, কখনো ওপরের নয়।

THE-তে ছয়টি স্তর ছিল। সবচেয়ে নিচের স্তর ০ CPU বণ্টন আর প্রসেসের মধ্যে সমন্বয় করত — এখানেই Dijkstra-র semaphore (P আর V অপারেশন) প্রথম বাস্তবে কাজে লাগে, যা আপনি পর্ব ২৪-এ বিস্তারিত পড়বেন। স্তর ১ মেমরি সামলাত: মূল মেমরি (core) আর ধীরগতির ঘূর্ণায়মান drum-এর মধ্যে তথ্য আনা-নেওয়া। একটি user program একটি লাইন ছাপতে চাইলে কী হয়, ধাপে ধাপে দেখুন:

তাহলে আজকের OS-গুলো পুরোপুরি layered নয় কেন? দুটি কারণ। এক, গতি: প্রতিটি অনুরোধকে অনেকগুলো স্তর পার হতে হয়, প্রতিটি পারাপারে কিছু খরচ। দুই, কোন অংশ কোন স্তরে — এই সিদ্ধান্তই কঠিন। ধরুন মেমরি-ব্যবস্থাপকের ডিস্ক থেকে পাতা আনতে হয় (তাই ডিস্ক driver তার নিচে থাকা উচিত), আবার ডিস্ক driver-এর buffer-এর জন্য মেমরি লাগে (তাই মেমরি-ব্যবস্থাপক তার নিচে থাকা উচিত)। দুটোই একসাথে সত্য হতে পারে না। বাস্তবের kernel তাই কঠোর স্তর মানে না; কিন্তু layered চিন্তা সর্বত্র রয়ে গেছে — নেটওয়ার্ক stack (TCP/IP-এর স্তর), Windows-এর HAL (হার্ডওয়্যার-ভেদ লুকানোর স্তর), আর Linux-এর VFS → file system → block layer → driver ক্রম।

৪ · Microkernel — kernel ছোট, বাকিরা user space-এ

এবার একেবারে উল্টো প্রশ্ন: kernel mode-এ সর্বনিম্ন কতটুকু না রাখলেই নয়? Microkernel-এর উত্তর: শুধু তিনটি mechanism — (১) address space তৈরি ও আলাদা রাখা (মেমরি সুরক্ষা), (২) থ্রেড চালানো ও CPU বদলানো (scheduling), আর (৩) প্রসেসগুলোর মধ্যে বার্তা পাঠানো (IPC). File system, device driver, নেটওয়ার্ক stack — সবাই আলাদা আলাদা user-mode প্রসেস, যাদের বলে server. একটি প্রোগ্রাম ফাইল পড়তে চাইলে kernel-কে বলে না “ফাইলটি পড়ে দিন”, বলে “এই বার্তাটি file server-এর কাছে পৌঁছে দিন।” এই ধাঁচকে বলে message passing.

একটি সাধারণ read() দুই রকম kernel-এ কোন পথে যায়, পাশাপাশি দেখুন। নিচের হিসাব-টেবিলে কতবার kernel-এ ঢুকতে হলো (trap), কতবার এক প্রসেস থেকে আরেক প্রসেসে CPU বদলাল (context switch), আর কতবার ডেটা কপি হলো — খেয়াল রাখুন:

শুধু ছবি নয় — একটি খেলনা সিমুলেশন চালিয়ে দেখুন। এখানে monolithic অংশে file system আর driver সাধারণ C ফাংশন; microkernel অংশে তারা “server”, আর ipc() ফাংশনটি kernel-এর ভূমিকায় বার্তা কপি করে, প্রতিবার trap, context switch আর বার্তার হিসাব বাড়ায়:

#include <stdio.h>
#include <string.h>
typedef struct { int traps, switches, msgs, copies; } Cost;
typedef struct { int op, len; char data[16]; } Msg;
static const char disk[16] = "Hello, Dhaka!";

/* Monolithic: FS and driver are plain functions inside one kernel */
static void driver_read(char *b, int n, Cost *c) { memcpy(b, disk, n); c->copies++; }
static void fs_read(char *b, int n, Cost *c) { driver_read(b, n, c); }
static void mono_read(char *ubuf, int n, Cost *c) {
    char kbuf[16]; c->traps++;            /* one trap into the kernel */
    fs_read(kbuf, n, c);                  /* direct function calls    */
    memcpy(ubuf, kbuf, n); c->copies++;   /* kernel buffer -> user    */
}
/* Microkernel: FS and driver are user-space servers; kernel only passes messages */
static void ipc(Msg *to, const Msg *from, Cost *c) {
    c->traps++; c->switches++; c->msgs++;
    *to = *from; c->copies++;             /* kernel copies the message */
}
static void micro_read(char *ubuf, int n, Cost *c) {
    Msg req = {1, n, ""}, at_fs, at_drv, reply_fs, reply_app;
    ipc(&at_fs, &req, c);                 /* app    -> FS server   */
    ipc(&at_drv, &at_fs, c);              /* FS     -> disk driver */
    memcpy(at_drv.data, disk, n); c->copies++;  /* driver reads disk */
    ipc(&reply_fs, &at_drv, c);           /* driver -> FS          */
    ipc(&reply_app, &reply_fs, c);        /* FS     -> app         */
    memcpy(ubuf, reply_app.data, n);      /* reply sits in app memory */
}
int main(void) {
    char a[16] = "", b[16] = ""; Cost m = {0}, k = {0};
    mono_read(a, 14, &m); micro_read(b, 14, &k);
    printf("%-12s %-14s traps switches msgs copies\n", "design", "data");
    printf("%-12s %-14s %5d %8d %4d %6d\n", "monolithic", a, m.traps, m.switches, m.msgs, m.copies);
    printf("%-12s %-14s %5d %8d %4d %6d\n", "microkernel", b, k.traps, k.switches, k.msgs, k.copies);
}

design       data           traps switches msgs copies
monolithic   Hello, Dhaka!      1        0    0      2
microkernel  Hello, Dhaka!      4        4    4      5

চারটি বিখ্যাত microkernel

Microkernel-এর লাভগুলো তাহলে কী? নির্ভরযোগ্যতা — একটি server ভেঙে পড়লে শুধু সেটিই পড়ে। নিরাপত্তা — kernel mode-এ চলা কোড অনেক কম, তাই যে কোডকে অন্ধভাবে বিশ্বাস করতে হয় (trusted computing base) তা ছোট; seL4-এর মতো kernel কয়েক হাজার লাইনের, আর Linux-এর কয়েক কোটি। বদলানো ও বাড়ানো সহজ — নতুন file system মানে একটি নতুন user-mode প্রোগ্রাম, kernel ছোঁয়ার দরকার নেই। দামটি তো দেখলেনই: প্রতিটি সেবায় বাড়তি বার্তা ও context switch.

৫ · Driver কোথায় থাকে — একটি বাগ কেন পুরো কম্পিউটার ফেলে দেয়

Device driver হলো সেই কোড, যা একটি নির্দিষ্ট যন্ত্রের — Wi-Fi কার্ড, প্রিন্টার, গ্রাফিক্স কার্ড — ভাষা জানে (পর্ব ৩৯)। প্রতিটি নতুন যন্ত্রের জন্য নতুন driver লাগে, আর এগুলো প্রায়ই লেখে যন্ত্রের নির্মাতা কোম্পানি, OS-এর মূল দল নয়। ফলে OS-এর কোডের মধ্যে driver-ই সবচেয়ে বেশি, সবচেয়ে বৈচিত্র্যময়, আর গড়ে সবচেয়ে কম পরীক্ষিত।

গবেষণাও তাই বলে। ২০০১ সালে Stanford-এর Andy Chou ও সহকর্মীরা Linux-এর কোড স্বয়ংক্রিয়ভাবে বিশ্লেষণ করে দেখান, driver-এর কোডে বাগের হার kernel-এর বাকি অংশের চেয়ে কয়েকগুণ বেশি। ২০০৩ সালে Michael Swift ও সহকর্মীরা তাঁদের “Nooks” গবেষণাপত্রে উল্লেখ করেন, Microsoft-এর তথ্য অনুযায়ী Windows XP-র সাম্প্রতিক crash-গুলোর প্রায় ৮৫ শতাংশের কারণ ছিল driver.

একই বাগ — একটি NULL pointer (কোথাও নির্দেশ করে না এমন pointer) থেকে মান পড়া — দুই রকম kernel-এ কী ঘটায়, দেখুন:

এর একটি বড় বাস্তব উদাহরণ ২০২৪ সালের ১৯ জুলাই। সাইবার-নিরাপত্তা কোম্পানি CrowdStrike-এর Falcon সফটওয়্যারের kernel-mode অংশের জন্য পাঠানো একটি ত্রুটিপূর্ণ কনফিগারেশন আপডেটে Windows কম্পিউটার চালু হতেই crash করতে থাকে। Microsoft-এর হিসাবে প্রায় ৮৫ লাখ Windows যন্ত্র আক্রান্ত হয়; বিশ্বজুড়ে বিমান, ব্যাংক, হাসপাতাল ও সম্প্রচারের কাজ ব্যাহত হয়। কোডটি kernel mode-এ চলছিল বলেই একটি ভুল পুরো OS ফেলে দিয়েছিল।

তাই আজকের প্রবণতা: যতটা সম্ভব driver-কে kernel-এর বাইরে আনা, বা kernel-এর ভেতরেও দেয়াল তোলা। Windows-এ আছে User-Mode Driver Framework (UMDF), আর আধুনিক গ্রাফিক্স driver-এর বড় অংশ user mode-এ চলে। Apple ২০১৯ সালে macOS Catalina থেকে DriverKit চালু করে user space-এ driver লেখার জন্য, আর পুরোনো kernel extension-কে ধীরে ধীরে নিরুৎসাহিত করছে। Linux-এ আছে নিরাপদভাবে kernel-এ ছোট প্রোগ্রাম চালানোর eBPF (যার কোড আগে একটি verifier যাচাই করে, পর্ব ৫৫), আর ২০২২ সালের Linux 6.1 থেকে driver লেখার জন্য Rust ভাষার প্রাথমিক সমর্থন — যাতে NULL pointer-এর মতো ভুল compile-এর সময়েই ধরা পড়ে।

৬ · Loadable module — চলন্ত kernel-এ নতুন অংশ জোড়া

Monolithic kernel-এর একটি ব্যবহারিক সমস্যা ছিল: নতুন একটি USB যন্ত্রের driver লাগলে পুরো kernel আবার compile করে রিবুট করতে হতো। আবার সম্ভাব্য সব যন্ত্রের driver আগে থেকে kernel-এ রাখলে kernel বিশাল হয়ে যায়, অথচ একটি কম্পিউটারে তার সামান্য অংশই লাগে। সমাধান: loadable kernel module (LKM) — kernel-এর একটি অংশ আলাদা ফাইলে রাখা, যা চলন্ত kernel-এ দরকারমতো জোড়া বা খোলা যায়, রিবুট ছাড়াই।

Linux-এ module-এর ফাইলের নাম .ko (kernel object). ১৯৯০-এর দশকের মাঝামাঝি Linux-এ এই সুবিধা যোগ হয়, আর আজ বেশিরভাগ distribution-এ driver আর file system-এর বড় অংশ module হিসেবেই আসে। Sun-এর Solaris-ও একই নকশা নেয় — একটি ছোট মূল kernel, আর তার চারপাশে scheduling class, file system, device driver, executable-এর ধরন ইত্যাদির loadable module. একটি সবচেয়ে ছোট module দেখতে এমন:

#include <linux/module.h>
#include <linux/init.h>

MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Smallest possible example module");

static int __init hello_init(void)
{
    pr_info("hello: loaded\n");
    return 0;              /* 0 = success; a negative errno aborts loading */
}

static void __exit hello_exit(void)
{
    pr_info("hello: unloaded\n");
}

module_init(hello_init);
module_exit(hello_exit);

এখানে main() নেই, printf নেই — kernel-এ C library থাকে না, তাই লেখা ছাপার জন্য kernel-এর নিজের pr_info, যা লেখে kernel-এর log-এ (dmesg দিয়ে দেখা যায়)। module_init বলে দেয় লোড হওয়ার সময় কোন ফাংশন চলবে, module_exit বলে খোলার সময় কোনটি। এবার দেখুন insmod চালালে ভেতরে কী হয়:

আসল কম্পিউটারে (container-এ নয়) module দেখার কমান্ডগুলো এমন — নিচে একটি উদাহরণ আউটপুট:

$ lsmod | head -6
Module                  Size  Used by
iwlmvm                 802816  0
iwlwifi                598016  1 iwlmvm
cfg80211              1323008  2 iwlmvm,iwlwifi
btusb                  77824  0
bluetooth            1032192  7 btusb

$ modinfo iwlwifi | head -6
filename:       /lib/modules/6.8.0-45-generic/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko.zst
license:        GPL
description:    Intel(R) Wireless WiFi driver for Linux
firmware:       iwlwifi-ty-a0-gf-a0-89.ucode
depends:        cfg80211
vermagic:       6.8.0-45-generic SMP preempt mod_unload modversions

$ sudo modprobe -r iwlmvm iwlwifi   # Wi-Fi driver খুলে ফেলা (Wi-Fi বন্ধ হবে)
$ sudo modprobe iwlwifi             # আবার লোড; modprobe নির্ভরতাও (cfg80211) নিজে আনে

“Used by” কলামে দেখুন — iwlwifi-কে iwlmvm ব্যবহার করছে, তাই আগে iwlmvm না খুলে iwlwifi খোলা যাবে না। insmod শুধু একটি ফাইল লোড করে; modprobe নির্ভরতার তালিকা (modules.dep) দেখে দরকারি সব module ক্রম মেনে আনে — দৈনন্দিন কাজে সেটিই ব্যবহার হয়। আর অন্য OS-এ?

driverquery /v | Select-Object -First 5

লক্ষ করুন, modular kernel গঠনে সুশৃঙ্খল — প্রতিটি module-এর একটি নির্দিষ্ট interface থাকে, layered নকশার মতো কঠোর স্তরের বাধ্যবাধকতা নেই, যেকোনো module যেকোনো রপ্তানি-করা ফাংশন ডাকতে পারে। কিন্তু সুরক্ষায় এটি monolithic-এর মতোই: একটি খারাপ module পুরো kernel ফেলতে পারে। তাই বাইরের বা লাইসেন্স-বহির্ভূত module লোড হলে Linux “tainted” চিহ্ন দেয় — bug report দেখে যেন kernel ডেভেলপাররা বোঝেন, সমস্যা হয়তো বাইরের কোডে।

৭ · Hybrid — Windows NT আর macOS XNU; সাথে exokernel ও unikernel

বাস্তবের বড় OS-গুলো কোনো একটি খাঁটি নকশা মানে না। Hybrid kernel কথাটি সাধারণত বোঝায়: নকশায় microkernel-এর মতো আলাদা আলাদা অংশ ও বার্তা-ভিত্তিক চিন্তা, কিন্তু গতির জন্য সেই অংশগুলো একই kernel address space-এ kernel mode-এ চলে। কেউ কেউ বলেন “hybrid” আসলে বিপণনের শব্দ — শেষ বিচারে এগুলো monolithic-ই। দুই পক্ষের যুক্তিই বুঝে রাখা ভালো।

Windows NT (১৯৯৩)

Dave Cutler-এর নেতৃত্বে Microsoft-এর দল NT নকশা করে microkernel-এর প্রভাবে: নিচে HAL (হার্ডওয়্যার-ভেদ লুকায়), তার ওপর ছোট একটি “kernel” (scheduling, interrupt, সমন্বয়), তার ওপর Executive (মেমরি, I/O, object, security ব্যবস্থাপক)। শুরুতে Win32, OS/2 আর POSIX-এর জন্য আলাদা user-mode “subsystem” ছিল — এক kernel-এর ওপর একাধিক OS-এর চেহারা। কিন্তু ১৯৯৬ সালে NT 4.0-তে গতির জন্য window manager আর গ্রাফিক্সের বড় অংশ user mode থেকে kernel mode-এ (win32k.sys) আনা হয়। Driver-ও kernel mode-এ। ফলে আজকের Windows-এর kernel-ভাগে HAL, kernel, Executive, driver আর গ্রাফিক্সের একাংশ — সবাই একই address space-এ। বিস্তারিত পর্ব ৫৬-এ।

macOS ও iOS-এর XNU

XNU নামটি নিজেই একটি রসিকতা — “X is Not Unix”. এটি এসেছে Steve Jobs-এর NeXT কোম্পানির NeXTSTEP থেকে, যা ১৯৯৭ সালে Apple কিনে নেয়। XNU-তে তিনটি অংশ: Mach (task, thread, virtual memory, IPC), BSD স্তর (FreeBSD থেকে নেওয়া — process, POSIX system call, file system, নেটওয়ার্ক), আর C++-এর একটি সীমিত রূপে লেখা driver-কাঠামো I/O Kit. মূল কথা: Mach থাকলেও BSD আর driver আলাদা server নয় — তিনটিই একই kernel address space-এ, তাই BSD-অংশ Mach-কে বার্তা না পাঠিয়ে সরাসরি ফাংশন ডাকতে পারে। Mach-এর নকশা, monolithic-এর গতি।

আরও দুই দিক: exokernel আর unikernel

Exokernel (১৯৯৫, MIT-তে Dawson Engler ও Frans Kaashoek-এর গবেষণা) microkernel-এর চেয়েও এক ধাপ এগোয়: kernel কোনো সুন্দর বিমূর্ত ধারণাই (ফাইল, সাধারণ virtual memory) দেবে না, শুধু হার্ডওয়্যারের টুকরো — ডিস্কের block, মেমরির পাতা, CPU-র সময় — নিরাপদে ভাগ করে দেবে। ফাইল কীভাবে সাজানো হবে, সেটি প্রোগ্রামের সাথে জোড়া একটি “library OS” ঠিক করবে। ফলে একটি ডেটাবেস নিজের কাজের মতো করে ডিস্ক সাজাতে পারে। এটি মূলত গবেষণার ধারণা, কিন্তু এর চিন্তা পরে অনেক জায়গায় প্রভাব ফেলেছে।

Unikernel ক্লাউড যুগের ধারণা: একটি প্রোগ্রাম আর তার যতটুকু OS-অংশ লাগে, সব মিলিয়ে একটিমাত্র ছোট image বানানো হয়, যা সরাসরি hypervisor-এর (পর্ব ৫০) ওপর চলে। কোনো shell নেই, একাধিক ব্যবহারকারী নেই, user/kernel ভাগও প্রায়ই নেই — এক address space-এ এক প্রোগ্রাম। Cambridge-এর MirageOS (OCaml ভাষায়, ২০১৩) আর পরের Unikraft এর পরিচিত উদাহরণ। সুবিধা: খুব দ্রুত চালু হয়, আক্রমণের জায়গা কম; অসুবিধা: debug করা কঠিন, প্রচলিত টুল চলে না। VM, container আর এদের তুলনা পর্ব ৫২-এ।

৮ · Tanenbaum–Torvalds বিতর্ক আর পাশাপাশি তুলনা

১৯৯২ সালের ২৯ জানুয়ারি আমস্টারডামের Vrije Universiteit-এর অধ্যাপক Andrew S. Tanenbaum, MINIX-এর স্রষ্টা, Usenet-এর comp.os.minix আলোচনা-গ্রুপে একটি পোস্ট দেন, শিরোনাম “LINUX is obsolete”. তাঁর মূল যুক্তি দুটি: এক, ১৯৯১ সালে monolithic kernel বানানো পেছনের দিকে হাঁটা — ভবিষ্যৎ microkernel-এর; দুই, Linux শুধু Intel 386 CPU-র সাথে বাঁধা, অথচ ভবিষ্যতের OS-কে নানা CPU-তে চলতে হবে। তখন ২২ বছরের ছাত্র Linus Torvalds কড়া ভাষায় উত্তর দেন: MINIX-এর নিজের সীমাবদ্ধতা আছে, Linux-এর নকশা বাস্তবে কাজ করে ও দ্রুত, আর “তত্ত্বে সুন্দর” হওয়াই সব নয়। আলোচনায় আরও অনেকে যোগ দেন, যার মধ্যে Unix-এর সহ-স্রষ্টা Ken Thompson-ও ছিলেন। পরে দুজনেই স্বীকার করেন কিছু কথা অতিরিক্ত কড়া হয়েছিল।

পরের তিন দশকে কী হলো? Portability-র প্রশ্নে Torvalds-এর kernel জিতেছে নিজের মতো করে — Linux আজ x86, ARM, RISC-V সহ বহু রকম CPU-তে চলে। বাজারের প্রশ্নে monolithic Linux সার্ভার, ক্লাউড আর Android-এ রাজত্ব করছে। কিন্তু Tanenbaum-এর যুক্তিও হারিয়ে যায়নি: যেখানে ভুলের দাম জীবন বা বিপুল অর্থ — গাড়ি, বিমান, চিকিৎসা, প্রতিরক্ষা — সেখানে QNX, seL4-এর মতো microkernel বা তাদের ধারণা ব্যবহৃত হয়। ২০১৭ সালে নিরাপত্তা-গবেষকেরা জানান, Intel-এর বহু প্রসেসরের ভেতরের Management Engine নামের আলাদা ছোট কম্পিউটারটি MINIX 3-এর একটি রূপ চালায় — হয়তো পৃথিবীর সবচেয়ে বেশি চলা OS-গুলোর একটি, যদিও কেউ চোখে দেখে না। আর driver-কে user space-এ আনা, eBPF, Rust — monolithic জগৎও ধীরে ধীরে microkernel-এর শিক্ষা গ্রহণ করছে।

পাশাপাশি তুলনা

৯ · AI-এর যুগে OS-এর গঠন

“Linux-এ একটি driver লোড করার কমান্ড কী?” বা “microkernel কি monolithic-এর চেয়ে ধীর?” — এমন প্রশ্নে AI কয়েক সেকেন্ডে আত্মবিশ্বাসী উত্তর দেয়। কিন্তু kernel-জগতের তথ্য দ্রুত বদলায়, আর OS-ভেদে খুব আলাদা। AI-এর সাধারণ ভুলগুলো চিনে রাখুন:

AI-এর উত্তর হাতে পেলে — যাচাইয়ের চেকলিস্ট

• কমান্ডটি আমার OS আর version-এর জন্য কি না দেখেছি (Linux distro, Windows build, macOS version)
• man page বা kernel-এর নিজের নথিতে (docs.kernel.org) flag আর আচরণ মিলিয়েছি
• sudo লাগে এমন প্রতিটি ধাপের অর্থ বুঝেছি, আর ফেরানোর উপায় জানি
• ইতিহাস বা সংখ্যা (বছর, লাইন-সংখ্যা, গতির তফাত) নির্ভরযোগ্য উৎসে মিলিয়েছি
• গতির দাবি নিজে মেপে দেখেছি — ছোট পরীক্ষা, একাধিকবার চালিয়ে, চাপের মধ্যে (load) চালিয়ে