سیستم عامل کوثر

سیستم عامل فارسی کوثر

سیستم عامل کوثر

سیستم عامل فارسی کوثر

سیستم عامل کوثر

سیستم عامل کوثر یک سیستم عامل فارسی بر پایه معماری X86 می باشد. هدف این سیستم عامل تا اطلاع ثانوی آزمایشی / آموزشی می باشد. این سیستم عامل بر پایه هیچ سیستم عامل دیگری مانند لینوکس و ... نمی باشد و از ابتدا توسط توسعه دهندگان آن نوشته شده است.
ما از علاقمندان به برنامه نویسی و طراحی سیستم در همکاری و توسعه این سیستم عامل استقبال می کنیم. نیازی نیست که شما برنامه نویسی و یا ... خبره باشید. حتی با دانش کم هم می توان به ما کمک کرد.
امید است بعد از مراحل آموزشی به مرحله بهره برداری از یک سیستم عامل کاملا بومی برسیم.
emadrezvani@chmail.ir

بایگانی
آخرین نظرات
نویسندگان

هسته - اداره وظایف (ایجاد و همزمانی)

مازیار نون | دوشنبه, ۲۰ مرداد ۱۳۹۳، ۰۳:۴۷ ب.ظ

سلام

قصد دارم در این پست و شاید پست های بعدی به مسائل اداره کردن وظایف توسط هسته در یک محیط چندبرنامه ای یک توضیح مختصر و مفید انجام دهم.

در ابتدا به منظور اجرای تمام وظایف (فرآیندها) توسط سیستم عامل ، این را باید در نظر بگیریم که با هر مدل هسته ای به طور کلی ، اداره کردن وظایف بر عهده هسته خواهد بود. پس در این پست من یک دید کلی از یک بخش از اداره کردن وظایف توسط هسته را ارائه می دهم. هر وظیفه شامل کد و داده ها است که در واقع قبل از بکارگیری آن بر روی دیسک سخت کامپیوتر ذخیره شده است.

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


از دید سیستم عامل هسته باید ابتدا بعد از یک وقفه ، PCB فرآیند (وظیفه) را در حافظه اصلی ایجاد کند و قبل از آنکه فرآیند در حافظه اصلی قرار گیرد باید روال ایجاد تصویر فرآیند نیز صورت گیرد. و بعد با زمانبندی و فراخوانی برنامه توزیع کننده این فرآیند به پردازنده برای اجرا تحویل داده شود بعد از اتمام کار فرآیند ، هسته مسئول خارج کردن فرآیند از حافظه اصلی است.

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

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

در مورد ایجاد وظایف پستی در این مورد برای ایجاد فرآیندها در این وبلاگ وجود دارد. اما ایجاد وظیفه فعال دارای یک ساختمان داده است که متشکل از بخش های مختلف می باشد. و هر بخش باید به طور کامل و مبتنی بر مدل حیات فرآیند طراحی شود.

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

در راستای اجرای فرآیندها شما باید در سیستمی که مبتنی چندبرنامگی است باید زمانبند تعریف کنید. اما بعضی از الگوریتم های زمانبندی برای بهتر اجرا شدن نیازمند یک تمایز بین فرآیندها هستند. به عنوان مثال لازم است یا پیشنهاد می شود که برای فرآیندها یک اولویت تعریف کنید. با بکارگیری اولویت و خود الگوریتم زمانبندی می تواند بهره وری بهتری برای سیستم برسید. در بکارگیری سیستم های مبتنی بر اولویت شما می توانید از صف یا لیست پیوندی برای کاهش دادن اولویت ها مبتنی بر شرایط فعلی سیستم استفاده کنید. در این صف شما اولویت یک فرآیند را براساس شرایط فعلی سیستم محاسبه می کنید. در بعضی از روش های قدیمی از صف های چند سطحی استفاده می کنند به این صورت که هر صف مبتنی بر الگوریتمی مانند RR است و صف آخر را مبتنی بر الگوریتم FIFO طراحی می کنند. به این ترتیب هر فرآیندی اگر به اتمام نرسید به صف های پایین تر می رود تا به اتمام برسد.


نکته: کلمات وظایف ، فرآیندها در اینجا یک معنی دارند.

با تشکر

تیم سیستم عامل کوثر

  • مازیار نون

علت تاخیر در انتشار و زمان انتشار نسخه جدید

عماد رضوانی | دوشنبه, ۲۰ مرداد ۱۳۹۳، ۰۹:۵۲ ق.ظ
السلام علیکم ورحمة الله وبرکاته.
بابت وقفه بوجود آمده در بروز رسانی وبلاگ پوزش می طلبیم. چند روزیست که مشغله کاری ما زیاد شده و کمتر وقت بر روی بروز رسانی هسته گذاشتیم. اما با این حال بیکار نبودیم و در حال اضافه کردن قابلیت و ایده های جدید به هسته هستیم. مثلا راه اندازی هسته(یا به اصتلاح پورت کردن هسته) به روی AVR و X86  و  Windows(منظور راه اندازی بدون مجازی ساز و سخت افزار هست که بعدا بحث خواهیم کرد).

نکته بعدی در مورد درخواست هایی هست که دوستان جهت همکاری با ما داده اند که باید عرض کنم تا زمان ارائه پورتال و SDK منتظر بمانید.

و نهایتا از دوستان عزیزی که با وجود کمتر بروز شدن وبلاگ به ما سر میزنند کمال تشکر رو داریم و انشاا.. در ماه آینده نسخه جدید انتشار خواهیم داد.

و من الله توفیق.

  • عماد رضوانی

معماری سیستم عامل - مدل ها و هسته ها - بخش سوم

مازیار نون | سه شنبه, ۷ مرداد ۱۳۹۳، ۰۸:۲۳ ق.ظ

سلام

در ادامه مباحث مربوط به معماری سیستم عامل ها امروز به بحث هسته ها از دید دیگری نگاه می کنیم.

مدل های که تا امروز مطرح شدند هرکدام معایب و مزایای خاص خود را دارند. لذا برخی از سیستم عامل ها مدل های هسته خاص خود را دارند. اما پیروی از مدل هسته های مشهور می تواند به ما در طراحی مولفه ها و برنامه ریزی برای ارتباط مولفه ها و کنترل آنها کمک کند. هر مدل برای خود براساس ساختار خاص طراحی شده است از این جهت دست ما برای تغییرات اساسی و برنامه ریزی در زمان طراحی معماری سیستم عامل باز است.

وجود هسته در واقع به این دلیل بود که مرکز محاسباتی برای سیستم عامل طراحی شود. در این مرکز محاسبات کلیه وظایف سیستم عامل مانند یک سازمان انجام می شود. کل مولفه هایی که در این قسمت قرار دارد باید توسط سیستم عامل کنترل شوند. اما سوالی که مطرح می شود این است که تا چه حد سیستم عامل درگیر عملیات درون هسته باشد؟

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

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

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


  • مازیار نون

الگوریتم های زمانبندی - راهکار کارایی برای سیستم

مازیار نون | دوشنبه, ۶ مرداد ۱۳۹۳، ۰۱:۴۹ ق.ظ

سلام

در این پست می خواهم در مورد یکی از جنبه های مهم در انتخاب مدل زمانبندی بحث کنم که معمولاً در بسیاری از سیستم عامل های غیر رسمی و شبه سیستم عامل ها آنرا در نظر نمی گیرند.

انتخاب مدل زمانبندی فقط به این موضوع بستگی ندارد که باید تنها یک سیاست انتخاب وظیفه برای سیستم عامل در نظر گرفته شود. بلکه این الگوریتم های مشهور که بسیاری از آنها را ما می شناسیم فقط به عنوان یک پایه برای طراحی الگوریتم های بهتر است. به عنوان مثال در یک سیستم عامل نمی شود فقط از الگوریتم RR استفاده کرد به این دلیل که مثلاً گاهاً مدل انتخاب آن براساس تقسیم بندی زمانی (نوعی عدالت خاص) است و این دلیل خوبی برای یک طراح سیستم عامل نیست.

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

فرآیندها و نخ ها سخت با منابع درگیر هستند و در مسئله همزمانی گاهی در دسترسی به منابع بین آنها مسابقه (Race condition) راه می افتد و در بیشتر مواقع باعث ترافیک و در نهایت به بن بست می رسد.

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

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

در یک نتیجه گیری این را خواستم بگویم که در انتخاب روش های زمانبندی باید خیلی دقت کرد. همچنین در استفاده از هم زمانی نیز باید توجه داشت که می توان از رویکرد حسابداری برای سیستم در برنام ریزی برای عملیات بعدی سیستم استفاده کرد و کارایی سیستم را در عملیات بعدی سیستم تغییر داد.


  • مازیار نون

حمایت از مردم مظلوم غزه

عماد رضوانی | جمعه, ۳ مرداد ۱۳۹۳، ۱۱:۰۸ ق.ظ

  • عماد رضوانی

پیشرفت در MultiTasking

عماد رضوانی | سه شنبه, ۲۴ تیر ۱۳۹۳، ۰۲:۵۰ ب.ظ

تصاویر گویای پیشرفت کار هست. مبحث Multitasking بسیار گسترده هست و خیلی از اجزای سازنده هسته رو تحت تاثیر قرار میده. برای شروع ما فقط قصد نحوه راه اندازی پایه ساختار Multitasking رو خواهیم داشت و هنوز ساختار خاصی برای هسته جدید در نظر نگرفتیم!


  • عماد رضوانی

هسته جدید و پیشرفت در Multitasking

عماد رضوانی | شنبه, ۲۱ تیر ۱۳۹۳، ۱۰:۳۹ ب.ظ

سلام. بلاخره شروع به نوشتن هسته جدید کردیم. تصویر اول نمایانگر بازنویسی هسته جدید با نسخه 2.0.0(به دلیل اینکه نسخه ۱ ادامه نسخه قبل خواهد بود-نسخه قبل عملکرد یکپارچه داشت-اگر چه این نسخه مقدار کمی تفاوت دارد)  هست. تصویر دوم نمایانگر Multitasking هست. حتما به مقادیر EIP دقت کنید(ویرایش: مقادیر EIP نباید بصورت منفی باشد - مشکل در قسمت نمایش مقدار در تابع itoa بود که حل شده):


  • عماد رضوانی

معماری سیستم عامل - مدل ها و هسته ها - بخش دوم

مازیار نون | شنبه, ۲۱ تیر ۱۳۹۳، ۱۲:۲۴ ب.ظ

سلام

در ادامه مطالب اجازه بدید یک نتیجه جزئی از مطالب قبلی داشته باشیم پس دو موضوع امنیت (قابلیت اطمینان) و عملکرد (هدف) در این زمینه بسیار مهم هستند. اما این مسائل چقدر می تواند در کاهش پیچدگی تاثیر داشته باشند. اجازه دهید مثالی داشته باشیم ، شما اگر یک مدل هسته انتخاب کنید که مثلاً کل مولفه ها یا بیشترین مولفه ها باید در سطح هسته پیاده سازی شوند به نظر شما چقدر پیچیدگی وجود دارد؟ از طرف دیگر اگر مدل هسته شما به صورتی باشد که بیشتر مولفه ها در سطح کاربر پیاده سازی شوند ، خوب شما باید قابلیت اطمینان را با توجه به هدف (نوع سیستم عامل) در سطح هسته پیاده سازی کنید این قابلیت اطمینان تا چه حد با بروز رسانی های شما بزرگ و پیچیده می شود؟

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

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

مسئله بعدی این است که آیا این رویکردها تاثیری در کارایی سیستم دارد. کارایی معیار مهمی است که باید در نظر گرفته شود. این معیار را می توان در درصد پر کار بودن مولفه های سطح کاربر در نظر گرفت.اینکه تا چه حد باید اعمال هسته در سطح کاربر صورت گیرد و این بکارگیری آیا تاثیر در محاسبات دارد؟

این مطلب ادامه دارد...


  • مازیار نون

معماری سیستم عامل - مدل ها و هسته ها - بخش اول

مازیار نون | شنبه, ۲۱ تیر ۱۳۹۳، ۱۱:۴۹ ق.ظ

سلام

در طراحی سیستم عامل ، دو گام ابتدایی وجود دارد که شامل انتخاب هسته از بین هسته های موجود ، طراحی معماری سیستم عامل براساس هدف سیستم عامل است. این دو گام به ما در طراحی و برنامه ریزی بخش های درونی و بیرونی نرم افزار کمک می کند.بر همین اساس امروز می خوام کمی در مورد این دو گام اساسی و ابتدایی در طراحی سیستم عامل صحبت کنم.

اولین گام در طراحی سیستم عامل انتخاب هسته است همانطور که بالا ذکر شد. اما این انتخاب باید چگونه انجام شود؟

هنگامیکه شما می خواهید یک نرم افزار کاربردی طراحی کنید در واقع قبل از آن صورت مسئله (هدف) برای شما معین است. این هدف به شما مواردی همچون ، نیازمندی های ذینعفان سیستم ، نیازمندی های محیطی ، امنیتی و ... می گوید. به طور کلی با صورت مسئله شما شروع به برنامه ریزی برای طراحی یک نرم افزار خوب می کنید.

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

البته ، در این سال ها بسیاری از طراحی ها یکپارچه شده اند یعنی انتخاب هسته برای هر هدفی کاری دشواری است و منطقی نیست از این جهت هسته ها در طراحی سیستم عامل آنچنان تاثیری نداشتند. و این تبدیل به حرکت به سمت طراحی معماری سیستم شد که بتوان از آنجا تاثیرات را دریافت کرد.

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

با بوجود آمدن تکنولوژی های متعددی در برنامه نویسی و ساختار دهی سیستم مانند شی گرائی و ماژولار ، باعث شد که تاثیر مهمی بر طراحی سیستم عامل بگذارد از این جهت سیستم عامل ها به صورت لایه ای ساخته شدند و در آن مولفه هایی قرار دارد که هریک فعالیت و عملکرد خاصی را برای سیستم عامل فراهم می کند که این باعث انتزاع بیشتری در سیستم می شود. به این ترتیب مولفه ها می توانند با یکدیگر محاوره داشته باشند به عنوان مثال ، مولفه memory manager با مولفه file manager. این محاوره به نوعی مانند ارتباط اشیاء در جهان واقعی و در مفهوم شی گرایی است. به این صورت که درخواست ها از طریق پیام هایی به یکدیگر فرستاده می شوند.و در نتیجه باعث تجرید مولفه های از یکدیگر می شود.

معماری هسته باعث تقسیم شدن به دو بخش مجزا شد: حالت کاربر و حالت هسته. این دو حالت هر کدام براساس معماری هسته بار مختلفی را به دوش می کشند. به همین خاطر لازم است که هدف سیستم عامل که در بالا ذکر کردم در اینجا تاثیر داشته باشد به عنوان مثال آیا file manager در حالت کاربر باشد یا در حالت هسته؟ به مواردی همچون قابلیت اطمینان فعالیت های برنامه های برنامه کاربر بستگی دارد.مثلاً اگر سیستم عامل برای محیط های توزیعی است ممکن است یک بدافزار تاثیر زیادی روی این مولفه داشته و مسائلی مانند قابلیت اطمینان را تحت شعاع قرار دهد. البته این را هم اضافه کنم که می توان با داشتن این مولفه در سیستم عامل های توزیعی و حتی با وجود بدافزار بدون مشکل جلو رفت ، ولی باید قابلیت اطمینان را نیز در نظر گرفت ، چرا که هرچه نرم افزار گسترش یابد بزرگتر می شود و قابلیت اطمینان در آن کمتر و یا اداره کردن آن مشکل تر خواهد شد.

پس این سوال ممکن است مطرح شود که آیا لازم است که بین مولفه های سطح کاربر و سطح هسته تفاوت قائل شد؟ و این ارتباطات چه تاثیری می تواند داشته باشد؟

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

این مطلب ادامه دارد...

  • مازیار نون

Multitasking و شروع دوباره

عماد رضوانی | جمعه, ۲۰ تیر ۱۳۹۳، ۰۲:۵۰ ب.ظ

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

احتمالا دیگه بروزرسانی هسته فعلی رو نداشته باشیم. هسته فعلی بصورت یکپارچه طراحی شده بود.تصویر زیر برگرفته از ویکی هست که تفاوت چند نوع هسته رو نشون میده:



بزودی شروع به توسعه هسته جدید میکنیم. تا اون موقع در حال بررسی معماری های هسته و انتخاب یک مدل برای توسعه هستیم. برای انتخاب یک مدل باید موارد زیادی رو مد نظر قرار داد. در انتشار جدید حتما خبرهای خوبی از SDK خواهید شنید.

التماس دعا.


  • عماد رضوانی