System call — user mode থেকে kernel mode

১ · দুই রকম মোড — user mode আর kernel mode

একটি ব্যাংকের শাখার কথা ভাবুন। গ্রাহকেরা হলে বসতে পারেন, ফর্ম পূরণ করতে পারেন, টোকেন নিতে পারেন। কিন্তু ভল্টে ঢুকে নিজের হাতে টাকা তুলে নেওয়া চলবে না। টাকা তুলতে হলে কাউন্টারে গিয়ে চেক দিতে হয়। কাউন্টারের কর্মকর্তা স্বাক্ষর মেলান, ব্যালান্স দেখেন, তারপর ভল্ট থেকে টাকা এনে দেন। গ্রাহক কখনো ভল্টের চাবি হাতে পান না।

কম্পিউটারও ঠিক এভাবে চলে। আপনার ব্রাউজার, গেম, Word বা নিজের লেখা C প্রোগ্রাম — এরা সবাই “গ্রাহক”। হার্ডওয়্যার (ডিস্ক, নেটওয়ার্ক কার্ড, মেমরির নিয়ন্ত্রণ, টাইমার) হলো “ভল্ট”। আর ভল্টের চাবি থাকে শুধু অপারেটিং সিস্টেমের মূল অংশ kernel-এর হাতে। এই ভাগাভাগি সফটওয়্যারের ভদ্রতা দিয়ে চলে না, চলে হার্ডওয়্যারের জোরে। CPU নিজেই দুই রকম মোডে চলতে পারে:

এই দুই মোডে ভাগ করে চালানোকে বলে dual-mode operation. পাঠ্যবইয়ের ভাষায় CPU-র ভেতরে একটি mode bit থাকে: 0 মানে kernel mode, 1 মানে user mode. বাস্তবের x86 CPU-তে এটি একটি বিট নয়, দুই বিটের একটি সংখ্যা — current privilege level (CPL), যার মান 0 থেকে 3. এই চারটি স্তরকে বলে protection ring. তবে Linux আর Windows কার্যত শুধু ring 0 (kernel) আর ring 3 (user) ব্যবহার করে।

Privileged instruction — শুধু kernel-এর জন্য

কিছু instruction এত ক্ষমতাশালী যে user প্রোগ্রামের হাতে দিলে সিস্টেম আর নিরাপদ থাকে না। এগুলোকে বলে privileged instruction. CPU এগুলো শুধু kernel mode-এ চালায়। কয়েকটি উদাহরণ (x86):

User mode-এ থাকা কোনো প্রোগ্রাম যদি এর একটি চালাতে চায়? CPU সেটি চালায় না। বরং একটি exception তোলে — x86-এ general protection fault (#GP) — আর নিয়ন্ত্রণ সঙ্গে সঙ্গে kernel-এর হাতে চলে যায়। Kernel দেখে, অপরাধী একটি সাধারণ প্রোগ্রাম। Linux তখন সেই প্রসেসকে SIGSEGV signal পাঠায়, সাধারণত প্রসেসটি বন্ধ হয়ে যায় (signal নিয়ে বিস্তারিত পর্ব ১৩-এ)। Windows-এ একই ঘটনায় প্রোগ্রাম STATUS_PRIVILEGED_INSTRUCTION exception পায়। কম্পিউটারের বাকি সবকিছু চলতে থাকে — ঠিক যেমন ভল্টে ঢুকতে চাওয়া গ্রাহককে দারোয়ান বের করে দিলেও ব্যাংকের কাজ থামে না।

নিচের ডায়াগ্রামে এক প্রোগ্রামের জীবনের কয়েকটি মুহূর্ত দেখুন। প্রতিটি ধাপে mode bit কীভাবে বদলায়, আর কে বদলায়, তা খেয়াল করুন। একটি বিষয় মনে রাখার মতো: user থেকে kernel-এ যাওয়া ঘটে শুধু তিনটি পথে — system call, interrupt আর exception. আর kernel থেকে user-এ ফেরে kernel নিজেই, একটি বিশেষ return instruction দিয়ে।

1boot: kernel sets up hardware2kernel starts a user program3user: add, mov, call ...4user: read(0, buf, 64) -> syscall5kernel: sys_read done, return6timer interrupt fires7kernel: timer handled, return8user: hlt   ; privileged!9CPU: #GP exception -> kernel10kernel: send SIGSEGV, end it

২ · System call কী, আর কেন লাগে

User mode এত সীমিত হলে প্রোগ্রাম কাজ করে কীভাবে? একটি “Hello” লিখতেও তো স্ক্রিন বা টার্মিনাল লাগে, যা হার্ডওয়্যার। ফাইল পড়তে ডিস্ক লাগে। উত্তর: প্রোগ্রাম kernel-কে অনুরোধ করে। সেই নির্দিষ্ট, নিয়ন্ত্রিত অনুরোধের নামই system call — kernel-এর দেওয়া একটি সেবা, যা প্রোগ্রাম একটি বিশেষ instruction দিয়ে ডাকে।

এই ব্যবস্থার তিনটি বড় লাভ:

• সুরক্ষা: Kernel প্রতিটি অনুরোধ যাচাই করে — এই ফাইল পড়ার অনুমতি আছে কি? এই মেমরির ঠিকানা কি সত্যিই এই প্রসেসের? ভুল হলে অনুরোধ ফিরিয়ে দেয়।
• সরলতা (abstraction): প্রোগ্রামকে জানতে হয় না ডিস্কটি SSD না হার্ডডিস্ক, বা টার্মিনালটি আসল স্ক্রিন না একটি pipe. সবার জন্য একই write().
• ভাগাভাগি: একটি ডিস্ক বা নেটওয়ার্ক কার্ড শত শত প্রোগ্রাম একসাথে ব্যবহার করে। Kernel মাঝখানে থেকে ক্রম ঠিক রাখে, যাতে একজনের লেখা আরেকজনের লেখায় মিশে না যায়।

প্রতিটি OS-এর system call-এর একটি নির্দিষ্ট তালিকা আছে। Linux-এ x86-64-এর জন্য এমন call কয়েকশো (৩৫০-এর বেশি), প্রতিটির একটি নম্বর — syscall number. যেমন x86-64 Linux-এ read = 0, write = 1, getpid = 39. তবে প্রোগ্রামাররা নম্বর মুখস্থ করেন না; তাঁরা ডাকেন C library-র ফাংশন, যেমন write() বা open(). Linux-এ এই library সাধারণত glibc (GNU C Library); Android-এ Bionic, ছোট container-এ প্রায়ই musl.

এখানে Linux আর Windows-এর একটি বড় পার্থক্য আছে। Linux-এ write()-এর wrapper প্রায় সরাসরি একটি system call করে। Windows-এ WriteFile() হলো Win32 API-র ফাংশন; এটি ভেতরে ntdll.dll-এর NtWriteFile ডাকে, আর আসল system call করে সেই ntdll. Microsoft Win32 API স্থির রাখে, কিন্তু system call-এর নম্বর Windows-এর সংস্করণভেদে বদলায় — তাই Windows-এ সরাসরি syscall নম্বর ব্যবহার করা অসমর্থিত। Linux উল্টো: kernel ডেভেলপাররা প্রতিশ্রুতি দেন যে একবার যোগ হওয়া syscall-এর নম্বর ও আচরণ বদলানো হবে না (“don't break userspace”). macOS-ও নিজের syscall ABI স্থির রাখার প্রতিশ্রুতি দেয় না; সেখানে প্রোগ্রাম libSystem দিয়ে যায়।

৩ · একটি system call-এর যাত্রাপথ

এবার সবচেয়ে গুরুত্বপূর্ণ অংশ। আপনার C প্রোগ্রামে একটি লাইন আছে: n = write(1, "hi\n", 3); — অর্থাৎ file descriptor 1 (সাধারণত stdout, মানে টার্মিনাল)-এ ৩ বাইট লেখার অনুরোধ। এই এক লাইনের পেছনে CPU-তে কী কী ঘটে, x86-64 Linux ধরে ধাপে ধাপে দেখি। ডান দিকে CPU-র register-এর মান খেয়াল করুন।

1// user program   (user mode)2n = write(1, "hi\n", 3);3// glibc: write() wrapper4mov  eax, 1        ; SYS_write5mov  edi, 1        ; arg1 fd6lea  rsi, [buf]    ; arg2 "hi\n"7mov  edx, 3        ; arg3 count8syscall            ; trap!9// kernel          (kernel mode)10entry_SYSCALL_64: save regs11sys_call_table[rax] -> write12fd 1 -> file -> tty driver13rax = 3; sysret14// glibc again    (user mode)15if -4095 <= rax <= -1: errno16return rax;   // n = 3

Trap instruction — CPU-ভেদে আলাদা নাম

“জানালা” প্রতিটি CPU-তে আছে, শুধু নাম আর নিয়ম আলাদা। পরীক্ষায় এবং বাস্তব debugging-এ এই টেবিলটি কাজে লাগে:

খেয়াল করুন: একই কাজের syscall নম্বর CPU-ভেদে আলাদা। write x86-64-এ 1, কিন্তু ARM64-এ 64. পুরোনো int 0x80 আসলে একটি software interrupt — interrupt টেবিলের ১২৮ নম্বর ঘর দিয়ে kernel-এ ঢোকা। এটি ধীর ছিল বলে পরে Intel sysenter আর AMD syscall নামে দ্রুত, বিশেষ instruction আনে। এজন্যই অনেক বইয়ে system call-কে “software interrupt” বলা হয় — ইতিহাসের দিক থেকে কথাটি ঠিক, তবে আধুনিক x86-64-এ এটি আলাদা instruction.

নিজের হাতে syscall নম্বর দিয়ে ডাকা

glibc একটি সাধারণ ফাংশন syscall() দেয়, যেখানে নম্বরটি আপনি নিজে বলে দেন। নিচের প্রোগ্রাম একই কাজ দুইভাবে করে — wrapper দিয়ে আর সরাসরি নম্বর দিয়ে — এবং ফল মেলায়:

#define _GNU_SOURCE
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/syscall.h>

int main(void) {
    pid_t via_wrapper = getpid();                 /* glibc wrapper */
    long  via_raw     = syscall(SYS_getpid);      /* number by hand */
    printf("SYS_getpid = %d, SYS_write = %d on this machine\n",
           SYS_getpid, SYS_write);
    printf("wrapper and raw syscall agree: %s\n",
           via_raw == via_wrapper ? "yes" : "no");
    fflush(stdout);

    const char *msg = "hello from syscall(SYS_write, ...)\n";
    long n1 = syscall(SYS_write, 1, msg, strlen(msg));
    long n2 = write(1, "hello from write()\n", 19);
    printf("returned bytes: raw = %ld, wrapper = %ld\n", n1, n2);
    return 0;
}

SYS_getpid = 39, SYS_write = 1 on this machine
wrapper and raw syscall agree: yes
hello from syscall(SYS_write, ...)
hello from write()
returned bytes: raw = 35, wrapper = 19

৪ · Parameter পাঠানো, ফল ফেরত আর errno

Kernel-কে তথ্য দেওয়ার তিন উপায়

System call-এর সাথে তথ্য পাঠাতে হয় — কোন ফাইল, কত বাইট, কোন buffer. পাঠ্যবইয়ে তিনটি উপায় বলা হয়:

দ্বিতীয় আর তৃতীয় উপায়ে kernel-কে user-এর মেমরি থেকে পড়তে হয়। Kernel কখনো ধরে নেয় না যে ঠিকানাটি সৎ। প্রতিটি পয়েন্টার যাচাই করে, তারপর বিশেষ ফাংশন দিয়ে কপি করে। কারণ একটি দুষ্ট প্রোগ্রাম kernel-এর নিজের মেমরির ঠিকানা দিয়ে বলতে পারে, “এখানে লিখুন”।

ফল আর ত্রুটি — errno

System call ব্যর্থ হতেই পারে: ফাইল নেই, অনুমতি নেই, ডিস্ক ভর্তি। Linux kernel তখন rax-এ একটি ঋণাত্মক সংখ্যা ফেরত দেয় — যেমন −2 মানে ENOENT (“এমন ফাইল নেই”)। কিন্তু C-র POSIX নিয়ম ভিন্ন: ফাংশন ফেরত দেবে −1, আর কারণটি থাকবে একটি আলাদা ভ্যারিয়েবল errno-তে। এই অনুবাদের কাজ করে glibc wrapper. নিচের ডায়াগ্রামে একটি ব্যর্থ open()-এর পথ দেখুন:

1fd = open("/no/such/file.txt", O_RDONLY);2// glibc: open() -> openat(AT_FDCWD, ...)3mov eax, 257 ; SYS_openat ; syscall4// kernel: look up "/" -> "no" ... missing5rax = -2  (-ENOENT); sysret6// glibc: is -4095 <= rax <= -1 ?7errno = -rax;  return -1;8if (fd == -1) perror("open");

এবার আসল মেশিনে কয়েক রকম ত্রুটি দেখি। perror লেখে stderr-এ; এখানে প্রথম লাইনেই dup2 দিয়ে stderr-কে stdout-এ জুড়ে দেওয়া হয়েছে (shell-এর 2>&1-এর মতো), যাতে দুটোই এক জায়গায় দেখা যায়:

#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

static void try_open(const char *path) {
    errno = 0;
    int fd = open(path, O_RDONLY);
    int saved = errno;                  /* copy errno at once */
    printf("open(\"%s\") = %d, errno = %d (%s)\n",
           path, fd, saved, strerror(saved));
    fflush(stdout);
    if (fd == -1) perror("  perror says");
    else close(fd);
}

int main(void) {
    dup2(STDOUT_FILENO, STDERR_FILENO); /* like 2>&1: show stderr here */
    try_open("/no/such/file.txt");
    try_open("/etc/shadow");
    try_open("/etc/hostname");
    errno = 0;
    long r = write(99, "x", 1);         /* fd 99 was never opened */
    printf("write(99, ...) = %ld, errno = %d (%s)\n", r, errno, strerror(errno));
    return 0;
}

open("/no/such/file.txt") = -1, errno = 2 (No such file or directory)
  perror says: No such file or directory
open("/etc/shadow") = -1, errno = 13 (Permission denied)
  perror says: Permission denied
open("/etc/hostname") = 3, errno = 0 (Success)
write(99, ...) = -1, errno = 9 (Bad file descriptor)

৫ · System call-এর ছয়টি শ্রেণি — POSIX আর Windows পাশাপাশি

কয়েকশো system call মনে রাখা অসম্ভব, দরকারও নেই। পাঠ্যবই (যেমন Silberschatz-দের Operating System Concepts) এগুলোকে ছয়টি শ্রেণিতে ভাগ করে। অফিসের ফাইল ক্যাবিনেটের ড্রয়ারের মতো ভাবুন — কোন অনুরোধ কোন ড্রয়ারে যায়, জানলেই নতুন call দেখে তার কাজ আন্দাজ করা যায়।

Unix-এর একটি সুন্দর নকশা-চিন্তা এখানে চোখে পড়ে: “সবকিছুই ফাইল”। কিবোর্ড, টার্মিনাল, pipe, এমনকি অনেক ডিভাইস — সবার সাথেই read আর write চলে। তাই device management-এর আলাদা call খুব কম; যা ফাইলের মতো করা যায় না, তার জন্য একটি সাধারণ “বাকি সব” call আছে: ioctl. আর এই একরূপ interface-এর মানদণ্ড হলো POSIX — IEEE-র একটি মানদণ্ড, যার প্রথম সংস্করণ ১৯৮৮ সালে। Linux, macOS আর BSD বেশিরভাগ ক্ষেত্রে POSIX মেনে চলে, তাই একই C কোড এদের সবখানে চলে; Windows-এ আলাদা API.

৬ · Library ফাংশন বনাম system call — printf আর write

নতুনদের একটি সাধারণ ভুল ধারণা: “printf একটি system call”. না। printf হলো C standard library-র ফাংশন, পুরোটা চলে user mode-এ। এটি সংখ্যাকে লেখায় রূপ দেয় (%d → "42"), ফলাফল একটি buffer-এ জমায়, আর সুবিধামতো সময়ে একবার write system call ডেকে পুরো buffer kernel-কে দেয়।

stdio library তিন রকম buffering ব্যবহার করে, আর কোনটি হবে তা নির্ভর করে stdout কোথায় যাচ্ছে তার ওপর:

• Line buffered: stdout যখন টার্মিনাল। প্রতিটি \n-এ buffer খালি হয়। তাই টার্মিনালে সবকিছু “স্বাভাবিক” দেখায়।
• Fully buffered: stdout যখন ফাইল বা pipe. Buffer ভরলে (সাধারণত কয়েক KB), fflush ডাকলে, বা প্রোগ্রাম স্বাভাবিকভাবে শেষ হলে লেখা যায়।
• Unbuffered: stderr. ত্রুটির বার্তা সঙ্গে সঙ্গে যায়, যাতে crash-এর আগেও দেখা যায়।

এই পাতার কোড-রানারে stdout একটি pipe (পরের অংশের bash আউটপুটে নিজের চোখেই দেখবেন), তাই printf fully buffered. নিচের প্রোগ্রাম printf আর সরাসরি write মিশিয়ে লেখে। কোড পড়ে আগে অনুমান করুন আউটপুট কোন ক্রমে আসবে, তারপর চালান:

#include <stdio.h>
#include <string.h>
#include <unistd.h>

static void raw(const char *s) {          /* straight to the kernel */
    write(STDOUT_FILENO, s, strlen(s));
}

int main(void) {
    printf("stdout is a terminal? %s\n", isatty(STDOUT_FILENO) ? "yes" : "no");
    printf("1. printf  (goes into the stdio buffer)\n");
    raw("2. write   (one system call, printed now)\n");
    printf("3. printf  (still waiting in the buffer)\n");
    raw("4. write   (printed now)\n");
    fflush(stdout);                       /* buffer -> one write() call */
    raw("5. write   (after fflush)\n");
    printf("6. printf  (flushed by exit)\n");
    return 0;
}

2. write   (one system call, printed now)
4. write   (printed now)
stdout is a terminal? no
1. printf  (goes into the stdio buffer)
3. printf  (still waiting in the buffer)
5. write   (after fflush)
6. printf  (flushed by exit)

৭ · System call-এর খরচ, vDSO আর /proc

প্রতিটি system call-এ মোড বদল, register সংরক্ষণ আর ফেরত, অনুমতি যাচাই — সব মিলিয়ে খরচ আছে। আধুনিক x86 CPU-তে প্রায় কিছু না করা একটি syscall-এর খরচ সাধারণত মোটামুটি একশো থেকে কয়েকশো ন্যানোসেকেন্ড; সাধারণ একটি function call তার চেয়ে কয়েক ডজন গুণ সস্তা। সংখ্যাটি CPU, kernel-এর সংস্করণ আর নিরাপত্তা-ব্যবস্থার ওপর অনেক নির্ভর করে — ২০১৮ সালে Meltdown নিরাপত্তা-ত্রুটির পর চালু হওয়া KPTI-এর মতো সুরক্ষায় অনেক মেশিনে খরচ উল্লেখযোগ্যভাবে বেড়েছে। তাই নির্দিষ্ট সংখ্যা মুখস্থ না করে নিজের মেশিনে মেপে দেখাই ঠিক।

একটি syscall-এর খরচ ছোট, কিন্তু লাখ লাখ হলে বড়। ধরুন একটি লগ-প্রোগ্রাম ১০ লাখ লাইন লিখবে, প্রতিটি ২০ বাইট, আর ধরে নিই প্রতিটি syscall-এ ২০০ ন্যানোসেকেন্ড লাগে:

প্রায় ২০০ গুণ কম syscall! এজন্যই stdio buffer করে, আর এজন্যই বড় সার্ভার সফটওয়্যার syscall কমানোর নানা কৌশল খোঁজে।

vDSO — kernel-এ না গিয়েই kernel-এর উত্তর

কিছু প্রশ্ন প্রোগ্রাম সেকেন্ডে হাজারবার করে — “এখন কয়টা বাজে?” (clock_gettime, gettimeofday). ওয়েব সার্ভার প্রতিটি অনুরোধের লগে সময় লেখে, গেম প্রতিটি ফ্রেমে সময় দেখে। প্রতিবার kernel-এ ঢোকা অপচয়। Linux-এর সমাধান: kernel প্রতিটি প্রসেসের মেমরিতে একটি ছোট, kernel-এর তৈরি library বসিয়ে দেয় — vDSO (virtual dynamic shared object). সঙ্গে থাকে একটি পড়ার-অনুমতি-মাত্র ডেটা পাতা ([vvar]), যেখানে kernel নিয়মিত সময়ের তথ্য হালনাগাদ রাখে। glibc-র clock_gettime তখন user mode-এই সেই পাতা পড়ে উত্তর দেয় — কোনো মোড বদল নেই।

vDSO সব কাজে চলে না — শুধু এমন কাজে, যেখানে উত্তর নিরাপদে পড়ার-অনুমতি-মাত্র মেমরি থেকে দেওয়া যায় (x86-64-এ মূলত clock_gettime, gettimeofday, time, getcpu). ফাইল লেখা বা প্রসেস তৈরির মতো কাজে kernel-এ যেতেই হয়। আর সময় যাচাইয়ের উৎস যদি এমন হার্ডওয়্যার ঘড়ি হয় যা user mode থেকে পড়া যায় না (কিছু virtual machine-এ এমন হয়), তাহলে vDSO চুপচাপ আসল syscall-এ ফিরে যায়।

/proc — kernel-এর জানালা দিয়ে নিজেকে দেখা

Linux-এ /proc একটি বিশেষ ফাইল সিস্টেম: এখানের “ফাইল” ডিস্কে থাকে না, পড়ার মুহূর্তে kernel তৈরি করে দেয় (প্রসেস আর /proc নিয়ে বিস্তারিত পর্ব ১১-এ)। আর /proc/self সবসময় বোঝায় “যে প্রসেস এখন পড়ছে, সে নিজে”। এই পাতার bash রানারে strace নেই, তাই syscall গোনা যাবে না; তবে kernel প্রসেস সম্পর্কে যা জানে, তার অনেকটাই দেখা যায়:

echo "== files inside /proc/self (here 'self' is the ls process) =="
ls /proc/self/ | head -n 12 | tr '\n' ' '; echo
echo
echo "== open file descriptors of this shell =="
ls -l /proc/$$/fd | awk 'NR>1 {print $9, $10, $11}'
echo
echo "== selected fields of /proc/self/status (self = grep) =="
grep -E '^(Name|State|Pid|PPid|Uid|Threads|voluntary_ctxt_switches|nonvoluntary_ctxt_switches)' /proc/self/status
echo
echo "== the vDSO is mapped into every process =="
grep -E 'vdso|vvar' /proc/self/maps | awk '{print $2, $6}'

== files inside /proc/self (here 'self' is the ls process) ==
arch_status attr autogroup auxv cgroup clear_refs cmdline comm coredump_filter cpu_resctrl_groups cpuset cwd

== open file descriptors of this shell ==
0 -> pipe:[918826095]
1 -> pipe:[918826096]
2 -> pipe:[918826097]
255 -> /home/wandbox/prog.sh

== selected fields of /proc/self/status (self = grep) ==
Name:	grep
State:	R (running)
Pid:	8
PPid:	2
Uid:	999	999	999	999
Threads:	1
voluntary_ctxt_switches:	0
nonvoluntary_ctxt_switches:	1

== the vDSO is mapped into every process ==
r--p [vvar]
r-xp [vdso]

৮ · System call চোখে দেখা — strace, Process Monitor, dtruss

একটি প্রোগ্রাম kernel-এর সাথে কী কী কথা বলছে, তা শোনার টুল আছে। এটি debugging-এর অন্যতম শক্তিশালী কৌশল: “প্রোগ্রাম কোন ফাইল খুঁজছে পাচ্ছে না?”, “কোথায় আটকে আছে?” — সোর্স কোড না দেখেও উত্তর মেলে।

Linux-এ cat notes.txt চালালে strace কী দেখায়, তার একটি উদাহরণ নিচে। (এটি একটি নমুনা আউটপুট, এই পাতায় চালানো যাবে না; লম্বা অংশ “…” দিয়ে ছোট করা। আপনার মেশিনে ঠিকানা আর কিছু লাইন ভিন্ন হবে।)

$ strace cat notes.txt
execve("/usr/bin/cat", ["cat", "notes.txt"], 0x7ffc... /* 24 vars */) = 0
brk(NULL)                               = 0x5581f3a4e000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=27133, ...}) = 0
mmap(NULL, 27133, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f2c1a9b4000
close(3)                                = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0"..., 832) = 832
...
openat(AT_FDCWD, "notes.txt", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=12, ...}) = 0
read(3, "Hello Dhaka\n", 131072)        = 12
write(1, "Hello Dhaka\n", 12Hello Dhaka
)           = 12
read(3, "", 131072)                     = 0
close(3)                                = 0
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

প্রতিটি লাইনের গঠন একই: নাম(argument…) = ফল. নিচের ডায়াগ্রামে একটি লাইন টুকরো করে পড়ি:

এবার পুরো নমুনাটি লাইন ধরে বুঝে নিন:

• execve — shell-এর তৈরি নতুন প্রসেস নিজের জায়গায় /usr/bin/cat প্রোগ্রামটি বসাল। ফল 0 মানে সফল।
• brk, mmap — মেমরি চাওয়া (পর্ব ৩৮-এ বিস্তারিত)।
• access("/etc/ld.so.preload") = −1 ENOENT — dynamic linker দেখছে আগে থেকে কোনো library জোর করে লোড করার নির্দেশ আছে কি না। নেই — এবং এটি স্বাভাবিক। strace-এ ENOENT দেখলেই ভয় পাবেন না; অনেক প্রোগ্রাম ইচ্ছে করেই “আছে কি?” যাচাই করে।
• openat … ld.so.cache, তারপর libc.so.6 — dynamic linker libc খুঁজে খুলছে, ELF header পড়ছে (\177ELF), মেমরিতে map করছে। আপনার প্রোগ্রামের main শুরুর আগেই এত কাজ!
• openat(…"notes.txt"…) = 3 — এবার cat-এর আসল কাজ শুরু।
• read(3, …, 131072) = 12 — ১২৮ KB পর্যন্ত পড়তে চেয়েছিল, ফাইলে ছিল ১২ বাইট। read কম ফেরত দিতেই পারে; প্রোগ্রামকে তা সামলাতে হয়।
• write(1, …, 12) — stdout-এ লেখা। খেয়াল করুন, “Hello Dhaka” লেখাটি strace-এর লাইনের মাঝখানে ঢুকে গেছে: strace নিজে লেখে stderr-এ, আর cat লেখে stdout-এ, দুটোই একই টার্মিনালে।
• read(3, "", …) = 0 — 0 মানে ফাইলের শেষ (end of file). cat থামে।
• close, exit_group(0) — সব fd বন্ধ, প্রসেসের সব থ্রেড শেষ। = ? কারণ এই call কখনো ফেরে না।

strace -c ls                  # summary: which syscalls, how many, how long
strace -e trace=openat,read ls  # show only these syscalls
strace -f -o log.txt ./server # follow child processes, write to a file
strace -p 1234                # attach to a running process (needs permission)

৯ · AI-এর যুগে system call

“Linux-এ একটি ফাইল কপি করার C প্রোগ্রাম লিখে দাও” — AI কয়েক সেকেন্ডে দেবে, আর সেটি সাধারণত চলবেও। সমস্যা লুকিয়ে থাকে কিনারায়: আংশিক write, errno ঠিকমতো না দেখা, ভুল OS-এর API. System call বোঝেন বলে আপনি এগুলো ধরতে পারবেন। AI-এর সাধারণ ভুলগুলো:

AI-এর লেখা systems কোড বা কমান্ড চালানোর আগে — চেকলিস্ট

• AI-কে আমার OS, distro, CPU architecture আর compiler-এর নাম বলেছি; উত্তর সেই OS-এর জন্যই কি না মিলিয়েছি
• প্রতিটি syscall-এর ফেরত মান আর errno যাচাই আছে; man page (section 2) পড়ে ফেরত মানের নিয়ম মিলিয়েছি
• strace (বা Windows-এ Process Monitor) দিয়ে চালিয়ে দেখেছি, প্রোগ্রাম আসলে কোন ফাইল খোলে আর কতগুলো syscall করে
• আউটপুট টার্মিনালে আর ফাইলে redirect করে — দুইভাবেই চালিয়েছি, ক্রম একই থাকে কি না দেখেছি
• ভুল ইনপুটে (না-থাকা ফাইল, অনুমতিহীন ফাইল, পূর্ণ ডিস্কের অনুকরণ) পরীক্ষা করেছি
• sudo, chmod 777 বা নিরাপত্তা-ব্যবস্থা বন্ধ করার কোনো পরামর্শ মানিনি; ন্যূনতম অনুমতির পথ খুঁজেছি