Linux kernel-এর ভেতর — গঠন, module আর eBPF

১ · Kernel-এর মানচিত্র — source tree-তে কী কোথায়

এই কোর্সের ৫৪টি পর্বে আপনি kernel-এর অনেক অংশ আলাদা আলাদা দেখেছেন: scheduler, page allocator, VFS, driver, namespace. এবার পুরো ভবনটি দেখার পালা। এই পর্ব মূলত জোড়া লাগাবে: আগে শেখা জিনিস আসল kernel-এর কোথায় থাকে, কীভাবে একসাথে চলে, আর আজকের kernel-এ নতুন কী এসেছে।

Linux-এর মূল source থাকে kernel.org-এ, Linus Torvalds-এর git repository-তে (“mainline”). মোটামুটি লাখখানেক ফাইল (সংস্করণভেদে কম-বেশি), আর উপরের স্তরে বিশ-পঁচিশটি ফোল্ডার। সবচেয়ে গুরুত্বপূর্ণগুলো, আর এই কোর্সের কোন পর্বে তাদের কাজ দেখেছেন:

আরও কয়েকটি ছোট কিন্তু চেনার মতো ফোল্ডার: virt/ (KVM, পর্ব ৫০), lib/ (kernel-এর নিজের সাধারণ library — red-black tree, sort, string), crypto/, sound/, scripts/ (build-এর সহায়ক, checkpatch.pl), Documentation/ আর ২০২২ থেকে rust/.

ফোল্ডারগুলো আলাদা হলেও কাজের সময় সবাই একটি monolithic kernel-এর (পর্ব ৬) অংশ — একই address space, একে অপরের ফাংশন সরাসরি ডাকে। একটি read() কীভাবে কয়েকটি বিভাগ পার হয়, নিচের ছবিতে দেখুন:

২ · start_kernel() থেকে PID 1 — kernel-এর প্রথম মুহূর্ত

পর্ব ৭-এ বুটকে বাইরে থেকে দেখেছেন: firmware, bootloader, সংকুচিত vmlinuz, initramfs, তারপর systemd. এবার kernel-এর ভেতর থেকে, C কোডের ভাষায়। Bootloader থেকে আসার পর arch/-এর assembly কোড kernel খুলে (decompress) একটি ন্যূনতম page table বসায়, তারপর সব architecture-এর জন্য এক সাধারণ C ফাংশন ডাকে: init/main.c-এর start_kernel(). তখন শুধু একটি CPU চলে, interrupt বন্ধ, আর চলমান “task” একটিই — যাকে পরে idle task (PID 0, নাম swapper) বলা হবে।

void __init start_kernel(void)
{
        setup_arch(&command_line);   /* RAM map, early page tables, CPU features */
        mm_core_init();              /* buddy + SLUB ready: kmalloc() works now */
        sched_init();                /* one run queue per CPU                   */
        init_IRQ();                  /* interrupt controller                    */
        time_init();                 /* clock and timer tick                    */
        console_init();              /* printk() now reaches the console        */
        local_irq_enable();
        rest_init();                 /* never returns                           */
}

static void rest_init(void)
{
        user_mode_thread(kernel_init, ...);   /* becomes PID 1 */
        kernel_thread(kthreadd, ...);         /* becomes PID 2 */
        cpu_startup_entry(CPUHP_ONLINE);      /* this task becomes the idle loop */
}

__init চিহ্নটি খেয়াল করুন: এই ফাংশনগুলো একটি আলাদা section-এ রাখা হয়, আর বুট শেষ হলে kernel সেই মেমরি ফেরত দেয় — dmesg-এ “Freeing unused kernel image (initmem) memory” লাইনটি এই কারণে। এবার ধাপে ধাপে দেখুন, কে কখন জন্মায়:

মনে রাখার মতো তিনটি সংখ্যা: PID 0 idle task, PID 1 init (kernel-এর ভেতরে জন্ম, পরে user space), PID 2 kthreadd. ps -o pid,comm -p 1,2 দিয়ে শেষ দুটি দেখা যায় (container-এর ভেতরে PID 1 অন্য — পর্ব ৫১)।

৩ · Kernel-এ কোড লেখার নিয়ম — অপারেশন থিয়েটারের শৃঙ্খলা

Kernel C-তে লেখা, কিন্তু সাধারণ C-এর অভ্যাস এখানে প্রায়ই বিপজ্জনক। অপারেশন থিয়েটারের কথা ভাবুন: বাইরের জুতা নিষেধ, চিকিৎসক নিজের জীবাণুমুক্ত যন্ত্র ব্যবহার করেন, মাঝপথে কেউ বিশ্রামে যেতে পারেন না, আর ভুলের দাম রোগীর জীবন। Kernel-এর একটি বাগও পুরো যন্ত্রের — ভেতরে এক অংশকে আরেক অংশ থেকে রক্ষার দেয়াল নেই। তাই কয়েকটি কঠিন নিয়ম:

ঘুমানো যাবে, নাকি যাবে না — দুই রকম context

Kernel-এর কোড সবসময় দুই অবস্থার একটিতে থাকে। Process context: কোনো একটি task-এর পক্ষে চলছে, যেমন syscall-এর ভেতরে; এখানে ঘুমানো (sleep) যায় — ডিস্কের অপেক্ষায় scheduler-কে CPU ছেড়ে দেওয়া, mutex-এ অপেক্ষা করা। Atomic context: interrupt handler, softirq (পর্ব ৩৯), বা spinlock ধরে থাকা অবস্থা; এখানে ঘুমানো নিষেধ, কারণ পেছনে কোনো ঘুমাতে-পারা task নেই, বা যে spinlock ধরে আছে সে ঘুমালে অন্য CPU অনন্তকাল ঘুরতে থাকবে (পর্ব ২৩)। ট্রাফিক মোড়ের মাঝখানে দাঁড়ানো সার্জেন্ট হাত নামিয়ে বিশ্রাম নিতে পারেন না — পুরো মোড় আটকে যাবে।

মেমরি চাওয়ার সময় এই পার্থক্য সরাসরি দেখা যায়, GFP flag-এ (“get free pages”):

• GFP_KERNEL — স্বাভাবিক পছন্দ; মেমরি কম থাকলে allocator page ফেরত আনতে ঘুমাতে পারে, তাই শুধু process context-এ।
• GFP_ATOMIC — কখনো ঘুমায় না, জরুরি সংরক্ষিত মেমরি থেকেও নিতে পারে; interrupt বা spinlock-এর ভেতরে। ব্যর্থ হওয়ার সম্ভাবনা বেশি, তাই NULL পরীক্ষা বাধ্যতামূলক।
• GFP_NOIO, GFP_NOFS — ঘুমাতে পারে, কিন্তু মেমরি খালি করতে ডিস্ক-I/O বা file system-এ ফিরে যাবে না; block বা file system-এর নিজের কোডে, যাতে নিজের ওপর আটকে না যায়।

ত্রুটি ফেরত দেওয়ার রীতি — ঋণাত্মক errno আর ERR_PTR

Kernel-এ global errno নেই। ফাংশন সফল হলে ০ (বা একটি অর্থবহ সংখ্যা), ব্যর্থ হলে ঋণাত্মক errno ফেরত দেয়: return -ENOMEM;. Syscall-এর পথে এই সংখ্যা user space-এ পৌঁছালে glibc তাকে ধনাত্মক করে errno-তে রাখে আর ফাংশন −১ ফেরত দেয় (পর্ব ৫)। আর যে ফাংশন pointer ফেরত দেয়? ত্রুটির সংখ্যাটিকেই pointer-এর ভেতরে লুকানো হয়: address space-এর একেবারে শেষ ৪০৯৫টি ঠিকানায় কোনো বৈধ বস্তু থাকে না, তাই ERR_PTR(-ENOMEM) একটি “অসম্ভব” pointer বানায়, IS_ERR() তা চেনে, PTR_ERR() সংখ্যাটি ফেরত দেয়:

struct buf *buf_create(size_t len)
{
        struct buf *b;

        if (len == 0 || len > SZ_1M)
                return ERR_PTR(-EINVAL);            /* error hidden in the pointer */
        b = kzalloc(sizeof(*b) + len, GFP_KERNEL);  /* may sleep: process context only */
        if (!b)
                return ERR_PTR(-ENOMEM);
        b->len = len;
        return b;
}

static irqreturn_t mydev_irq(int irq, void *data)    /* atomic context */
{
        struct mydev *d = data;
        struct event *e;

        spin_lock(&d->lock);
        e = kmalloc(sizeof(*e), GFP_ATOMIC);         /* GFP_KERNEL here would be a bug */
        if (e)
                list_add_tail(&e->node, &d->events);
        spin_unlock(&d->lock);
        return IRQ_HANDLED;
}

/* caller */
        b = buf_create(n);
        if (IS_ERR(b))
                return PTR_ERR(b);                   /* pass -EINVAL / -ENOMEM upward */

Interrupt handler-এ GFP_KERNEL লিখলে সাধারণত কিছুই হয় না — মেমরি যথেষ্ট থাকলে allocator ঘুমায় না — তাই বাগটি পরীক্ষায় লুকিয়ে থাকে, আর একদিন মেমরির চাপে যন্ত্র আটকে যায়। Debug kernel (CONFIG_DEBUG_ATOMIC_SLEEP) আগেভাগেই log-এ লেখে BUG: sleeping function called from invalid context.

printk আর dmesg — kernel-এর ডায়েরি

printk() লেখে kernel-এর একটি ring buffer-এ, প্রতিটি লাইনে একটি গুরুত্ব-স্তর: ০ (KERN_EMERG) থেকে ৭ (KERN_DEBUG); সহজ রূপ pr_err(), pr_info(), driver-এ dev_info(). পড়া হয় dmesg বা journalctl -k দিয়ে — অনেক distro-তে শুধু root (kernel.dmesg_restrict = 1).

Kernel-এর তালা — এক নজরে মনে করিয়ে দেওয়া

Kernel-এ একসাথে অনেক CPU আর interrupt, তাই synchronization সর্বত্র। এগুলো মডিউল ৪-এ বিস্তারিত দেখেছেন; এখানে শুধু কোনটি কোন context-এ চলে:

এই তালাগুলো ভুল ক্রমে নেওয়া হচ্ছে কি না, debug kernel-এ lockdep প্রতিটি lock-এর ক্রম মনে রেখে আগেভাগে সতর্ক করে (পর্ব ২৭)।

৪ · Kernel-এর ডেটা-কাঠামো — task_struct, list_head আর container_of

Kernel-এর প্রতিটি task-এর জন্য একটি task_struct (include/linux/sched.h) — পর্ব ৮-এর PCB-র আসল রূপ। কয়েক কিলোবাইটের এই struct-এ আগের পর্বগুলোর প্রায় সবকিছুর সূত্র: __state (চলছে, ঘুমাচ্ছে), pid আর tgid, mm (address space, পর্ব ৩৮), files (খোলা fd-এর টেবিল, পর্ব ৪১), signal আর sighand (পর্ব ১৩), cred (UID, capability — পর্ব ৪৭), nsproxy (namespace, পর্ব ৫১), se (scheduler-এর হিসাব, পর্ব ২১)। আর আছে children আর sibling — বাবা-সন্তানের গাছ সাজানোর তালিকা।

সেই তালিকাগুলো কেমন? আপনি C বা DSA কোর্সে linked list শিখেছেন এভাবে: প্রতিটি node-এ ডেটা আর next pointer. Kernel উল্টো পথে যায়। struct list_head-এ শুধু দুটি pointer — next আর prev, কোনো ডেটা নেই। আর এই ছোট node-টি বসানো হয় আসল বস্তুর ভেতরে, একটি member হিসেবে। একে বলে intrusive list.

তালিকায় হাঁটার সময় হাতে থাকে শুধু list_head *, অথচ দরকার পুরো বস্তু। Compiler জানে member-টি struct-এর শুরু থেকে কত বাইট দূরে (offsetof); member-এর ঠিকানা থেকে সেটি বিয়োগ করলেই বস্তুর শুরু। Kernel-এর include/linux/container_of.h-এ এর সংজ্ঞা (সরলীকৃত; আসলটিতে একটি compile-time type পরীক্ষাও আছে):

#define container_of(ptr, type, member) ({                      \
        void *__mptr = (void *)(ptr);                           \
        static_assert(__same_type(*(ptr), ((type *)0)->member)  \
                      || __same_type(*(ptr), void),             \
                      "pointer type mismatch in container_of()"); \
        ((type *)(__mptr - offsetof(type, member))); })

এবার একই ধারণা user space-এ নিজে বানিয়ে চালিয়ে দেখি। নিচের প্রোগ্রামে kernel-এর list_head, list_add_tail, list_del, container_of আর list_for_each_entry-এর ছোট নকল; তিনটি task একটি “run queue”-তে ঢোকে, মাঝেরটি বেরিয়ে যায়, তারপর তালিকায় হাঁটা:

#include <stdio.h>
#include <stddef.h>
/* user-space copy of the kernel idea: the list node lives INSIDE the object */
struct list_head { struct list_head *next, *prev; };
#define container_of(ptr, type, member) \
    ((type *)((char *)(ptr) - offsetof(type, member)))
#define list_for_each_entry(pos, head, member)                           \
    for (pos = container_of((head)->next, __typeof__(*pos), member);     \
         &pos->member != (head);                                         \
         pos = container_of(pos->member.next, __typeof__(*pos), member))
static void list_add_tail(struct list_head *n, struct list_head *head) {
    n->prev = head->prev;  n->next = head;
    head->prev->next = n;  head->prev = n;
}
static void list_del(struct list_head *e) { e->prev->next = e->next; e->next->prev = e->prev; }
struct task { int pid; char comm[12]; int nice; struct list_head run; };

int main(void) {
    struct list_head rq = { &rq, &rq };          /* empty list: points to itself */
    struct task t[3] = { { .pid = 101, .comm = "bash" },
                         { .pid = 102, .comm = "nginx", .nice = -5 },
                         { .pid = 103, .comm = "backup", .nice = 10 } };
    printf("offsetof(struct task, run) = %zu, sizeof(struct task) = %zu\n",
           offsetof(struct task, run), sizeof(struct task));
    for (int i = 0; i < 3; i++) list_add_tail(&t[i].run, &rq);
    list_del(&t[1].run);                          /* nginx leaves the run queue */
    struct task *p;
    list_for_each_entry(p, &rq, run)
        printf("pid=%d comm=%-6s nice=%3d  (node is %td bytes into the task)\n",
               p->pid, p->comm, p->nice, (char *)&p->run - (char *)p);
    struct task *last = container_of(rq.prev, struct task, run);
    printf("rq.prev -> %s; container_of gives &t[2]? %s\n",
           last->comm, last == &t[2] ? "yes" : "no");
    return 0;
}

offsetof(struct task, run) = 24, sizeof(struct task) = 40
pid=101 comm=bash   nice=  0  (node is 24 bytes into the task)
pid=103 comm=backup nice= 10  (node is 24 bytes into the task)
rq.prev -> backup; container_of gives &t[2]? yes

ভেতরের হিসাবটি এবার ঠিকানা ধরে দেখুন। ধরা যাক t array শুরু হয়েছে 0x7ffd1000-এ (উদাহরণ ঠিকানা; আসল রানে অন্য হবে), প্রতিটি task ৪০ = 0x28 বাইট:

লাভ তিনটি: যোগ করতে আলাদা node-এর মেমরি লাগে না (atomic context-এ বড় সুবিধা); একটি বস্তু কয়েকটি list_head দিয়ে একসাথে কয়েকটি তালিকায় থাকতে পারে; আর একই list_add/list_del সব ধরনের বস্তুতে চলে (বিস্তারিত ভাবনার প্রশ্ন ৩-এ)।

আরও তিনটি কাঠামো — যেখানে তালিকা যথেষ্ট নয়

• Red-black tree (lib/rbtree.c, struct rb_node — এটিও intrusive, বস্তুর ভেতরে বসে): সাজানো ক্রমে খোঁজা, যোগ, মোছা O(log n). CFS/EEVDF-এর task-গুলো এতে সাজানো (পর্ব ২১), আর epoll, high-resolution timer-সহ অনেক জায়গায় ব্যবহার হয়। গাছের নিয়ম আর ঘোরানো DSA কোর্সে দেখতে পারেন।
• XArray (Linux ৪.২০, ২০১৮; Matthew Wilcox): একটি সংখ্যা (index) থেকে pointer-এর বিশাল, ফাঁকা-ফাঁকা “array”, ভেতরে একটি radix tree, RCU দিয়ে lock ছাড়াই পড়া যায়। একটি ফাইলের page cache — “ফাইলের ৫ নম্বর page কোন frame-এ?” — এতেই রাখা (address_space->i_pages).
• Maple tree (Linux ৬.১, ২০২২): পরিসর (range) রাখার জন্য B-tree-ধাঁচের গাছ। একটি প্রসেসের VMA-গুলো (পর্ব ৩৮-এর /proc/self/maps-এর লাইন) আগে red-black tree-তে ছিল, এখন এতে।

৫ · একটি পূর্ণাঙ্গ module লেখা — Kbuild, parameter, export আর taint

পর্ব ৬-এ সবচেয়ে ছোট “hello” module আর insmod-এর ভেতরের ধাপ দেখেছেন। এবার একটি বাস্তবসম্মত module, যাতে প্রায় প্রতিটি আসল driver-এ থাকা তিনটি জিনিস আছে: বাইরে থেকে দেওয়া parameter, অন্য module-এর জন্য export করা symbol, আর ভুল input-এ ঋণাত্মক errno ফেরত।

#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt     /* every pr_info() starts with "greet: " */
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/init.h>

static char *who = "world";
module_param(who, charp, 0444);                 /* read-only in /sys */
MODULE_PARM_DESC(who, "Name to greet");

static int times = 1;
module_param(times, int, 0644);                 /* root may change it later */
MODULE_PARM_DESC(times, "How many greetings (1-10)");

int greet_count;                                /* other modules may read this */
EXPORT_SYMBOL_GPL(greet_count);                 /* ...if they are GPL-compatible */

static int __init greet_init(void)
{
        int i;

        if (times < 1 || times > 10)
                return -EINVAL;                 /* loading fails, nothing stays */
        for (i = 1; i <= times; i++)
                pr_info("hello, %s (%d of %d)\n", who, i, times);
        greet_count = times;
        return 0;
}

static void __exit greet_exit(void)
{
        pr_info("goodbye, %s\n", who);
}

module_init(greet_init);
module_exit(greet_exit);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Greeting module with parameters");

এটি সাধারণ gcc greet.c দিয়ে compile হয় না — চলমান kernel-এর ঠিক একই config আর header দিয়ে বানাতে হয়। কাজটি করে kernel-এর নিজের build-ব্যবস্থা Kbuild. আপনার ফোল্ডারে শুধু দুই লাইনের একটি Makefile (রেসিপির লাইনগুলোর শুরুতে Tab):

obj-m := greet.o                        # build greet.ko as a module
KDIR  ?= /lib/modules/$(shell uname -r)/build

all:
	$(MAKE) -C $(KDIR) M=$(CURDIR) modules
clean:
	$(MAKE) -C $(KDIR) M=$(CURDIR) clean

-C $(KDIR) মানে “kernel-এর build ফোল্ডারে গিয়ে তার Makefile চালানো”, আর M= বলে বাইরের module-টি কোথায়। Debian/Ubuntu-তে এর জন্য linux-headers-$(uname -r) প্যাকেজ লাগে। এবার একটি পরীক্ষামূলক VM-এ পুরো যাত্রা — নিচের আউটপুট একটি Ubuntu VM-এর উদাহরণ (এই পাতার রানার container, সেখানে module লোড করা যায় না; সময়ের ছাপ, version আর hash আপনার যন্ত্রে ভিন্ন হবে):

$ make
make -C /lib/modules/6.8.0-45-generic/build M=/home/rahim/greet modules
  CC [M]  /home/rahim/greet/greet.o
  MODPOST /home/rahim/greet/Module.symvers
  CC [M]  /home/rahim/greet/greet.mod.o
  LD [M]  /home/rahim/greet/greet.ko

$ modinfo greet.ko
filename:       /home/rahim/greet/greet.ko
description:    Greeting module with parameters
license:        GPL
depends:
name:           greet
vermagic:       6.8.0-45-generic SMP preempt mod_unload modversions
parm:           who:Name to greet (charp)
parm:           times:How many greetings (1-10) (int)

$ sudo insmod greet.ko times=20
insmod: ERROR: could not insert module greet.ko: Invalid argument

$ sudo insmod greet.ko who=Rajshahi times=2
$ sudo dmesg | tail -4
[ 912.402113] greet: loading out-of-tree module taints kernel.
[ 912.402170] greet: module verification failed: signature and/or required key missing - tainting kernel
[ 912.402689] greet: hello, Rajshahi (1 of 2)
[ 912.402692] greet: hello, Rajshahi (2 of 2)

$ cat /sys/module/greet/parameters/who /sys/module/greet/parameters/times
Rajshahi
2
$ cat /proc/sys/kernel/tainted
12288
$ sudo rmmod greet && sudo dmesg | tail -1
[ 975.118204] greet: goodbye, Rajshahi

• times=20: greet_init -EINVAL ফেরত দিল, kernel module-টি সরিয়ে দিল, আর insmod সেটিই “Invalid argument” হিসেবে দেখাল — ঋণাত্মক errno user space পর্যন্ত পৌঁছেছে।
• Parameter: insmod-এ নাম=মান; স্থায়ীভাবে /etc/modprobe.d/*.conf-এ options greet times=3; built-in হলে kernel command line-এ greet.times=3. module_param-এর শেষ সংখ্যাটি /sys-এর ফাইলের অনুমতি — ০৬৪৪ দিলে root চলমান অবস্থায় মান বদলাতে পারেন।
• EXPORT_SYMBOL_GPL: module-এর global symbol export না করলে অন্য module দেখতে পায় না; _GPL রূপটি শুধু GPL-সামঞ্জস্যপূর্ণ module-কে দেয় (ভাবনার প্রশ্ন ৪)।

Taint — kernel-এর গায়ে লাগা দাগ

উপরের 12288 সংখ্যাটি একটি bitmask. Kernel একবার “অস্বাভাবিক” কিছু দেখলে একটি bit জ্বালায়, আর রিবুট ছাড়া তা আর নেভে না। উদ্দেশ্য শাস্তি নয়, bug report বিচার করা: একটি crash report-এ Tainted: P OE দেখলে kernel ডেভেলপাররা জানেন, এমন module ছিল যার source তাঁরা দেখতে পারবেন না। Oops-এর বার্তায় এই অক্ষরগুলো ছাপা হয়। প্রধান bit-গুলো (Documentation/admin-guide/tainted-kernels.rst):

তাহলে ১২২৮৮ = ৮১৯২ + ৪০৯৬ = E + O: আমাদের greet বাইরে বানানো আর স্বাক্ষরবিহীন। Secure Boot চালু থাকলে অনেক distro-র kernel স্বাক্ষর বাধ্যতামূলক করে (পর্ব ৪৯-এর lockdown), তখন insmod সরাসরি “Key was rejected by service” বলে ব্যর্থ হয়। সমাধান Secure Boot বন্ধ করা নয়; নিজের চাবি বানিয়ে MOK-এ নথিভুক্ত করে module-এ স্বাক্ষর করা — DKMS-এর মতো ব্যবস্থা এটি স্বয়ংক্রিয়ভাবে করে।

৬ · চলমান kernel-এর জানালা — /proc, /sys, sysctl আর kernel config

Kernel-এর ভেতরের অবস্থা দেখার আর কিছু সেটিং বদলানোর জন্য দুটি কাল্পনিক file system আছে, যাদের ফাইল ডিস্কে নেই — পড়ার মুহূর্তে kernel লেখা তৈরি করে। /proc পুরোনো, কিছুটা এলোমেলো: প্রসেসের তথ্য (/proc/<pid>/, পর্ব ১১) আর সিস্টেমের নানা ফাইল একসাথে। তার ভেতরের /proc/sys/ হলো sysctl-এর গাছ — kernel-এর বদলযোগ্য “knob”. /sys (২০০৩-এর দিকে, ২.৬ যুগে) নতুন আর নিয়মমাফিক: kernel-এর বস্তুগুলো (যন্ত্র, driver, module) একটি গাছে, আর প্রতিটি ফাইলে একটিই মান.

নিচের শুধু-পড়ার script-টি এই পাতার রানারের kernel-কে কয়েকটি প্রশ্ন করে। মনে রাখবেন, রানারটি একটি container (পর্ব ৫১) — তাই উত্তর আসে host কম্পিউটারের kernel থেকে:

echo "== which kernel am I talking to? =="
cut -c1-80 /proc/version
for k in osrelease pid_max threads-max tainted kptr_restrict perf_event_paranoid; do
  printf '%-20s %s\n' "$k" "$(cat /proc/sys/kernel/$k 2>/dev/null || echo '(unreadable)')"
done
echo "== /sys/kernel =="
ls /sys/kernel 2>/dev/null | tr '\n' ' '; echo
echo "BTF of the running kernel: $(stat -c %s /sys/kernel/btf/vmlinux 2>/dev/null || echo none) bytes"
echo "== first 3 lines of /proc/kallsyms =="
head -3 /proc/kallsyms 2>/dev/null || echo "(kallsyms unreadable)"
echo "symbols listed: $(wc -l < /proc/kallsyms 2>/dev/null || echo 0)"
echo "== knobs under /proc/sys (files per directory) =="
for d in /proc/sys/*/; do
  n=$(find "$d" -type f 2>/dev/null | wc -l)
  printf '%-8s %s\n' "$(basename "$d")" "$n"
done
all=$(find /proc/sys -type f 2>/dev/null | wc -l)
rd=$(find /proc/sys -type f -readable 2>/dev/null | wc -l)
echo "total: $all files, readable by me: $rd"

== which kernel am I talking to? ==
Linux version 6.8.0-137-generic (buildd@lcy02-amd64-064) (x86_64-linux-gnu-gcc-1
osrelease            6.8.0-137-generic
pid_max              4194304
threads-max          14727
tainted              0
kptr_restrict        1
perf_event_paranoid  4
== /sys/kernel ==
address_bits boot_params btf cgroup config cpu_byteorder crash_elfcorehdr_size debug fscaps iommu_groups irq kexec_crash_loaded kexec_crash_size kexec_loaded livepatch mm notes oops_count profiling rcu_expedited rcu_normal reboot security slab software_nodes tracing uevent_helper uevent_seqnum vmcoreinfo warn_count 
BTF of the running kernel: 6101218 bytes
== first 3 lines of /proc/kallsyms ==
0000000000000000 A fixed_percpu_data
0000000000000000 A __per_cpu_start
0000000000000000 A cpu_debug_store
symbols listed: 257494
== knobs under /proc/sys (files per directory) ==
abi      1
debug    2
dev      15
fs       43
kernel   148
net      668
user     12
vm       51
total: 940 files, readable by me: 921

নিজের যন্ত্রে /proc/sys/kernel/pid_max আর sysctl kernel.pid_max একই জিনিস — নামের বিন্দু path-এর /. বদলাতে sudo sysctl -w kernel.pid_max=…; স্থায়ী করতে /etc/sysctl.d/-এ একটি .conf ফাইল। macOS-এও BSD-র sysctl আছে (sysctl kern.ostype), নামগুলো আলাদা; Windows-এ এমন সেটিং থাকে registry-তে (পর্ব ৫৬), আর চলমান অবস্থা দেখা হয় performance counter বা ETW দিয়ে।

Kconfig আর .config — কোন kernel বানানো হবে

Kernel-এর প্রায় প্রতিটি বৈশিষ্ট্য একটি config symbol, যার সংজ্ঞা প্রতিটি ফোল্ডারের Kconfig ফাইলে: নাম, ধরন, নির্ভরতা আর সাহায্য-বার্তা। এমন symbol হাজার হাজার (সংস্করণভেদে দশ হাজারেরও বেশি)। Driver-এর মতো বেশিরভাগের তিনটি মান হতে পারে: y (kernel-এর ভেতরে স্থায়ী), m (module হিসেবে আলাদা .ko), n (বাদ)। সব উত্তর জমা থাকে একটি টেক্সট ফাইলে, .config:

CONFIG_BPF_SYSCALL=y          # eBPF available
CONFIG_BPF_JIT=y
CONFIG_DEBUG_INFO_BTF=y       # produces /sys/kernel/btf/vmlinux
CONFIG_EXT4_FS=y              # built in: root file system needs it at boot
CONFIG_BTRFS_FS=m             # module: loaded only if used
# CONFIG_DEBUG_ATOMIC_SLEEP is not set

আপনার চলমান kernel কোন config-এ বানানো, তা সাধারণত /boot/config-$(uname -r)-এ থাকে (kernel-এ CONFIG_IKCONFIG_PROC থাকলে /proc/config.gz-এও)। নিজে একটি kernel বানানোর ধাপ — শুধু একটি পরীক্ষামূলক VM-এ, পুরোনো kernel বুট মেনুতে রেখে:

git clone --depth 1 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
cd linux
cp /boot/config-$(uname -r) .config   # start from your distro's choices
make olddefconfig                     # new options get their default answer
make localmodconfig                   # optional: keep only modules loaded right now
make menuconfig                       # optional: a text menu to browse/change options
make -j"$(nproc)"                     # vmlinux, the compressed image, all modules
sudo make modules_install             # copies .ko files to /lib/modules/<version>/
sudo make install                     # copies the kernel to /boot, updates the bootloader

সময় লাগে যন্ত্রভেদে কয়েক মিনিট থেকে এক ঘণ্টার বেশি; localmodconfig অপ্রয়োজনীয় driver বাদ দিয়ে তা অনেক কমায়। আর নিজের বানানো kernel-এর নিরাপত্তা-হালনাগাদের দায়িত্ব আপনার নিজের।

৭ · BPF-এর জন্মকথা — প্যাকেট ছাঁকার ছোট যন্ত্র থেকে verifier

১৯৯০-এর দশকের শুরুতে নেটওয়ার্ক বিশ্লেষণের একটি বড় সমস্যা ছিল: tcpdump-এর মতো টুল প্রতিটি প্যাকেট kernel থেকে user space-এ কপি করত, আর তারপর বেশিরভাগই ফেলে দিত — কারণ আপনি হয়তো শুধু port ২২-এর প্যাকেট দেখতে চান। Lawrence Berkeley Laboratory-র Steven McCanne আর Van Jacobson ১৯৯২ সালে একটি সমাধান বানান, যা ১৯৯৩ সালের USENIX সম্মেলনে প্রকাশিত হয়: BSD Packet Filter — BPF. ধারণাটি: ছাঁকনির নিয়ম user space থেকে একটি ছোট “প্রোগ্রাম” হিসেবে kernel-এ পাঠানো, আর kernel প্রতিটি প্যাকেটে সেটি চালিয়ে শুধু দরকারিগুলো ওপরে পাঠাবে।

Classic BPF একটি ক্ষুদ্র কাল্পনিক যন্ত্র: একটি accumulator register A, একটি index register X, ছোট একটি scratch মেমরি, আর কয়েক ধরনের নির্দেশ — প্যাকেটের নির্দিষ্ট জায়গা থেকে load, তুলনা, শুধু সামনের দিকে jump, আর return (কত বাইট রাখব; ০ = ফেলে দেওয়া)। পেছনে jump নেই, তাই লুপ নেই, তাই প্রোগ্রাম সবসময় শেষ হয়। tcpdump -d আপনার লেখা ছাঁকনি-নিয়মটির BPF রূপ দেখায় — নিচে একটি Ethernet যন্ত্রে উদাহরণ আউটপুট (রানারে tcpdump নেই):

$ sudo tcpdump -d ip
(000) ldh      [12]                       # load 2 bytes at offset 12: the EtherType
(001) jeq      #0x800      jt 2  jf 3      # IPv4?
(002) ret      #262144                    # yes: keep the packet
(003) ret      #0                         # no: drop it

Linux এই ধারণা ১৯৯০-এর দশকের শেষে socket-এর ছাঁকনি হিসেবে নেয় (Linux Socket Filter), আর আজও যেকোনো প্রোগ্রাম SO_ATTACH_FILTER দিয়ে নিজের socket-এ classic BPF বসাতে পারে — কোনো বিশেষ অনুমতি ছাড়াই, কারণ ছাঁকনি শুধু নিজের প্যাকেট কমাতে পারে। এই পাতার রানারেই চলুক: একটি UDP socket-এ ৪ নির্দেশের ছাঁকনি, যা শুধু ‘A’ দিয়ে শুরু হওয়া বার্তা রাখে, তারপর loopback-এ চারটি বার্তা পাঠানো:

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#include <linux/filter.h>

int main(void) {
    struct sock_filter prog[] = {                  /* classic BPF: 4 instructions */
        BPF_STMT(BPF_LD | BPF_B | BPF_ABS, 8),           /* A = byte 8 = first payload byte */
        BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, 'A', 0, 1),  /* A == 'A' ? next : skip 1 */
        BPF_STMT(BPF_RET | BPF_K, 0xFFFF),               /* keep (up to 65535 bytes) */
        BPF_STMT(BPF_RET | BPF_K, 0),                    /* drop */
    };
    struct sock_fprog fp = { .len = 4, .filter = prog };
    struct sockaddr_in a = { .sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK) };
    int rx = socket(AF_INET, SOCK_DGRAM, 0), tx = socket(AF_INET, SOCK_DGRAM, 0);
    socklen_t len = sizeof a;
    if (bind(rx, (struct sockaddr *)&a, sizeof a) != 0) { perror("bind"); return 1; }
    getsockname(rx, (struct sockaddr *)&a, &len);          /* learn the port */
    if (setsockopt(rx, SOL_SOCKET, SO_ATTACH_FILTER, &fp, sizeof fp) != 0) {
        perror("SO_ATTACH_FILTER"); return 1;
    }
    printf("filter attached: %u instructions\n", fp.len);
    const char *msgs[] = { "A-order#1", "B-spam", "A-order#2", "C-ping" };
    for (int i = 0; i < 4; i++)
        sendto(tx, msgs[i], strlen(msgs[i]), 0, (struct sockaddr *)&a, sizeof a);
    char buf[64]; ssize_t n; int got = 0;
    while ((n = recv(rx, buf, sizeof buf - 1, MSG_DONTWAIT)) > 0) {
        buf[n] = '\0'; printf("received: %s\n", buf); got++;
    }
    printf("sent 4, received %d (kernel ran the filter on each packet)\n", got);
    return 0;
}

filter attached: 4 instructions
received: A-order#1
received: A-order#2
sent 4, received 2 (kernel ran the filter on each packet)

Verifier কেন — একটি খেলনা BPF যন্ত্র

Kernel বাইরের একটি প্রোগ্রাম নিজের ভেতরে চালাবে — এটি ভয়ের কথা। তাই প্রোগ্রাম গ্রহণের আগে একবার kernel তাকে যাচাই করে: প্রতিটি jump প্রোগ্রামের ভেতরে পড়ে কি না, পেছনের দিকে কোনো jump (সম্ভাব্য অনন্ত লুপ) আছে কি না, শেষ নির্দেশটি return কি না। নিচের JavaScript-এ একটি খেলনা যন্ত্র আর খেলনা verifier: একটি ছাঁকনি, যা শুধু TCP port ২২ (SSH) রাখে, কয়েকটি নমুনা প্যাকেটে চলে; তারপর একটি লুপ-ওয়ালা প্রোগ্রাম verifier-এর কাছে যায়:

// Toy classic-BPF machine, one register A. Toy packet: [protocol (6 TCP, 17 UDP), port hi, port lo]
function verify(prog) {                 // runs ONCE, before the program is accepted
  for (let pc = 0; pc < prog.length; pc++) {
    const i = prog[pc];
    if (i.op === "jeq" || i.op === "ja") {
      for (const off of i.op === "ja" ? [i.k] : [i.jt, i.jf]) {
        if (off < 0) return "REJECT: insn " + pc + " jumps backwards (possible loop)";
        if (pc + 1 + off >= prog.length) return "REJECT: insn " + pc + " jumps past the end";
      }
    }
  }
  return prog[prog.length - 1].op === "ret" ? "OK" : "REJECT: last insn is not ret";
}
function run(prog, pkt) {
  let A = 0, pc = 0, steps = 0;
  for (;;) {
    const i = prog[pc++]; steps++;
    if (i.op === "ldb") { if (i.k >= pkt.length) return [0, steps]; A = pkt[i.k]; }
    else if (i.op === "ldh") { if (i.k + 1 >= pkt.length) return [0, steps]; A = pkt[i.k] * 256 + pkt[i.k + 1]; }
    else if (i.op === "jeq") pc += (A === i.k) ? i.jt : i.jf;
    else if (i.op === "ja") pc += i.k;
    else if (i.op === "ret") return [i.k, steps];
  }
}
const sshOnly = [ { op: "ldb", k: 0 }, { op: "jeq", k: 6, jt: 0, jf: 3 },
  { op: "ldh", k: 1 }, { op: "jeq", k: 22, jt: 0, jf: 1 },
  { op: "ret", k: 65535 }, { op: "ret", k: 0 } ];
console.log("verifier: " + verify(sshOnly));
const pkts = { "TCP:22": [6, 0, 22], "TCP:80": [6, 0, 80], "UDP:53": [17, 0, 53], "short": [6] };
for (const [name, p] of Object.entries(pkts)) {
  const [v, s] = run(sshOnly, p);
  console.log(name.padEnd(7) + " -> " + (v ? "ACCEPT" : "drop  ") + " after " + s + " insns");
}
const looping = [ { op: "ldb", k: 0 }, { op: "ja", k: -2 }, { op: "ret", k: 0 } ];
console.log("verifier: " + verify(looping));

verifier: OK
TCP:22  -> ACCEPT after 5 insns
TCP:80  -> drop   after 5 insns
UDP:53  -> drop   after 3 insns
short   -> drop   after 3 insns
verifier: REJECT: insn 1 jumps backwards (possible loop)

৮ · আধুনিক eBPF — verifier, map, JIT আর kernel-এর প্রায় সব hook

২০১৪ সালে Alexei Starovoitov-এর কাজ থেকে (পরে Daniel Borkmann-সহ অনেকের অবদানে) classic BPF-এর একটি বড় সম্প্রসারণ Linux-এ আসে: eBPF (“extended”). Linux ৩.১৮-এ নতুন bpf() system call আসে, আর তারপর প্রায় প্রতিটি release-এ নতুন ক্ষমতা। আজ “BPF” বললে সাধারণত eBPF-ই বোঝানো হয়, আর classic রূপটিকে kernel ভেতরে ভেতরে eBPF-এ অনুবাদ করে চালায়। কী বদলাল:

• বড় যন্ত্র: ১১টি ৬৪-বিট register (r0 ফল, r1–r5 argument, r10 stack-এর frame pointer), ৫১২ বাইটের stack — আধুনিক CPU-র কাছাকাছি, তাই JIT-এ প্রায় এক-এক অনুবাদ।
• Helper ফাংশন: প্রোগ্রাম kernel-এর যেকোনো ফাংশন ডাকতে পারে না, শুধু অনুমোদিত তালিকা — যেমন bpf_get_current_pid_tgid(), bpf_ktime_get_ns(), bpf_map_lookup_elem().
• Map: kernel-এ থাকা key-value ভাণ্ডার — hash, array, per-CPU রূপ, ring buffer. eBPF প্রোগ্রাম সেখানে লেখে, user space-এর প্রোগ্রাম bpf() syscall দিয়ে পড়ে; একাধিক প্রোগ্রাম একই map ভাগ করতে পারে।
• শক্তিশালী verifier: প্রতিটি সম্ভাব্য পথে প্রতিটি register-এর ধরন (সংখ্যা, map-এর মান, প্যাকেটের pointer…) আর সম্ভাব্য পরিসর হিসাব রাখে। Map lookup-এর ফল NULL হতে পারে — পরীক্ষা না করে ব্যবহার করলে প্রত্যাখ্যান। Linux ৫.৩ (২০১৯) থেকে সীমাবদ্ধ লুপ চলে, যদি verifier প্রমাণ করতে পারে লুপটি শেষ হবে।
• JIT: যাচাই-পাস bytecode CPU-র আসল machine code-এ অনুবাদ হয় (x86-64, arm64, riscv…), তাই গতি প্রায় kernel-এর নিজের কোডের মতো। নিরাপত্তার কারণে অনেক distro-র kernel-এ JIT সবসময় চালু থাকে আর interpreter বাদ দেওয়া হয়।
• BTF আর CO-RE: task_struct-এর কোন member কত বাইট দূরে, তা kernel-ভেদে বদলায় — অংশ ৪-এর offsetof-এর সমস্যা! BTF হলো kernel-এর সব type-এর সংক্ষিপ্ত বর্ণনা (রানারে দেখা /sys/kernel/btf/vmlinux); লোডের সময় libbpf তা দেখে offset ঠিক করে দেয় — “Compile Once – Run Everywhere”.

একটি eBPF প্রোগ্রামের পুরো যাত্রা ধাপে ধাপে দেখুন। উদাহরণ: প্রতিটি প্রসেস কতবার system call করছে, গোনা।

bpftrace, bcc আর bpftool — হাতে-কলমে

তৈরি টুল দিয়েই অনেক কাজ হয়: bpftrace — awk আর DTrace-এর ধাঁচের এক-লাইনের ভাষা; bcc — তৈরি টুলের সংগ্রহ; bpftool — লোড-করা প্রোগ্রাম আর map দেখায়। সবগুলোতে root লাগে, রানারে এগুলো নেই — নিচে একটি Ubuntu সার্ভারের উদাহরণ আউটপুট:

# which processes make the most system calls? (Ctrl+C after a few seconds)
$ sudo bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'
Attaching 1 probe...
^C

@[systemd-journal]: 57
@[sshd]: 318
@[bash]: 702
@[node]: 9431

# every new program that starts, with its parent (bcc tool; Ubuntu adds -bpfcc)
$ sudo execsnoop-bpfcc
PCOMM            PID     PPID    RET ARGS
cron             24187   1103      0 /bin/sh -c /usr/local/bin/backup.sh
backup.sh        24188   24187     0 /usr/bin/tar -czf /backup/db.tgz /var/lib/db

# what BPF programs are loaded right now?
$ sudo bpftool prog show
47: tracepoint  name sys_enter  tag 6a2b1c0d9e8f7a65  gpl
        loaded_at 2026-10-26T10:12:03+0600  uid 0
        xlated 240B  jited 151B  memlock 4096B  map_ids 12

bpftrace ফল ছোট থেকে বড় ক্রমে ছাপে, তাই সবচেয়ে ব্যস্ত node শেষে। কোনো প্রোগ্রাম না বদলে পুরো সিস্টেমের ছবি — আর পর্ব ৫-এর strace-এর তুলনায় খরচ সাধারণত অনেক কম। xlated আর jited হলো bytecode আর JIT-এর পরের machine code-এর আকার। পূর্ণ ব্যবহার পর্ব ৫৭-এ।

বাস্তবে কোথায় — নেটওয়ার্ক, observability, নিরাপত্তা

• নেটওয়ার্ক: Cilium Kubernetes-এর নেটওয়ার্কিং আর নেটওয়ার্ক-নীতি eBPF দিয়ে করে (CNCF-এর “graduated” প্রকল্প, ২০২৩); XDP দিয়ে DDoS-প্যাকেট driver-এর স্তরেই ফেলা হয়।
• Observability আর নিরাপত্তা: Falco, Tetragon-এর মতো টুল প্রসেস চালু, ফাইল খোলা, নেটওয়ার্ক-সংযোগের ঘটনা দেখে সন্দেহজনক আচরণে সতর্ক করে।
• অন্য OS-এ: Microsoft-এর খোলা প্রকল্প eBPF for Windows সীমিত পরিসরে একই ধারণা আনছে; macOS-এ eBPF নেই, সেখানে ঐতিহাসিকভাবে DTrace আর নিরাপত্তা-টুলের জন্য Endpoint Security কাঠামো।

৯ · Kernel কীভাবে তৈরি হয় — mailing list, merge window, stable আর Rust

বিশ্বের সবচেয়ে বড় সহযোগী সফটওয়্যার-প্রকল্পগুলোর একটি এখনো মূলত ইমেইলে চলে; প্রতিটি release-এ সাধারণত হাজারো ডেভেলপারের দশ হাজারের বেশি পরিবর্তন। কাজের ধাপ:

1. Patch লেখা আর পাঠানো: একটি পরিবর্তন = একটি patch, সাথে কেন বদলানো হলো তার বর্ণনা। scripts/checkpatch.pl রীতি যাচাই করে, scripts/get_maintainer.pl MAINTAINERS ফাইল দেখে বলে দেয় কোন maintainer আর mailing list-এ পাঠাতে হবে; তারপর git send-email (প্রায়ই LKML-এও)।
2. প্রকাশ্য পর্যালোচনা: যে কেউ উত্তর দিতে পারেন; maintainer সন্তুষ্ট হলে নিজের git tree-তে নেন। প্রতিটি patch-এ Signed-off-by: — লেখক Developer Certificate of Origin (DCO, ২০০৪) মেনে ঘোষণা দেন যে কোডটি জমা দেওয়ার অধিকার তাঁর আছে। আরও চিহ্ন: Reviewed-by:, Tested-by:, আর কোন commit-এর বাগ সারানো হলো বোঝাতে Fixes:.
3. একসাথে পরীক্ষা: শত শত subsystem tree প্রতিদিন linux-next-এ জোড়া হয়, আর স্বয়ংক্রিয় build ও test-ব্যবস্থা সংঘাত আগেই ধরে।
4. Linus-এর tree: merge window-এ Linus Torvalds maintainer-দের “pull request” নিয়ে নতুন বৈশিষ্ট্য mainline-এ জোড়েন। তারপর শুধু বাগ-সংশোধন।

এই ছন্দে একটি release-এর জীবন নিচে — দিনের হিসাব সাধারণ নিয়মে (কোনো কোনো release-এ rc8 লাগে, বা ছুটির কারণে merge window একটু লম্বা হয়):

সংস্করণ নম্বর আর uname -r

Linux 1.0 আসে ১৯৯৪ সালে। পুরোনো যুগে জোড়-বিজোড় নিয়ম ছিল (২.৪ স্থিতিশীল, ২.৫ উন্নয়ন), যা ২.৬-এ (২০০৩) উঠে যায়। তারপর ৩.০ (২০১১), ৪.০ (২০১৫), ৫.০ (২০১৯), ৬.০ (২০২২) — প্রথম সংখ্যার বদল কোনো বড় পরিবর্তনের চিহ্ন নয়; দ্বিতীয় সংখ্যাটি খুব বড় হয়ে গেলে Linus প্রথমটি বাড়ান। তাই 6.12-এর পরে 6.13 — দশমিক সংখ্যা নয়, দুটি আলাদা পূর্ণসংখ্যা। পড়ার নিয়ম:

• 6.12 — mainline release; 6.12-rc3 — তার আগের তৃতীয় release candidate; 6.12.57 — সেই release-এর ৫৭তম stable সংশোধন।
• Distro-র kernel নিজের নম্বর জোড়ে। রানারের 6.8.0-137-generic: upstream 6.8-এর ওপর Ubuntu-র kernel, 137 Ubuntu-র নিজের সংশোধন/ABI নম্বর, generic সাধারণ ধরন। ভেতরে অনেক সংশোধন যোগ হয়েছে, তাই নিরাপত্তার অবস্থা জানতে distro-র নিজের তালিকা দেখুন।

Rust for Linux

Kernel-এর নিরাপত্তা-ত্রুটির বড় অংশ মেমরি-ভুল থেকে: buffer-এর বাইরে লেখা, মুক্ত মেমরি ব্যবহার। Rust for Linux প্রকল্পের প্রাথমিক কাঠামো Linux ৬.১-এ (ডিসেম্বর ২০২২) mainline-এ ঢোকে — C ছাড়া দ্বিতীয় কোনো ভাষা প্রথমবার। লক্ষ্য পুরো kernel নতুন করে লেখা নয়; নতুন driver Rust-এ লেখা, যেখানে compiler-ই অনেক মেমরি-ভুল আটকায়। পরে ছোট কিছু Rust driver এসেছে (প্রথমগুলোর একটি ৬.৮-এ একটি network PHY driver বলে জানা যায়), আর বড় driver-এর কাজ চলছে। C আর Rust-এর সংযোগস্থলের দায়িত্ব নিয়ে প্রকাশ্য বিতর্কও হয়েছে (ভাবনার প্রশ্ন ৩)।

১০ · AI-এর যুগে kernel-এর কাজ — দ্রুত কোড, কঠোর যাচাই

Module, eBPF প্রোগ্রাম বা sysctl-এর খসড়া AI দ্রুত দেয়, কিন্তু এখানে ভুলের দাম বেশি — ভুল kernel কোড পুরো যন্ত্র ফেলে। আর kernel-এর ভেতরের API স্থিতিশীল নয় (ভাবনার প্রশ্ন ১), তাই পুরোনো লেখায় শেখা AI প্রায়ই এমন ফাংশন দেয় যা আর নেই।

AI-এর kernel-পরামর্শ প্রয়োগের আগে — চেকলিস্ট

• নিজের uname -r, distro আর architecture AI-কে জানিয়েছি, আর উত্তরের প্রতিটি API সেই version-এর source-এ (elixir.bootlin.com বা নিজের header) খুঁজে পেয়েছি
• কোডটি W=1 দিয়ে warning ছাড়া build হয়েছে, আর scripts/checkpatch.pl চালিয়েছি
• প্রতিটি ফাংশনের context (ঘুমাতে পারে কি না) নিজে চিহ্নিত করেছি, আর debug kernel-এ (lockdep, KASAN, DEBUG_ATOMIC_SLEEP) পরীক্ষা করেছি
• শুধু snapshot-সহ একটি VM-এ (যেমন QEMU) লোড করেছি; কাজের যন্ত্রে নয়
• Secure Boot বন্ধ, insmod -f, স্থায়ী kptr_restrict=0 বা অপ্রয়োজনীয় sudo/chmod 777 নেই
• লোড-খোলা অনেকবার করে দেখেছি — dmesg-এ warning নেই, /proc/sys/kernel/tainted শুধু প্রত্যাশিত bit দেখায়, আর rmmod-এর পর কিছু পড়ে থাকে না