[OSy] Zpětná vazba k OSům
Martin Decky
decky at d3s.mff.cuni.cz
Sat Mar 21 20:46:10 CET 2015
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ý
More information about the NSWI004
mailing list