TimTim

سایت خبر خوان

یک ترم OS، هزاران حرف!

جمعه 21 دی 97 | 16:52 - virgool.io - 4
۰. بحث از این‌جا شروع شد که باتوجه به خفن‌تر شدن تی‌ای‌های درس شبکه بر...

۰. بحث از این‌جا شروع شد که باتوجه به خفن‌تر شدن تی‌ای‌های درس شبکه برای ترم بعد، سینا (که تی‌ایِ شبکه‌ست) درباره‌ی وسوسه شدنش برای تغییر دادن توی پروژه‌های درس شبکه به شوخی یه توییتی زد و زیرش غُر زدم که آقا، این روش failئه! :))

و قرار شد درباره‌ی OS و وضعی که بر ما گذشت بنویسم. قرار بود توی ۱ یا ۲ تا توییت جا بشه. اما نشد. تصمیم گرفتم بخاطرش اینجا اکانت بسازم و اینجا بنویسمش. از اواسطش هم دیدم خوبه که یک مقایسه‌ای داشته باشیم وضعیت درس رو در دانشگاه تهران با بقیه‌ی دانشگاه‌ها. و باتوجه به این که پروژه‌های آزمایشگاه از xv6 داده می‌شد، کورس MIT رو برای مقایسه انتخاب کردم.


۱. توی این ترم که OS داشتم، اصلاً لحاظ نشده بود که بچه‌ها باتوجه به الزام‌های چارت، مشکل سنوات و...، مجبور هستن یک‌سری درس‌ها و تعداد بالایی واحد رو توی یک ترم بردارن و فشار روی بچه‌ها زیاد شده بود. تقریباً هر هفته درس یه ددلاین داشت و در کنارِ درس‌های کامپایلر و CAD و سیگنال، همه چیز ریخته بود به هم. (من CAD و سیگنال نداشتم.)

به استاد انتقال دادیم که از دلایل غر زدن بچه‌ها سر درس و درخواست‌های مکرر تمدید پروژه‌ها، این‌هاست. دکتر کارگهی هم علناً سر کلاس گفت ما نمی‌تونیم همه‌ی این موارد رو توی طراحی برنامه‌ی درس دخیل کنیم. که به نظرم خیلی حرفش غیر منطقی بود.

هماهنگی درس‌هایی که بچه‌ها همزمان برمی‌دارنشون به نظرم کم‌ترین کاریه که استاد و تی‌ای اون درس‌ها نیازه که انجام بدن. از نظر زمان و توزیع پروژه‌ها و تنظیم ددلاین‌ها.

البته وقتی همین یک درس OS، ددلاین پروژه‌ی درس و پروژه‌ی آزش توی یک روز، و روزِ قبل از امتحان افتاده بود و به تنهایی حتی مدیریت نشده بود، انتظار هماهنگیش با سایر دروس غیر منطقیه!


۲. استاد معتقد بود درس OS از مهم‌ترین درس‌های مهندسی کامپیوتره (منکرش نیستم) و نیازمند صرف زمان زیادیه. و حرفِ منطقی (جدی) استاد، این بود که «شما باتوجه به این که می‌دونستید وضعیت درس به چه صورته باید بقیه‌ی درس‌هاتون رو بر می‌داشتید که تحت فشار قرار نگیرید.»

ولی خب این هم بر می‌گرده به سنواتِ ۸ (حالا بگیم ۹) ترمه‌ی ما. که دانشجو مجبوره مثل ربات فقط واحد برداره و پاس کنه و نفهمه که چی به خوردش داده می‌شه.

مسلماً کسی با باکیفیت و کامل ارائه شدن درس‌ها مخالفتی نمی‌کنه؛ ولی چپوندن همه چیز توی یک ترم به این بهونه، دیگه ارائه‌ی درس رو از «مناسب بودن» در میاره. مثلاً یه پیشنهاد می‌تونه این باشه که یک‌سری درسِ جزئی‌تر ارائه شه برای تمرکز روی این مسائل. نمی‌دونم؛ شاید این که اسم رسمی این درس «سیستم‌های عامل ۱» هست یه دلیلی داشته. شاید یه «سیستم‌های عامل ۲»یی باید وجود می‌داشته که یک‌سری از این مباحث اون موقع تدریس شن.

حداقل تنها چیزی که مشخصه اینه که تعداد واحدهای درس با اهمیت و حجمش نمی‌خونه. مثلاً بیاین وضعیت MIT رو ببینیم:

در MIT یک دانشجوی کارشناسی علوم و مهندسی کامپیوتر، مجموعاً ۱۸۳ واحد می‌گذرونه. درس Operating Systems Engineering هم ۱۲ واحده. یک دانشجوی کارشناسی مهندسی کامپیوتر دانشگاه تهران باید ۱۴۲ واحد بگذرونه و ۴ واحدش سیستم‌های عامله. اگه تناسب بگیریم با MIT، درس OS ما باید ۹ واحد باشه.

البته این به شرط هم‌تراز بودن سطح کارشونه. که البته نیست!

در MIT کتابی که به عنوان جزوه‌ی درسه، کتاب xv6 هست (در واقع اون سیستم‌عامل داره در طول ترم بررسی می‌شه) و در سشن‌های آزمایشگاه، یک‌سری فیچرهای سیستم‌عامل رو خود بچه‌ها پیاده‌سازی می‌کنن (که فکر نکنم باتوجه به xv6 به مرجع دیگری نیاز داشته باشن). ما به عنوان کتاب مرجع، سیلبرشاتز رو داریم و برای سشن‌های آزمایشگاه، با xv6 روبروییم. هر هومورک MIT در حد ۱ تا ۳ سؤال در سطح سؤال‌های صورت پروژه‌های آزمایشگاه ماست. با این تفاوت که کلی توضیح دارن :)

توی MIT این درس جمعا ۱۹ هومورک (هرکدوم بین ۱ تا ۳ سؤال) و ۶ پروژه‌ی آزمایشگاه براش تعریف شده. اینجا، ۹ هومورک (هرکدوم تقریباً شامل ۲۰ سؤال)، ۵ پروژه‌ی آزمایشگاه و ۳ پروژه‌ی درس داریم. چون کلاً ذات پروژه‌ها و هومورک‌هامون متفاوتن، به نظرم از روی تعداد نمی‌شه قضاوت کرد. بگذریم.


۳. یک مورد دیگه، وضعیت پروژه‌های آزمایشگاهه. توی پروژه‌های آز، از بچه‌ها خواسته شده بود که تست بنویسن برای چیزهایی که نوشتن. که موقع تحویل بشه نشون داد که چه کردیم.

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

یه نگاه به صورت هومورک‌ها و پروژه‌های آزمایشگاه MIT بندازیم. این لینک تقویم درسشونه. مثلاً این صورت یکی از پروژه‌ی آزمایشگاهشونه. یا مثلاً این هومورک با عنوان لاک‌های xv6 هست؛ به عنوان چیزی که شبیه به سؤال‌های توی صورت آزمایش‌های ما هم دیده می‌شه.

این که به دانشجو گفته بشه که باید چیکار کنه و دنبال چی بگرده، واقعاً چیزِ بدی نیست!

این بخشی از صورت پروژه‌ی ۲ آزمایشگاه ماست. پروژه مربوط به «اضافه‌کردن فراخوانی سیستمی»ئه و بعد از ۱۳ صفحه توضیح درباره‌ی فراخوانی‌های سیستمی (که با وجود این که محتوای مفیدی داشت، اما به پیاده‌سازی ما در آزمایش مربوط نمی‌شد)، نوشته برین گوگل کنین. :) این که با خودمون بگیم «دانشجو باید بلد باشه سرچ کنه و راه‌حل‌ها رو خودش پیدا کنه» وقتی وارده که هدف از اون تمرین، همین سرچ کردن و پیدا کردن راه‌حل باشه. چرا باید همه‌ی اهداف ریز و درشت و اصلی و جانبی رو چپوند کنار هم؟

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

اینجا قسمتی از صورت همون پروژه رو ببینید:

تمام توضیحات موجود مربوط به نوشتن این سیستم‌کال رو گذاشتم.

با هومورک سیستم‌کال MIT مقایسه کنین:

Part Two: Date system call

Your second task is to add a new system call to xv6. The main point of the exercise is for you to see some of the different pieces of the system call machinery. Your new system call will get the current UTC time and return it to the user program. You may want to use the helper function, cmostime() (defined in lapic.c), to read the real time clock. date.h contains the definition of the struct rtcdate struct, which you will provide as an argument to cmostime() as a pointer.

You should create a user-level program that calls your new date system call; here's some source you should put in date.c:

#include "types.h"
#include "user.h"
#include "date.h"

int
main(int argc, char *argv[])
{
  struct rtcdate r;
  if (date(&r)) {
    printf(2, "date failed\n");
    exit();
  }
  // your code to print the time in any format you like...
  exit();
}

In order to make your new date program available to run from the xv6 shell, add _date to the UPROGS definition in Makefile.

Your strategy for making a date system call should be to clone all of the pieces of code that are specific to some existing system call, for example the "uptime" system call. You should grep for uptime in all the source files, using grep -n uptime *.[chS].

When you're done, typing date to an xv6 shell prompt should print the current UTC time.

چطور بود؟


۵. این مسئله که «تی‌ای‌های دانشکده‌ی ما در ازای زمانی که می‌ذارند، پول یا هر عاملِ واقعاً ایجادکننده‌ی انگیزه‌ای دریافت نمی‌کنند»، کاملاً دلیل موجهیه برای این که تی‌ای‌های ما مثل MIT وقت و علاقه نذارند. این، مسئله‌ایه که به دانشکده مربوطه و نه به دانشجوها. ولی در نهایت دود این وقت نگذاشتن توی چشم دانشجوهاست که می‌ره.


۶. این ترم و تغییر رویه‌ی درس نظریه! پروژه دادن توش از عجیب‌ترین اتفاقاتیه که می‌تونست برای این درس رخ بده. علت این که استاد درس همچین تصمیمی گرفته، به احتمال ۹۹٪ برمی‌گرده به این که بچه‌ها تا قبل از این، درس نظریه رو «یه درسِ روال و آسون» تصور می‌کردن و باتوجه به فشاری که بقیه‌ی درس‌ها دارن، مهم‌تر جلوه‌کردن اون‌ها برای بچه‌ها و ظرفیت محدود دانشجو، سر کلاسش هم خیلی وقتا نمی‌رفتن و اهمیتی براش قائل نبودن. راه حل استاد چی بود؟ بالا بردن فشار درس روی بچه‌ها و هم‌سطح کردنش با بقیه‌ی درس‌ها!

الآن OS هم مثلِ اون درسِ مهمی هست که تقریباً تمامِ وقت بچه‌ها رو می‌گیره و تأثیراتش رو روی سایر درس‌ها هم می‌ذاره. شاید این که این ترم دکتر صالحی برای درس کَد، ۸ تا پروژه داد بهش بی ربط نباشه.


پایان: حرف دکتر کارگهی کاملاً هم منطقیه که دانشجو نباید در کنار این OS کلی درس دیگه هم برداره (که ۱۸ واحد رو پر کنه.).

حالا راه حل، یا اینه که تعداد واحدهای این درس زیاد بشه، یا فشار ۸-۹ ترمه تموم کردن از سر دانشجو برداشته بشه، یا محتوای درس باتوجه به ۴ واحدی بودنش تنظیم بشه. من موافق آخری نیستم، اما موارد اول و دوم، واقعاً دسترسی دشواری دارن.

نتیجه‌ی تموم این مسائلی که می‌بینین، شده این که از بچه‌ها «ماشین‌های رسوندن پروژه به ددلاین» ساخته شده. امیدوارم انقدری که وضعیت از نظر من وضع افتضاحه، نباشه.


پی‌نوشت ۱: با احترامِ تمام نسبت به تی‌ای‌های درس این متن رو نوشتم و اگه از اسکرین‌شات و بخشی از صحبت‌های تی‌ای‌های درس استفاده کردم، فقط برای نشون دادن ضعف‌های شیوه‌ی ارائه‌ی درس (از نظر خودم) بوده و واقعاً هیچ اعتراضی به شخص تی‌ای‌ها ندارم. خسته هم نباشید. 🙏

پی‌نوشت ۲: اگه هر قضاوتی درباره‌ی MIT کردم، صرفا باتوجه به برداشت‌هام با خوندن صفحه‌ی درسشون بوده و اطلاع مستقیمی از وضعیت اون دانشگاه و اون درس ندارم.

یک ترم OS، هزاران حرف!