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

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

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

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

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

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

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

۵ مطلب در مرداد ۱۳۹۳ ثبت شده است

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

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

سلام

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

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

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


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

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

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

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

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

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


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

با تشکر

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

  • مازیار نون

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

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

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

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

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

  • عماد رضوانی

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

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

سلام

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

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

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

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

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

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


  • مازیار نون

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

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

سلام

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

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

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

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

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

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

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


  • مازیار نون

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

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

  • عماد رضوانی