Skip to content

المرحلة الثانية: إدارة المقاطعات والذاكرة الفيزيائية ​

في هذه المرحلة، انتقلنا من مجرد طباعة نصوص على الشاشة إلى وضع الأسس الحقيقية لنظام التشغيل QOS Kernel Kernel. ركزنا على جانبين أساسيين: التعامل مع الاستثناءات (Exceptions) وإدارة الذاكرة الفيزيائية (RAM).

ما تم إنجازه: ​

1. جدول واصفات المقاطعة (IDT) ​

  • تم إعداد Interrupt Descriptor Table (IDT) للتعامل مع استثناءات المعالج (مثل Page Fault, Double Fault, General Protection Fault).
  • استخدمنا مكتبة x86_64 مع lazy_static لتعريف الـ IDT بشكل آمن في لغة Rust.
  • النواة الآن قادرة على التقاط الأخطاء وعرض تفاصيلها (Kernel Panic) بدلاً من إعادة التشغيل الصامتة (Triple Fault).

2. مدير الذاكرة الفيزيائية (PMM - Bitmap Allocator) ​

  • بناء Bitmap Allocator متوافق مع خيوط المعالجة المتعددة (Thread-safe) باستخدام AtomicU64 لضمان مبدأ الأمان المُثبت بالتصميم.
  • قراءة خريطة الذاكرة من Multiboot2 لمعرفة المناطق المتاحة للعمل والمحجوزة.
  • حجز أول 4 ميغابايت (تحتوي على BIOS وبيانات النواة BSS/Text) لحمايتها من التخصيص الخاطئ وتجنب الكتابة فوق الكرنل.
  • تنفيذ دوال التخصيص alloc_frame والتحرير dealloc_frame.
  • تقليل مساحة الـ Bitmap بشكل مؤقت ليلائم 128MB لتفادي تضخم قسم .bss وخروجه عن نطاق الـ Page Table الأولي.

3. تمرير المتغيرات بين Assembly و Rust ​

  • تم تطبيق معيار System V AMD64 ABI لتمرير مؤشر Multiboot2 كمعامل أول (Argument) عبر مسجل RDI من كود التجميع (long_mode_start.asm) إلى الدالة الرئيسية في Rust (kernel_main).

4. صيد الأخطاء (Debugging) - خطأ CPUID القاتل ​

  • واجهنا Triple Fault غامض قبل الوصول إلى كود Rust، وكان النظام يعيد التشغيل في واجهة GRUB دون أي رسالة.
  • التشخيص: بالاستعانة بسجلات QEMU (int,cpu_reset) والتفريغ العكسي (objdump)، وجدنا أن الدالة check_cpuid في start.asm كانت تدفع قيمة الـ Multiboot Magic (0x36d76289) إلى المكدس ثم تسحبها إلى مسجل EFLAGS.
  • السبب: هذا الرقم العشوائي قام بتفعيل البت رقم 17 (Virtual 8086 Mode) والبت رقم 9 (Interrupt Flag) عن طريق الخطأ، مما أدى إلى انهيار فوري للمعالج.
  • الحل: تمت إعادة كتابة دالة check_cpuid لتتفاعل مع EFLAGS بشكل صحيح من خلال المكدس دون إدخال قيم عشوائية.

النتيجة النهائية ​

تعمل النواة الآن باستقرار تام في وضع 64-bit، وقد تم إثبات قدرة PMM على تخصيص إطار ذاكرة عند العنوان 0x400000 (مباشرة بعد الـ 4MB المحجوزة) وتحريره بنجاح، مع طباعة الإحصائيات (124 ميغابايت حرة من أصل 128 ميغابايت) على الشاشة، واكتملت المرحلة الثانية بنجاح باهر.

تم تطويره بحب بواسطة مجتمع Qtoom.