[OSy] Shrnuti OSu 2010/2011

[Martin Decky]

Vazeni kolegove,

rad bych se s Vami podelil o zaverecne shrnuti semestralnich praci z OSu 
2010/2011. Zamerne toto shrnuti posilam jiz v dalsim semestru a to 
proto, aby se studenti, kteri maji predmet zapsan (nebo o tom uvazuji) v 
akademickem roce 2011/2012, mohli poucit z nejcastejsich potizi v 
minulem roce.


Organizacni poznamka
====================
Po tomto emailu budou z mailing listu hromadne odhlaseni studenti, kteri 
meli predmet zapsan loni (prijde Vam o tom informacni email). Pokud si z 
libovolneho duvodu prejete v mailing listu OSu zustat i nadale, muzete 
se samozrejme opetovne prihlasit.

Lonsti studenti budou pote hromadne prihlaseni do mailing listu 
Alumni-Announce, Alumni-Chat a Alumni-Offers, coz jsou minimal-traffic 
konference, ktere slouzi k tomu, abychom mohli zustat i po absolvovani 
predmetu nasi katedry v kontaktu. Pokud si neprejete v techto listech 
byt (ve vsech nebo v kteremkoliv konkretnim), opet Vam samozrejme nic 
nebrani odhlasit se. Strucna charakteristika:

Alumni-Announce -- moderovana konference pro ruzna skolni oznameni
                    (nove predmety, zmeny studijnich planu apod.)
Alumni-Char     -- otevrena nemoderovana chatovaci konference
Alumni-Offers   -- moderovana konference pro mimoskolni a komercni
                    nabidky (snazime se poustet jen konkretni relevantni
                    nabidky, ne HR agentury a spam)


Shrnuti semestralek 2010/2011
=============================
Z celkoveho poctu deseti lonskych skupin se dvema skupinam podarilo 
dosahnout plneho poctu bodu (30), coz je jiste vysledek hodny oceneni. 
Take se po delsi dobe podarilo uspesne odevzdat dve vyberova zadani 
(implementace driveru souboroveho systemu ISO 9660 pro HelenOS a ovladac 
CAN sbernice pro BeagleBoard). Prumerne hodnoceni semestralek bylo 23,1 
bodu a vsichni studenti, kteri semestralku dokoncili, take ziskali 
celkovou znamku z predmetu (tedy lepsi nez 4 :)).

Nejcastejsi vytky v hodnoceni semestralek byly tyto:


1) Zadne nebo nedostatecne testovani argumentu systemovych volani
-----------------------------------------------------------------

Nesvar, ktery se objevoval bohuzel i u jinak bezproblemovych skupin. 
Jeden z hlavnich duvodu rozdeleni operacniho systemu na jadro a 
uzivatelske procesy je prave "opevneni" nejkritictejsich casti celeho 
softwaroveho stacku pred zamernymi i nahodilymi chybami jednotlivych 
procesu. Bez tohoto "opevneni" by v mnoha pripadech davalo mnohem vetsi 
smysl mit pouze jeden rezim procesoru, zapomenout na komplikovane 
rozdeleni kernel/uspace a usetrit tak na overheadu systemovych volani. 
Systemova volani predstavuji vstupni branu z "nebezpecneho sveta" 
uzivatelskeho prostoru do "bezpecneho sveta" kernelu a jako takova musi 
byt nalezite ochranena.

Neni proto dost dobre mozne predavat pomoci systemoveho volani nejaky 
ukazatel na datovou strukturu a ten potom v kernelu bezelstne 
dereferencovat, aniz by si kernel vubec overil, zda ukazatel miri na 
dostatecne velkou a spravne namapovanou pamet procesu (a ne napriklad 
nekam do kernelove pameti, kde se tak muze neco prepsat, nebo na 
nenamapovanou pamet, coz pri naslednem pristupu zpusobi pad celeho kernelu).

I pokud tento zakladni test provedete, stale to nestaci k tomu, aby bylo 
mozne verit, ze datova struktura s kernelovymi daty ulozena v 
uzivatelskem prostoru obsahuje konzistentni zaznamy, se kterymi 
uzivatelsky proces zamerne/nahodne nejak nemanipuloval. Mimochodem, 
porovnani nejake magic hodnoty sice vypada na prvni pohled jako 
dostatecne reseni, ale skutecnou konzistenci cele struktury to stale 
nezarucuje.

Jeden z mala temer neprustrelnych zpusobu ochrany pred temito problemy 
je predavat do uzivatelskeho prostoru pouze ciselne identifikatory 
(handlery) kernelovych dat. Je-li to jen trochu mozne, tak by tyto 
handlery mely zit v izolovanem jmennem prostoru pro kazdy proces 
(alternativne je mozne overovat spravneho vlastnika handleru) a mely by 
byt unikatni v case.


2) Omezeni poctu adresovych prostoru konstantou
-----------------------------------------------

Polovina skupin si velmi zjednodusila praci na memory managementu tim, 
ze vubec neresila otazku vhodneho pridelovani ASIDu, existuje-li v 
systemu v jeden okamzik vice nez 254 adresovych prostoru. V nekterych 
pripadech byl proste pocet adresovych prostoru omezen konstantou (nekdy 
dokonce ne jen pro jeden okamzik, ale celkove). V jinych pripadech byl 
pro nektere nebo vsechny adresove prostory vyhrazen jeden spolecny ASID, 
coz nutne vedlo k nutnosti delat kompletni TLB flush pri kazde zmene 
adresoveho prostoru (a tedy k netrivialnimu zpomaleni celeho systemu).

Pridelovani ASIDu adresovym prostorum je typicky problem dobre resitelny 
napriklad algoritmem LRU. Jedna se o reprezentanta dulezite tridy uloh, 
ktere se v operacnich systemech resi, a proto trvame na poctivem reseni. 
Zakladni zadani sice hovori o tom, ze lze omezit pocet oblasti v kazdem 
adresovem prostoru konstantnou, ale pocet adresovych prostoru jako 
takovych (stejne jako treba pocet vlaken) by mel byt omezen pouze 
aktualne dostupnou pameti.


3) Coding style
---------------

V pripade jednoclennych projektu nemusi byt dodrzovani coding style tak 
zasadni problem, ale u tymove prace rozsahu semestralky z OSu uz bylo 
patrne, ze neprehlednost zdrojaku vyrazne rostla prave tam, kde byly v 
implementaci nejvetsi problemy. Obzvlaste neprijemny pohled byl na 
soubory doslova "zablesene" zakomentovanym mrtvym kodem, ktery mozna 
nekdy k necemu byl (treba pro ladeni nebo prototypovani), ale aktualne 
uz k nicemu neslouzil a jen stal v ceste.

Pochopitelne nelze obecne rici, ze by subjektivne horsi esteticke 
kvality zdrojaku nutne vedly k vetsimu poctu chyb, ale neprehledne 
zdrojove kody urcite zpusobuji, ze se chyby hure hledaji. Zatimco krasne 
upraveny, opticky prehledny a na prvni pohled pochopitelny zdrojak 
(kratke "samovysvetlujici" funkce, rozumne popisne nazvy promennych, 
dodrzovani jmennych konvenci atd.) se snadno cte a snadno se o nem 
rozhoduje, zda je spravne, hledani chyb v neprehlednem zdrojaku muze 
doslova vypadat jako "hledani jehly v kupce sena".


4) Provazanost referencni a rucne psane dokumentace
---------------------------------------------------

Prestoze uroven rucne psane i referenci dokumentace byla opravdu velmi 
ruznoroda, i kvalitni dokumentace casto postradala lepsi provazanost 
obou slozek -- jako by se rucne psana i referencni dokumentace vubec 
netykala stejneho projektu. Pritom neni nic snazsiho nez vyuzit 
hypertextovych odkazu a z high-level popisu v rucne psane dokumentaci 
ctenare odkazat na konkretni mista v referencni dokumentaci, kde si muze 
precist, jak vypada programatorske API a dalsi low-level podrobnosti.

Pri generovani referencni dokumentace take neni prilis dobry napad 
pustit Doxygen nebo podobny nastroj na kernelove i uspace zdrojaky 
dohromady. Tyto dokumentacni nastroje jsou totiz vetsinou navrzeny pro 
praci s jednim ucelenym projektem a logicke rozdeleni kernel/uspace 
prilis "nechapou" (nota bene pokud se v kernelu i uspace pouzivaji 
stejne pojmenovane funkce, hlavickove soubory apod., pokazde vsak 
implementovane jinak a jinde). Mit samostatnou referencni dokumentaci 
pro kernel a uspace je rozhodne lepsi a pritom trivialni reseni.


M.D.