[c30tehran]

هسته لینوکس یکی از بزرگ ترین پروژه های منبع باز است که قدمتی طولانی دارد. همان طور که می دانید، توزیع های مختلف لینوکسی، خود لینوکس نیستند و لینوکس تنها به هسته این سیستم عامل می گویند که 13 میلیون خط کد دارد. هسته سیستم عامل پایین ترین سطح نرم افزاری است که با سخت افزار کامپیوتر در ارتباط است. لینوکس مسوول تمام نرم افزارهایی است که در حالت کاربری (user mode) اجرا می شوند. همچنین پروسه های مختلف از جمله سرورها را اجرا می کند و اطلاعات لازم از پروسه ها را در اختیار دیگر پروسه ها قرار می دهد.

انواع هسته ها:
برای تولید یک هسته دغدغه های مختلفی وجود دارد. به طور کلی، بیشتر هسته ها به سه نوع یکپارچه، میکروهسته و ترکیبی تقسیم می شوند. لینوکس یک هسته یکپارچه است، در صورتی که os x (مکینتاش) و ویندوز7 از هسته های ترکیبی استفاده می کنند. بهتر است به هر 3 نظری داشته باشیم:

میکروهسته :
میکروهسته تنها کارهای مشخصی را انجام می دهد: مدیریت پردازنده، حافظه و ipc. بقیه کارهای کامپیوتر، جانبی تلقی شده و در حالت کاربر اجرا می شوند. میکروهسته ها قابلیت پرتابل بودن دارند چون سیستم عامل نیازی ندارد که نوع ویدئوکارت متصل به سیستم را بداند. میکروهسته ها ردپای کوچکی دارند (هزینه انجام کار) و حافظه و فضای مصرفی آنها بسیار پایین است. از طرفی امن تر از هسته های دیگر هستند، چرا که تنها پروسه های مشخصی در حالت کاربر اجرا می شوند که نیازی به اجرا در حالت ناظر (supervisor mode) ندارند.
میکروهسته ها، ویژگی های خوبی دارند که پرتابل بودن، حجم کم، حافظه مصرفی کم و امنیت از جمله آنهاست. البته سخت افزارهای پشتیبانی شده توسط این هسته کمتر است و به دلیل اجرای درایورهای سخت افزاری در حالت کاربری، سخت افزارها کندتر هستند. ضمن آن که پروسه ها برای دریافت اطلاعات باید در صف منتظر بمانند. همچنین پروسه ها نمی توانند به دیگر پروسه ها دسترسی پیدا کنند.

هسته یکپارچه :
هسته های یکپارچه درست نقطه مقابل میکروهسته ها هستند و نه تنها پردازنده، حافظه و ipc، بلکه چیزهای دیگری از جمله درایورهای دستگاه ها، مدیریت سیستم فایل و فراخوان های سیستمی را مدیریت می کنند. هسته های یکپارچه در دسترسی سخت افزاری و چندوظیفگی بهتر عمل می کنند زیرا برنامه ای که در حال اجرا، انتظار یا توقف است می تواند به صورت مستقیم اطلاعات دیگر پروسه ها را دریافت کند و در هیچ صفی برای این عمل منتظر نمی ماند. البته این موضوع می تواند مشکل ساز هم باشد چون بیشتر پروسه ها درحالت ناظر اجرا می شوند و اگر درست رفتار نکنند، می توانند سیستم را از کار بیندازند.
از ویژگی های این هسته می توان به دسترسی بهتر به سخت افزارها و برنامه ها، ارتباط ساد ه تر پروسه ها با یکدیگر و عدم نیاز به نصب درایور سخت افزار برای سخت افزارهای شناخته شده در سیستم و در نهایت عکس العمل سریع تر پروسه ها به دلیل عدم وجود صف انتظار برای آنهاست.
از مشکلات این هسته، بزرگ بودن آن، مصرف حافظه بالا و امنیت پایین تر به دلیل اجرای همه چیز در حالت ناظر است.

هسته های ترکیبی :
هسته های ترکیبی می توانند انتخاب کنند که چه چیزی در حالت کاربر اجرا شود و چه چیزی در حالت ناظر. بیشتر مواقع چیزهایی مثل درایورهای سخت افزاری یا ورودی خروجی ها در حالت کاربر و فراخوان های سیستمی و ارتباط میان پروسه ها در حالت ناظر اجرا می شوند. این یعنی استفاده بهینه از هر دو که مشکل کوچکی ایجاد می کند؛ تولیدکنندگان سخت افزار باید کار بیشتری انجام دهند چون مسوولیت اجرای همه چیز با آنهاست. همچنین این هسته ها از مشکل میکروهسته ها نیز برخوردارند و باز هم مشکل انتظار در صف وجود دارد.
از ویژگی های این نوع هسته ها این است که توسعه دهنده می تواند خود انتخاب کند که چه چیز در حالت کاربر و چه چیز در حالت ناظر اجرا شود. همچنین نصب آن حجم کمتری نسبت به میکروهسته ها می گیرد و از دیگر مدل ها انعطاف پذیرتر است.
اما این مدل معایبی نیز دارد که وجود لگ در اجرای پروسه و مدیریت پروسه ها توسط کاربر بخشی از آنهاست.

فایل های هسته لینوکس کدام ها هستند؟
فایل هسته در اوبونتو، در مسیر boot / قرار دارد و vmlinuz-version نام دارد. نام vmlinuz از دنیای یونیکسی آورده شده که در آن دوران، یعنی دهه 60 میلادی به هسته یونیکس، یونیکس می گفتند و بنابراین لینوکسی ها هم هسته خود را لینوکس نام گذاشتند.
پس از این که حافظه مجازی برای بهتر کردن قابلیت های چندوظیفگی توسعه پیدا کرد، سرنام vm در ابتدای فایل هسته قرار داده شد تا نشان دهد این هسته از حافظه مجازی پشتیبانی می کند. تا مدت های زیادی هسته لینوکس vmlinux نامیده می شد تا این که آنقدر بزرگ شد که حافظه بوت آن فشرده شد و x آخر کلمه به دلیل فشرده شدن هسته با سیستم zlib، به z تغییر پیدا کرد؛ هر چند همیشه این روش فشرده سازی کاربرد ندارد و گاهی از lzma یا bzip2 استفاده می شود. در برخی از هسته های لینوکسی، نام هسته تنها zimage است.
سیستم نگارش بندی آن به صورت چهارگانه a.b.c.d است. a.b احتمالا 6/2 است، c نگارش فعلی هسته است و d نشانگر وصله ها یا نگارش های رفع عیب است.
در فولدر boot / فایل های بسیار مهم دیگری نیز قرار دارند که معمولا initrd.img-version، system.map-version و config-version وجود دارد.
فایل initrd اغلب به عنوان دیسک های رم استفاده می شوند که فایل اصلی هسته را باز و اجرا می کنند.
فایل system.map برای استفاده در مدیریت حافظه به کار می رود تا زمانی که هسته به طور کامل بارگذاری شود.
فایل config به هسته می گوید که چه گزینه ها و ماژول هایی باید بعد از کامپایل در هسته بارگذاری شود.

معماری هسته لینوکس
از آنجا که لینوکس هسته یکپارچه ای دارد، حجم زیادی نسبت به دیگر هسته ها داشته و پیچیدگی آن نیز بیشتر است. این ویژگی طراحی در سال های اخیر مورد نقد قرار گرفته و هنوز هم برخی از دغدغه های امنیتی هسته های یکپارچه را در خود دارد. برای گذر از چنین دغدغه هایی، توسعه دهندگان هسته لینوکس ماژول های هسته را ایجاد کردند که می تواند هنگام اجرا بارگذاری شده یا از حالت بارگذاری خارج شود. به این ترتیب می توان به هسته لینوکس در هنگام اجرا امکاناتی را افزود یا از آن حذف کرد. این کار فقط افزودن قابلیت های سخت افزاری به هسته نیست و می توان حتی کل هسته را بدون نیاز به راه اندازی مجدد کامپیوتر تعویض کرد. فقط تصور کنید اگر می شد سرویس پک ویندوز را نصب کرد و حتی یک بار هم آن را ریستارت نکرد!

ماژول های هسته
چه می شد اگر ویندوز تمام درایورهای سخت افزاری را در خود داشت و تنها برای استفاده از یک دستگاه کافی بود آن را روشن کنیم؟ این همان چیزی است که ماژول های هسته لینوکس انجام می دهند. ماژول های هسته که به نام ماژول های قابل بارگذاری هسته (lkm) شناخته می شوند، یکی از روش های استفاده از سخت افزارهای سیستم بدون استفاده از تمام حافظه موجود است.
یک ماژول عموما قابلیت هایی مثل دستگاه ها، سیستم های فایل و فراخوان های سیستمی را به هسته اضافه می کند. ماژول های قابل بارگذاری هسته پسوند ko . دارند و معمولا در دایرکتوری lib/modules/ قرار می گیرند. به دلیل طبیعت ماژولارشان می توان به سادگی هسته را با انتخاب ماژول های قابل بارگذاری یا ممنوع کردن تعدادی از آنها برای بارگذاری سفارشی کرد که هنگام بالا آمدن سیستم از طریق دستور menuconfig یا پس از بالا آمدن سیستم و از طریق فایل boot/config/ می توان این کار را انجام داد. همچنین می توان بدون راه اندازی مجدد سیستم، از طریق دستور modprobe ماژول هایی را به هسته اضافه یا از آن حذف کرد.
در برخی از توزیع های لینوکسی، ماژول های منبع بسته ای وجود دارند که توسط تیم توسعه لینوکس توسعه نیافته اند. مثلا در توزیع اوبونتو، توسعه دهنده های نرم افزاری همچون nvidia و ati به جای ارائه کدمنبع برای قرارگیری در هسته لینوکس، تنها به ارائه فایل های کامپایل شده ko بسنده کرده اند. این ماژول ها البته رایگان هستند و می توان آنها را دریافت کرد ولی قابلیت سفارشی سازی و تغییر ندارند. به همین دلیل در برخی از توزیع های لینوکسی که بسیار به آزادی نرم افزاری معتقد هستند، این نرم افزارها وجود ندارد.
هسته جادو نیست، اما برای هر کامپیوتری لازم است. هسته لینوکس به این دلیل از os x یا ویندوز متفاوت است که درایورهای سخت افزاری در سطح هسته وجود دارد و همه چیز بدون نصب نرم افزار اضافه قابل استفاده است. امیدواریم این مقاله توانسته باشد بخش کوچکی از کاری که هسته لینوکس انجام می دهد را نشان دهد. برای مطالعه بیشتر می توانید به سایت زیر مراجعه کنید:

کد :

http://www.kernel.org

منبع
از مجله رایانه

[Driller]

واقعا مقاله عالی ای بود. تشکر 1000 تا

[bsdlinux]

فایل initrd اغلب به عنوان دیسک های رم استفاده می شوند که فایل اصلی هسته را باز و اجرا می کنند.
فایل system.map برای استفاده در مدیریت حافظه به کار می رود تا زمانی که هسته به طور کامل بارگذاری شود.
فایل config به هسته می گوید که چه گزینه ها و ماژول هایی باید بعد از کامپایل در هسته بارگذاری شود.

آقا دست گلت درد نکنه برای این مقاله خوب و عالی. واقعا مرسی. فقط چند خطای کوچولو وجود داره. initrd به هیچ وجه فایل اصلی هسته رو باز و اجرا نمیکنه بلکه boot loader هم هسته هم initial ramdisk رو در نقطه خاص خودشون در حافظه بارگذاری میکنه و به مدخل start از arch/x86/kernel/head.S یک عمل long jump در حالت real-mode انجام میده. از اونجا یک پرش به مدخل startup_32 از arch/x86/boot/compressed/head_32.S انجام میشه تا بتونه با فراخونی درست تابع decompress_kernel از arch/x86/boot/compressed/misc.c خود کرنل و نه initrd رو باز کنه! در این لحظه هنوز در real-mode هستیم و حالا که کرنل آماده شده تابع start_kernel از init/main.c فراخونی میشه... کل عملیات آماده شدن کرنل از main.c فرماندهی میشه... init/do_mounts_initrd.c تازه اونجا از طرف کرنل initial ramdisk رو میشناسه و وجودشو تشخیص میده و اسمشو الکی میذاره initrd.image و با rd_load_image از do_mounts_rd.c اونو کاندیدای mount شدن میکنه.

کد :

int __init initrd_load(void)
{
        if (mount_initrd) {
                create_dev("/dev/ram", Root_RAM0);
                /*
                 * Load the initrd data into /dev/ram0. Execute it as initrd
                 * unless /dev/ram0 is supposed to be our actual root device,
                 * in that case the ram disk is just set up here, and gets
                 * mounted in the normal path.
                 */
                if (rd_load_image("/initrd.image") && ROOT_DEV != Root_RAM0) {
                        sys_unlink("/initrd.image");
                        handle_initrd();
                        return 1;
                }
        }
        sys_unlink("/initrd.image");
        return 0;
}

اونو با lib/inflate.c باز میکنه و اونو do_mount_root میکنه. وقتی آماده شد run_init_process شروع سیستم رو به init مال داخل ramdisk منتقل میکنه. اگر initial ramdisk توسط bootloader در حافظه قرار داده نشده باشه ولی root= در پارامتر های کرنل وجود داشته باشه کرنل اون root= رو بجای initial ramdisk ماونت میکنه. اگر init= در پارامتر کرنل باشه خیلی خوشگل init_filename میشه اونو اون برنامه بجای init یا linuxrc اجرا میشه.

کد :

static void run_init_process(const char *init_filename)
{
        argv_init[0] = init_filename;
        kernel_execve(init_filename, argv_init, envp_init);
}

خلاصه initrd سوسکه پیش کرنل... بعد آقا یه چیزی: system.map برای مدیریت حافظه بکار نمیره. وقتی linker تمام فایل های .o حاصل از کامپایل شدن .c و اسمبل شدن .S رو لینک میکنه یک جدول از کل متغیر ها و آدرس توابع لینک شده در system.map تشکیل میده. اون موقع اگر یک kernel panic خطای مرگبار در کرنل رخ بده میشه آدرس محل اون خطا (یعنی کدام تابع / ...) و حتی مثلا خطای تقسیم بر صفر روی فلان متغیر رو به اسم اون از داخل فایل system.map ترجمه معکوس کرد و فهمید دقیقا در کجا خطا رخ داده. فکر کنم حتی بدون system.map خیلی خوشگل و نازنازی کرنل کار بکنه... اگر هدف تشخیص خطا نباشه کرنل برای اجرا به system.map نیازی نداره... فایل config هم خیلی ساده یک کپی از همون فایل .config هستش که در دایرکتوری سورس کرنل قبل از کامپایل با دستور make menuconfig ایجاد میشه و علاوه بر اینکه حاوی اطلاعات اینکه کدام ماژول بصورت static داخل هسته لینک شده و کدام ماژول بصورت شیء قابل بارگذاری دینامیکی لینک شده حاوی ریز تمامی تنظیماتی است که توسط make menuconfig انجام شده. البته یک کپی از لیست ماژول هایی که در داخل هسته باید لینک شوند در include/generated/compile.h بداخل کرنل hardcode میشه...

[مهمان]

مثلا در توزیع اوبونتو، توسعه دهنده های نرم افزاری همچون nvidia و ati به جای ارائه کدمنبع برای قرارگیری در هسته لینوکس، تنها به ارائه فایل های کامپایل شده ko بسنده کرده اند.

درایور های nvidia و ati منبع باز هستند و به همراه source code عرضه میشوند و در محل کامپایل می شوند ولی به کاربر حق modification و redistribution رو نمیدهند و آزاد نیستند.