পাঠ ০৩ · ৫৬-এর মধ্যে · মডিউল ১
Home / Courses / Operating Systems (OS) / সিস্টেম কল

সিস্টেম কল ও OS সার্ভিস

System calls & OS services
৮ মিনিট পড়া শুরু · Beginner Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • সিস্টেম কল কী এবং এটি কেন ইউজার-মোড কোড ও কার্নেলের মধ্যে একমাত্র বৈধ "দরজা"
  • ডুয়াল-মোড অপারেশন — ইউজার মোড বনাম কার্নেল মোড, এবং mode bit কীভাবে কাজ করে
  • এই বিভাজন কেন সুরক্ষার জন্য অপরিহার্য
  • সিস্টেম কলের প্রধান ক্যাটাগরিগুলো এবং Python দিয়ে একটি সিস্টেম-কল ডিসপ্যাচ টেবিলের সিমুলেশন

১ · সিস্টেম কল কী

সিস্টেম কলSystem Callএকটি ইউজার-মোড প্রোগ্রামের জন্য প্রিভিলেজড OS সার্ভিস (যেমন ফাইল পড়া, প্রসেস তৈরি করা) অনুরোধ করার একমাত্র, নিয়ন্ত্রিত পথ। হলো একটি ইউজার-মোড প্রোগ্রামের জন্য কোনো প্রিভিলেজড OS সার্ভিস অনুরোধ করার একমাত্র পথ — একটি ফাইল পড়া, একটি নতুন প্রসেস তৈরি করা, বা নেটওয়ার্কে ডেটা পাঠানো — এই সবকিছুর জন্য একটি প্রোগ্রামকে OS-কে অনুরোধ জানাতে হয়, নিজে সরাসরি হার্ডওয়্যার স্পর্শ করতে পারে না। সিস্টেম কল তাই অবিশ্বস্ত ইউজার কোড ও বিশ্বস্ত কার্নেলের মধ্যে একটি সুনির্দিষ্ট, সুরক্ষিত "দরজা" হিসেবে কাজ করে।

২ · ডুয়াল-মোড অপারেশন — ইউজার মোড বনাম কার্নেল মোড

হার্ডওয়্যারে একটি mode bitMode Bitহার্ডওয়্যারে একটি বিট যা ট্র্যাক করে CPU এই মুহূর্তে ইউজার মোডে নাকি কার্নেল মোডে চলছে। থাকে যা ট্র্যাক করে CPU এই মুহূর্তে কোন মোডে চলছে —

ইউজার মোডUser Modeসীমাবদ্ধ মোড, যেখানে বেশিরভাগ অ্যাপ্লিকেশন কোড চলে — সরাসরি হার্ডওয়্যার অ্যাক্সেস নেই।
সীমাবদ্ধ — বেশিরভাগ অ্যাপ্লিকেশন কোড এখানে চলে, সরাসরি হার্ডওয়্যার অ্যাক্সেস নিষিদ্ধ।
কার্নেল মোডKernel Modeপ্রিভিলেজড মোড, যেখানে সম্পূর্ণ হার্ডওয়্যার অ্যাক্সেস থাকে — শুধু OS-এর নিজস্ব কোড এখানে চলে।
প্রিভিলেজড — সম্পূর্ণ হার্ডওয়্যার অ্যাক্সেস, শুধু OS-এর কোড এখানে চলার অনুমতি পায়।

একটি সিস্টেম কল একটি নিয়ন্ত্রিত সুইচ ঘটায় — ইউজার মোড থেকে কার্নেল মোডে যায়, OS অনুরোধটি যাচাই করে/সম্পন্ন করে, তারপর নিয়ন্ত্রণ ইউজার মোডে ফিরিয়ে দেয়। প্রোগ্রামের কাছে এই পুরো প্রক্রিয়া একটি সাধারণ ফাংশন কলের মতোই দেখতে লাগে, কিন্তু ভেতরে একটি সম্পূর্ণ মোড-সুইচ ঘটে যাচ্ছে।

ইউজার মোড (কোড চলছে) সিস্টেম কল কার্নেল মোড (OS পরিবেশন করে) রিটার্ন — নিয়ন্ত্রণ আবার ইউজার মোডে ফিরে আসে
সিস্টেম কল ইউজার মোড থেকে কার্নেল মোডে একটি নিয়ন্ত্রিত, সাময়িক সুইচ ঘটায়।

৩ · এই বিভাজন কেন গুরুত্বপূর্ণ

L01-এ আলোচিত সুরক্ষার প্রশ্নে ফিরে যাই — যদি প্রতিটি প্রোগ্রাম সরাসরি হার্ডওয়্যার অ্যাক্সেস পেত, একটি বাগযুক্ত বা ম্যালিশিয়াস প্রোগ্রাম সরাসরি হার্ডওয়্যার বা অন্য প্রসেসের মেমরি নষ্ট করে দিতে পারত। ইউজার/কার্নেল মোড বিভাজন এই ঝুঁকি ঠেকায় — শুধুমাত্র OS-এর নিজের কোড (যা যাচাই ও নিয়ন্ত্রিত) কার্নেল মোডে চলে, বাকি সব কোড সীমাবদ্ধ ইউজার মোডে আটকে থাকে। এই থিমটি এই কোর্সের M11 (প্রোটেকশন) ও রিং প্রোটেকশন পাঠে আরও গভীরভাবে ফিরে আসবে।

৪ · সিস্টেম কলের ক্যাটাগরি

প্রসেস কন্ট্রোল
প্রসেস তৈরি/টার্মিনেট করা (M2-এ বিস্তারিত)
ফাইল ম্যানেজমেন্ট
ফাইল খোলা/পড়া/লেখা/বন্ধ করা (M9-এ বিস্তারিত)
ডিভাইস ম্যানেজমেন্ট
ডিভাইস রিকোয়েস্ট/রিলিজ করা (M10-এ বিস্তারিত)
ইনফরমেশন মেইনটেন্যান্স
সিস্টেম তথ্য (সময়, প্রসেস আইডি) পাওয়া
কমিউনিকেশন
প্রসেসের মধ্যে বার্তা আদান-প্রদান (M2/L08-এ IPC বিস্তারিত)

৫ · একটি সিস্টেম-কল ডিসপ্যাচ টেবিলের সিমুলেশন

নিচের কোডে একটি সিমুলেটেড সিস্টেম-কল ডিসপ্যাচ টেবিল বানানো হয়েছে — current_mode-এর মান "kernel" না হলে (অর্থাৎ mode switch না ঘটে থাকলে) হ্যান্ডলার আদৌ চলতে দেওয়া হয় না, বরং একটি প্রোটেকশন ফল্ট রিটার্ন হয়।

Python
# সিস্টেম কল ডিসপ্যাচ টেবিল -- সিমুলেটেড, বাস্তব কোনো kernel/hardware call নয়

def sys_create_process(args):
    return f"নতুন প্রসেস তৈরি হলো: {args['name']}"

def sys_read_file(args):
    return f"ফাইল পড়া হলো: {args['filename']}"

def sys_write_file(args):
    return f"ফাইলে লেখা হলো: {args['filename']} <- '{args['data']}'"

dispatch_table = {
    "create_process": sys_create_process,
    "read_file": sys_read_file,
    "write_file": sys_write_file,
}

def handle_syscall(name, args, current_mode):
    # current_mode == "kernel" ধরে নেওয়া হচ্ছে mode switch ইতিমধ্যে ঘটে গেছে
    if current_mode != "kernel":
        return f"[প্রোটেকশন ফল্ট] '{name}' প্রত্যাখ্যাত -- user mode থেকে সরাসরি প্রিভিলেজড অপারেশন করা যায় না"
    handler = dispatch_table.get(name)
    if handler is None:
        return f"[এরর] অজানা সিস্টেম কল: {name}"
    return handler(args)

print("--- স্বাভাবিক সিস্টেম কল (mode switch হয়ে গেছে ধরে নিয়ে) ---")
print(handle_syscall("create_process", {"name": "P1"}, current_mode="kernel"))
print(handle_syscall("write_file", {"filename": "notes.txt", "data": "hello"}, current_mode="kernel"))

print("\n--- সরাসরি user mode থেকে চেষ্টা (mode switch ছাড়াই) ---")
print(handle_syscall("write_file", {"filename": "notes.txt", "data": "hacked"}, current_mode="user"))

    
লক্ষ্য করুন — handle_syscall ফাংশনটি current_mode পরীক্ষা না করে সরাসরি dispatch_table-এর হ্যান্ডলার চালিয়ে দিতেই পারত (তখন তৃতীয় প্রিন্টটিও সফল হতো) — কিন্তু বাস্তব হার্ডওয়্যারে ঠিক এই চেকটিই (mode bit পরীক্ষা করা) ইউজার কোডকে সরাসরি প্রিভিলেজড অপারেশন করা থেকে আটকায়।
মূল কথা · Key takeaway

সিস্টেম কল কোনো ঐচ্ছিক সুবিধা নয় — এটি একমাত্র বৈধ পথ যার মাধ্যমে ইউজার কোড OS-এর প্রিভিলেজড ক্ষমতা ব্যবহার করতে পারে। ডুয়াল-মোড হার্ডওয়্যার সাপোর্ট ছাড়া এই নিয়ন্ত্রণ বাস্তবায়ন করা সম্ভবই হতো না — এটিই আধুনিক OS সুরক্ষার ভিত্তি।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ একটি সাধারণ ফাংশন কল ও একটি সিস্টেম কলের মধ্যে বাস্তব পার্থক্য কী, যখন উভয়ই প্রোগ্রামারের কাছে "একটি ফাংশন ডাকা"-র মতোই দেখতে লাগে?

একটি সাধারণ ফাংশন কল একই মোডের মধ্যে থেকে যায় (ইউজার কোড ইউজার কোডকেই ডাকছে) — কোনো মোড সুইচ ঘটে না। একটি সিস্টেম কল আসলে একটি বিশেষ CPU নির্দেশ (যেমন একটি "trap" বা "software interrupt") ট্রিগার করে যা হার্ডওয়্যারকে বাধ্য করে mode bit পরিবর্তন করে কার্নেল মোডে যেতে, একটি পূর্বনির্ধারিত, নিরাপদ এন্ট্রি পয়েন্টে (OS নিজেই নির্ধারণ করে কোথায় প্রবেশ করা যাবে) — প্রোগ্রামার এটি একটি ফাংশন কলের মতো লেখেন (যেমন C-তে read()), কিন্তু ভেতরে সম্পূর্ণ ভিন্ন, প্রিভিলেজড কিছু ঘটছে।

প্র ০২ যদি mode bit-এর মতো হার্ডওয়্যার সাপোর্ট না থাকত, তাহলে "ইউজার মোড থেকে প্রিভিলেজড অপারেশন প্রত্যাখ্যান করা" শুধু সফটওয়্যার দিয়ে বলবৎ করা যেত কি?

না, নির্ভরযোগ্যভাবে নয়। শুধু সফটওয়্যার-স্তরের চেক (যেমন উপরের কোডের if current_mode != "kernel") একটি সহযোগিতাপূর্ণ প্রোগ্রামকে থামাতে পারে, কিন্তু একটি ম্যালিশিয়াস প্রোগ্রাম সহজেই এই চেক এড়িয়ে সরাসরি হার্ডওয়্যার অ্যাক্সেস করার চেষ্টা করতে পারত — যদি হার্ডওয়্যার নিজে থেকেই তা প্রতিরোধ না করত। প্রকৃত নিরাপত্তা আসে হার্ডওয়্যার-স্তরের বাধ্যবাধকতা থেকে (CPU নিজেই প্রিভিলেজড নির্দেশ ইউজার মোডে চালাতে অস্বীকার করে), সফটওয়্যার কনভেনশন থেকে নয়।

প্র ০৩ উপরের কোড সেলে তৃতীয় প্রিন্টটি (user mode থেকে চেষ্টা) কেন প্রত্যাখ্যাত হলো — কোড লজিক অনুযায়ী ব্যাখ্যা করুন।

handle_syscall("write_file", ..., current_mode="user") কল হওয়ার সাথে সাথে ফাংশনের প্রথম লাইনেই if current_mode != "kernel" শর্তটি সত্য হয়ে যায় (কারণ current_mode এখানে "user", "kernel" নয়) — ফলে ফাংশনটি dispatch_table-এর হ্যান্ডলার আদৌ না চালিয়েই সরাসরি একটি প্রোটেকশন-ফল্ট বার্তা রিটার্ন করে দেয়। হ্যান্ডলার ফাংশনটি (sys_write_file) এই ক্ষেত্রে কখনো ডাকাই হয় না।

অনুশীলন

  1. চিন্তা করুন: আপনার প্রিয় প্রোগ্রামিং ভাষায় ফাইল পড়ার একটি লাইন কোড লিখুন (মনে মনে বা কাগজে) এবং চিহ্নিত করুন কোন অংশটি আসলে একটি সিস্টেম কল ট্রিগার করছে।

    উদাহরণস্বরূপ Python-এর open("file.txt").read() — এখানে open() ও .read() উভয়ই ভেতরে ভেতরে অপারেটিং সিস্টেমের সিস্টেম কল (Unix-এ যথাক্রমে open() ও read() সিস্টেম কল) ট্রিগার করে — Python নিজে ফাইলটি "পড়ে না," বরং কার্নেলকে অনুরোধ পাঠায় এবং কার্নেল প্রকৃত ডিস্ক I/O সম্পন্ন করে ডেটা ফেরত দেয়।

  2. পরীক্ষা করুন: উপরের কোড সেলে dispatch_table-এ একটি নতুন এন্ট্রি (যেমন "delete_file") যোগ না করেই handle_syscall("delete_file", {}, current_mode="kernel") কল করলে কী আউটপুট আসবে?

    current_mode == "kernel" হওয়ায় প্রথম চেক পাস করবে, কিন্তু dispatch_table.get("delete_file") None রিটার্ন করবে (কারণ এই নামের কোনো হ্যান্ডলার টেবিলে নেই), তাই ফাংশনটি "[এরর] অজানা সিস্টেম কল: delete_file" প্রিন্ট করবে — এটি দেখায় mode-চেক পাস করাই যথেষ্ট নয়, সিস্টেম কলটি আদৌ সংজ্ঞায়িত কি না তাও যাচাই করতে হয়।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
অপারেটিং সিস্টেমের প্রকারভেদ