[OSy] Zpětná vazba k OSům

[Martin Decky]

Vážený pane kolego,

děkujeme mnohokrát za Vaši podrobnou zpětnou vazbu. Velmi si toho 
ceníme. Předmět Operační systémy se sice v současné formě letos vyučuje 
nejspíš naposledy, ale i pro přípravu nové koncepce se nám Vaše 
komentáře budou hodit.

Dovolte mi, abych k Vašim připomínkám přidal několik svých osobních 
komentářů.


Ad "zrušit dokumentaci"
-----------------------
Na jednu stranu pochopitelně Vašemu sentimentu rozumím, protože je 
jasné, že jen naprosté minimum absolventů OSů se někdy ke své 
semestrálce někdy vrátí. Na druhou stranu, snažíme se, aby se 
implementace semestrálky co nejvíce podobala reálnému softwarovému 
projektu v reálném světě. Myslím si, ze drtivá většina vývojových 
metodologií stále ještě tvorbu dokumentace v té či oné formě vyžaduje, 
byť některé agilní metodiky staví funkční software nad podrobnou 
dokumentaci a upřednostňují "lean documentation".

Myslím si, že "lean documentation" je i cílem dokumentace semestrálky z 
OSů. Rozhodně nám nejde o to, aby každá skupina napsala 50-stránkový 
manuál, který bude zároveň sloužit jako malá učebnice principů 
operačních systémů. Dokonce ani nepožadujeme dokonalou referenční 
dokumentaci na úrovni podrobnosti Win32 API nebo Java SE API.

Ideální dokumentace k semestrálce z OSů by měla obsahovat především 
popis architektury celé semestrálky (ideálně v nějaké standardní notaci, 
např. UML), popis datových struktur (opět ideálně s vhodnými diagramy), 
slovní komentář k některým méně triviálním algoritmům a především odkazy 
na to, kde se co v kódu najde. Taková dokumentace skutečně výrazně 
usnadní i naše hodnocení semestrálky, protože nám třeba pomůže odlišit, 
co v implementaci je zámer a co je jen hack.

Problém, na který sám narážíte, je ten, že většina lidí má ve zvyku psát 
dokumentaci až po implementaci a to typicky na poslední chvíli. To je 
ovšem dost špatný postup, který skutečně často vede jen k frustraci nad 
tím, že to je jen jakási formální a zbytečná činnost. Ve skutečnosti by 
některé zásadní části dokumentace (jako třeba popis architektury v UML 
nebo popis datových struktur) měly vznikat už během implementace, ne-li 
dokonce před samotným psaním kódu. Takový přístup k "lean documentation" 
může pomoci architekturu i implementaci softwaru lépe navrhnout, protože 
si člověk může předem ujasnit, jaké stavební bloky bude vlastně 
potřebovat a jak by měly být poskládány dohromady.

A poslední, zcela pragmatická poznámka: Kvalitu dokumentace hodnotíme ze 
všech kritérií zdaleke nejmírněji (právě i s přihlédnutím k tomu, že OSy 
skutečně nejsou předmět, kde by se studenti měli primárně učit psát 
dokumentaci). Prakticky si nepamatuji, že by někdy nějaká skupina za 
alespoň nějaký pokus o dokumentaci (byť celkem mizerný) dostala méně než 
5 bodů. Takže lze říci, že to jsou takové celkem jisté body i za poměrně 
malou snahu :)


Ad "debuggovací výpisy"
-----------------------
Tímto bodem narážíte na to, že otázka observability a ladění operačního 
systému (nebo obecně libovolného netriviálně složitého softwaru) je sama 
o sobě docela netriviální. Jinak by neexistovaly projekty typu DTrace 
nebo SystemTap a obecně by se problematikou vhodného způsobu logování 
nezabývaly celé frameworky nebo dokonce celé vývojové technologie (např. 
aspektově-orientovaný vývoj).

Protože je zadání semestrálky z OSů už tak docela obsáhlé (a to je na 
druhou stranu ohlodané až na kost), rozhodně ho nechceme komplikovat 
ještě nějakým složitým mechanismem pro ladění. A koneckonců ve spoustě 
případů je skutečně ad hoc použití printk() celkem dobrá pomůcka při 
ladění konkrétních problémů. Při odevzdání jenom chceme, aby ve 
zdrojácích nezbyly zakomentované ladící výpisy, což se dá udělat v 
podstatě i automaticky.


Ad "rucni průběžná kontrola"
----------------------------
V ideálním světě bych s Vašim návrhem plně souhlasil. Dokonce bych zašel 
ještě dál a chtěl bych dělat code review třeba po každém týdnu nebo 
větším mergi.

Bohužel v ideálním světě nežijeme a tak častou zpětnou vazbu si prostě 
nedovedu v praxi z časových důvodů představit. Navíc by to byla 
dvousečná zbraň: Zatímco současný systém umožňuje skupinám v krajním 
případě projít průběžnými testy s dost "ohackovaným", ne příliš 
elegantním nebo ne přiliš efektivním řešením, které mohou poté 
vylepšovat, Vámi navrhovaný systém by pravděpodobně vynucoval mnohem 
vyšší laťku hned na začátku a to by možná některé skupiny zabilo.

Na druhou stranu, není myslím pravda, že by skupiny neměly podle čeho 
implementaci navrhovat -- pořád ještě existuje také přednáška, vždy jsme 
nabízeli možnost individuálních nebo skupinových konzultací atd.


Ad "upravit deadline"
---------------------
Tohle je asi vysloveně věc názoru. Osobně mi příjde, že systém "1 bod za 
4 hodiny" psychologicky nedostatečně odrazuje od odkládání věci na 
poslední chvíli.


Ad "upravit bodování"
---------------------
V tomhle bodě mám vysloveně pocit, že navrhujete něco, co dávno 
existuje. Množství komentářů nikdy nebylo kritériem, vždy hodnotíme 
kvalitu a učelnost komentářů (viz můj komentář o dokumentaci výše).

Bonusové body za doplňkovou funcionalitu nad rámec zadání udělujeme a od 
prvního cvičení k tomu skupiny motivujeme.


Ad "testování na reálném HW"
----------------------------
To, že semestrálku z OSů lze celkem bez velkých problémů rozchodit na 
reálném HW, ukázala letos skupina Boková-Pelikán-Vinárek. Takže i v 
případě tohoto bodu trochu nechápu, co konkrétně navrhujete, protože 
takové iniciativě jsme nikdy nebránili (a samozřejmě ji po zásluze 
ohodnotíme bonusovými body).

Chcete, abychom testování semestrálky na reálném HW požadovali přímo v 
zadání? To by mi nepřišlo šťastné, protože prostředí MSIMu má oproti 
skutenému HW řadu výhod -- chová se deterministicky, je jednodušší 
(neimplementuje cache, nevyžaduje složitou inicializaci a interakci s 
firmwarem), mnohem více odpoušti a umožňuje mnohem snadnější ladění (i 
pro extrémní ladění nevyžaduje JTAG, ale stačí změnit zdroják MSIMu).

Nebo navrhujete, aby všechny skupiny od nás dostaly vhodný HW? Takovému 
požadavku bych docela rozuměl, přecejen procesory MIPS nejsou tak 
všudypřítomné jaké třeba ARM. Aktuálně tolik vývojových desek s MIPSem 
nemáme, ale jistě můžeme uvažovat o jejich pořízení.

Škoda, že jste toto přání neprojevil dřív. Minimálně jeden RouterBoard k 
případnému zapůjčení máme.


Ad "drobnosti pro debuggování"
------------------------------
Díky za návrhy, většinu z nich jistě můžeme implementovat, pokud nám to 
čas dovolí.

Přesměrování: Možná by i v současné verzi MSIMu mohlo pomoci přesměrovat 
výstup zařízení dprinter třeba do pojmenované roury (metoda "redir") a 
potom zpracovávat trace na stdout.

Disk a load; Úplně nerozumím, v čem by měl být problém. Na zařízení 
ddisk metoda "load" funguje, pokud je disk nejprve inicializován metodou 
"generic" na vhodnou velikost (podobně jako v případě paměti). Ovšem 
přiznávám, že by dodatečná chybová hláška u "load" neuškodila.

Verbose MSIM, lepší dokumentace MSIM: Ano. Vývojová verze MSIMu [1] 
obsahuje celou řadu podobných vylepšení. To neupozorňování na překryv 
paměti bylo zřejmě motivováno tím, že reálný hardware Vás při konfliktu 
dekódovaných fyzických adres také neupozorní. Ale chápu, že takové 
vysvětlení nemusí být úplně uspokojující :)

Převod trace: Je otázka, jestli je skutečně nutné, aby takový skript byl 
součástí distribuce MSIMu. Věřím, že to je něco, co by člověk v případě 
potřeby dokázal spíchnout za pár minut třeba v Pythonu. Další otázka je, 
jestli v případě takové potřeby není lepší sáhnout k plnohodnotnému 
debuggeru jako je gdb nebo dokonce k nějaké jeho grafické nádstavbě.


Každopádně ještě jednou díky za Vaše komentáře. I když v některých 
případech s Vámi možná nemohu 100% souhlasit, i tak je pro nás Vaše 
zpětná vazba cenná -- minimálně nám říká, které věci máme lépe komunikovat.


[1] http://d3s.mff.cuni.cz/~holub/sw/msim/


S pozdravem

Martin Děcký