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

[Jethro]

Zdravím vespolek,
byli jsme několikrát vyzýváni k tomu, abychom dali zpětnou vazbu, pokud nás
nějaká napadne, píši ji tedy níže. Protože čekám, že by k tomu mohli mít
ostatní komentáře, posílám ji do konference. Psát budu o zápočtu, protože k
přednášce mne už nic nenapadá, o tom jsme se již bavili.

Moje pocity a návrhy k zápočtu jsou následující:

1) Zrušit dokumentaci
OSy jsou předmět velmi náročný na čas a energii, vyžadují množství práce
srovnatelné s bakalářkou a přitom jsou to jen průběžný povinný předmět.
Studenti na nich stráví už jen psaním samotného programu velké množství
času a právě programování je (alespoň podle mého názoru) je to, v čem se
člověk nejvíce naučí. Vzhledem k tomu, kolik je toho potřeba implementovat
a za jak dlouho, si myslím, že valná většina týmů spoléhá na štěstí a
nějaké množství magie, že to všechno dohromady chodí.

Rád bych slyšel názory ostatních na toto téma, já mám pocit, že většina
týmů (obzvláště těch, co systém píší poprvé) systém odevzdává se slovy "už
to nikdy nechci vidět" a také tak koná. Než systém někde dále rozšiřovat
(proč to dělat, když tu jsou jiné lepší) by se hodilo ho celý přepsat s
ohledem na špatná rozhodnutí, která v něm jsou někde hluboko
zakonzervovaná. V takovém případě je psaní dokumentace rovno házení perel
sviním, protože na poslední chvíli (protože to dřív není potřeba) člověk
píše něco, co si po něm někdo jiný přečte nejvýše jednou a pak to už nikdy
nikdo nepoužije.

Dokumentace patří do jiných předmětů, kde je na ni více času (ročníkáč,
softwarový projekt, bakalářka, diplomka, zápočťáky) a dává smysl, protože
studenti tyto práce obvykle píší proto, aby byly posléze někde použity a
nebo to pomohlo ostatním. Tam si psaní dokumentace vyzkouší dostatečně.
Jedny z nejhorších pocitů při psaní byly, když jsem o víkendu před deadline
psal dokumentaci právě z toho důvodu, že jsou za ni body. Během roku na ni
není čas, tam, kde je to potřeba, již komentáře jsou a její učesávání je
nudná mechanická práce která jen bere čas a nic nedává. Obdobně to platí
pro debugovací výpisy, nejlepší pomůckou se nám ukázaly prinkt a //, celá
skvělá marka na debugování per module jsme psali těsně před odevzdáním,
protože člověk by potřeboval ladící výpisy povolovat do hloubky, což ale
nevím, zda jde udělat (=chci sledovat, kudy debugovaná funkce prochází, ale
např. nechci sledovat všechny mutexy, i když jeden z nich funkce používá).

2) Průběžné kontroly a konzultace
Kromě průchodu testy by mi přišlo zajímavé a přínosné (alespoň pro ty,
kteří se se systémovým programováním setkávají poprvé), kdyby si opravující
po každém deadline vyhradili nějaký čas na ruční kontrolu. Podívali by se
na kód a pak se sešli s jednotlivými týmy a konzultovali s nimi právě
proběhlou část, záludnosti, které nebyly pokryty testy (a nebo testy omylem
prošly) a vhodnosti konkrétních způsobů implementace. Z jedné strany je
dobře, že si většinu věcí musíme vymyslet sami, z druhé strany problém
někde hluboko vzniklý chybou návrhu a nalezený při dokončování třetí stage
člověka spíš naštve než posune dál.

3) Upravit deadline
Zde bych měl jen malou poznámku a to, že by se hodilo přidat 4 hodiny za
ztrátu 1 bodu (mezistupeň mezi odevzdám včas a odevzdám o týden později).
Jsem rád, že se deadline prodloužují z vážných důvodů.

4) Upravit bodování
Tento bod souvisí s bodem 1). Myslím si, že kdyby se zrušil bod kvalita
dokumentace a z ní se zachoval jen obecný text (klidně v češtině) se
zajímavostmi implementace konkrétních částí přesunutý do bodu 2), tak se
omezí množství opruzu ve prospěch programování a vylepšování systému. To,
že jsou funkce čitelné, krátké a dobře strukturované mi přijde jako
dostatečný požadavek na kvalitu kódu a množství komentářů by mělo být bráno
jako minoritní kritérium. Alternativně by se mi líbila možnost doplňkové
funkcionality za bonusové body. Rád bych napsal funkční filesystém místo
kopírování definic debugovacích maker z místa na místo.

5) Možnost testování na reálném HW
Kdyby byla možnost dostat kromě simulátoru i nějaký reálný HW (třeba
routerboard), na kterém by Kalisto bylo podporováno, motivovalo by mne to
mnohem více k programování. Nevím, jestli je to snadné, ale myslím, že by
snad možnost nahrát image přes U-boot a mít putc a getc ze sériové konzole
by bohatě stačilo a motivovalo by mne to k psaní mnohem více než pouhý běh
v simulátoru. Podpora reálného HW by měla samozřejmě být volitelná a
případně za bonusové body.

5) Drobnosti pro debugování
Velmi by mne potěšilo několik drobností, které by pomohl v debugování a
člověk si je nemusel psát sám (protože neví, kolik by mu to zabralo a
jestli by se to vyplatilo):
a) trasovací výstup z msimu na stderr - abych to mohl někam přesměrovat a
viděl, jak program běží. Místa, kde se zapisuje na konzoli by byla v trace
vyznačena obdobně jako přerušení
b) funkční diskové zařízení v msimu - když se píše, že můžu použít load a
fmap, tak by měly fungovat obojí, ne že fmap poběží a load nic neudělá a
nestěžuje si.
c) více debugovacích výpisů msimu - když se mi zařízení v paměti
překrývají, tak chci, aby mne praštil přes prsty, ne aby to tiše ignoroval.
Obecně mi chyběla možnost -v, kdy by byl ukecanější a třeba mi řekl, že
soubor neotevře jako disk a proč. Nemyslím si, že zkoumání zdrojáků msimu a
patchování by mělo být součástí OSů.
d) lepší dokumentace k msimu - někde u disku mi občas chyběly jednotky (teď
to nemohu najít), když se tam píše, že sector set, člověk by čekal, že
třeba set bude mít velikost větší než 1. Taky by se hodilo vědět, které
parametry jsou povinné a které ne (když mapuji soubor, musím udávat
velikost disku?)
ad b,c,d) disk dávám za příklad, protože jsem s ním hodně pracoval, s
jinými částmi jen okrajově.
e) převod trace na čitelný text - bohatě by stačil jednoduchý skript,
kterému předhodím trace a kernel.disasm (či jiný vhodnější) a dostanu u
každé instrukce jméno funkce (a případně i souboru), ze které instrukce
pochází.

Tolik to, co mne napadlo v průběhu psaní a doufám, že to pomůže při
budoucích změnách předmětu. Diskusi vítám.
S pozdravem

Tomáš "Jethro" Pokorný
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://d3s.mff.cuni.cz/pipermail/nswi004/attachments/20150319/8aa5d2a3/attachment.html>