[OSy] Hodnoceni OSu

[Martin Decky]

Vazeni kolegove,

zhruba polovina skupin jiz obdrzela hodnoceni sve semestralni prace
z OSu, zbyle skupiny jiz mame take ohodnocene, zbyva jen hodnoceni 
rozeslat. Vzhledem k tomu, v jak dlouhem casovem intervalu hodnoceni 
probihalo, tak se mohlo ojedinele stat, ze jsme prehledli nejakou 
skutecnost, na ktere jsme se napriklad ustne domlouvali pri odevzdani.
V takovem pripade se samozrejme ozvete.

Obecne jsme se snazili neohybat pravidla nastavena jiz na zacatku 
semestru, tedy doplneni semestralky po datu odevzdani jsme akceptovali 
jen v pripade chybejicich casti dokumentace ci drobnych oprav (nektere 
skupiny mely tendenci za drobnou opravu vydavat i pomerne razantni 
prepsani znacne casti kodu ..).

Naopak jsme se snazili kladnymi body ohodnotit to, co jste udelali nad 
ramec zadani nebo obzvlaste hezky. Kladne body jsme pridelovali zhruba 
4x vetsi nez jsme meli puvodne v planu, coz mnohym skupinam 
vykompenzovalo bodovou ztratu.

Zakladnim cilem bylo, abyste se na semestralkach neco naucili. Proto 
prikladam strucny seznam nejcasteji se opakujicich chyb:


1) Nedodrzovani jednotneho coding style, konzistentniho pojmenovavani 
identifikatoru, neprehledny strom zdrojaku apod.

V pripade malych jednoclennych projektu toto nemusi byt problem, ale u 
prace tohoto rozsahu uz bylo patrne, ze clovek, ktery kod sam nepsal, se 
v neprehledne adresarove strukture (mnohdy byly kernelove i user 
zdrojaky v jednom adresari) a jednotne uprave zdrojaku slozite 
orientuje. Mala cast skupin vsak mela upravu zdrojaku vzorovou a dokonce 
meli svuj coding style dokumentovany.


2) Opakovana implementace spojovych seznamu.

Stale se opakujici implementace logiky spojovych seznamu pro kazdou 
novou strukturu, kterou je potreba v seznamech udrzovat, byla mnohdy az 
zarazejici. Pritom postupy, jak elegantne vytvaret genericke datove 
struktury, existuji -- at uz to je metoda generujicich maker (obdoba 
sablonovych STL kontejneru z C++) nebo klasicka (ale velmi prehledna) 
implementace v jadre Linuxu (viz 
http://isis.poly.edu/kulesh/stuff/src/klist/).


3) Netestovani argumentu systemovych volani

Nesvar, ktery se opakoval u velke casti skupin. Prestoze jsme v zadani 
nepozadovali nejakou skutecnou "security", kazdy kernel musi byt napsan 
tak, aby byl odolny vuci nahodnym nebo zamernym chybam v uzivatelskem 
prostoru.

Neni proto dost dobre mozne predavat systemovemu volani nejaky ukazatel 
na datovou strukturu a ten potom v kernelu bezelstne pouzivat, aniz by 
si kernel vubec overil, zda ukazatel miri na korektne namapovanou pamet 
procesu (a ne napriklad nekam do kernelove pameti, kde se muze neco 
prepsat). I pokud tento zakladni test provedete, stale to nestaci
k tomu, aby bylo mozne verit, ze datova struktura s kernelovymi daty 
(ovsem ulozena v uzivatelskem prostoru) obsahuje konzistentni zaznamy 
(porovnani nejake magic hodnoty je sice hezke, ale stale nezarucuje, ze 
uzivatelsky proces data nepodvrhl). To, ze pro user space je pointer na 
kernelovou pamet jen logicky handle, take nic nevyresi, protoze i handle 
  se da podvrhnout.

Jedna z mala rozumnych cest je tedy ta, ze user space bude od kernelu 
dostavat pouze ciselne identifikatory kernelovych struktur (skutecne 
handle) a kernel si bude u kazdeho procesu evidovat, ktere 
identifikatory mu patri. V pripade predavani ukazatelu na pole, retezce 
atd. je potreba upravit spravu pameti, aby "vybehnuti" kernelu
z namapovane uzivatelske pameti zpusobilo pouze "potrestani" zleho 
procesu a ne pad kernelu.

(Z podobneho soudku byly pripady, kdy prepnuti z kerneloveho do 
uzivatelskeho rezimu procesoru pri spousteni procesu nebylo provedeno uz 
v kernelu, ale az v ramci uzivatelske knihovny librt. Asi neni potreba 
dopodrobna rozvadet, co to dovoluje procesu, ktery se nechce nechavat 
omezovat uzivatelskym rezimem ..)


4) Prevod thread_sleep() na thread_usleep() nasobenim milionem

Prestoze to na prvni pohled bude fungovat, tak smysl existence funkce 
thread_sleep() je ten, aby se dalo cekat treba den nebo tyden (coz neni 
zas tak neobvykly pozadavek). V takovem pripade by ten trivialni prevod 
sekund na mikrosekundy zpusobil preteceni.

Moralni pouceni je to, ze v API operacniho systemu vetsinou nejsou 
zbytecne veci, ktere lze trivialne nahradit necim jinym. Proto je 
potreba zamyslet se i nad implementaci na prvni pohled jasnych veci.


5) Dokumentace -- chybejici provazanost

Bez ohledu na kvalitu rucne psane a referencni dokumentace jsme se casto 
setkavali s tim, ze tyto dve casti byly naprosto oddelene, jakoby ani 
nepopisovaly stejny projekt. Smysl rucne psane dokumentace je pohled na 
architekturu celeho systemu "z prvniho patra", ale mely by z ni vest 
odkazy na casti referencni dokumentace, kde se clovek dozvi konkretni 
podrobnosti.


M.D.