[OSy] Shrnuti OSu

[Martin Decky]

Vazeni kolegove,

predmet Operacni systemy je (alespon co se tyce semestralnich praci) pro 
tento akademicky rok uzavren. Proto bych se s Vami jeste rad podelil o 
komentar ke trem prohreskum, ktere jsme jednotlivym skupinam v hodnoceni 
praci vytykali nejcasteji.

Nemohu ale zacit negativne, protoze hned dvema skupinam se letos 
podarilo dosahnout plneho poctu bodu (a dve dalsi se teto mete vyrazne 
priblizily), coz je urcite duvod k pochvale. Nyni tedy k tem mene 
prijemnym poznamkam:


1) Nedodrzovani jednotneho coding stylu, nekonzistentni pojmenovavani 
identifikatoru, nekonzistentni zpusob komentovani, neuklizeny kod 
"zableseny" zakomentovanym mrtvym kodem

V pripade jednoclennych projektu nemusi byt dodrzovani vhodneho coding 
style a uhlednych zdrojaku 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.

Pochopitelne nelze 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 
konvenci atd.) se snadno cte a snadno se o nem rozhoduje, zda je 
spravne, neprehledny zdrojak muze vest na efekt "hledani jehly v kupce 
sena".


2) Netestovani argumentu systemovych volani

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

Neni proto dost dobre mozne predavat pomoci systemoveho volani nejaky 
ukazatel na datovou strukturu a ten potom v kernelu bezelstne pouzivat, 
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 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 OK, 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.


3) Extremne slozite mechanismy synchronizace

Mnohe skupiny jakoby dovedly az do extremu obecny poznatek, ze spravna 
synchronizace nad sdilenymi daty je slozita vec. I jednoduche pripady, 
ktere se daly vyresit naprosto elegantne s pouzitim jednoho nebo dvou 
mutexu, pripadne za pouziti atomickych citacu (treba klavesnicovy 
buffer), doslova utopily v neproniknutelne zmeti uspavani a probouzeni 
vlaken, manualniho vkladani a vytahovani vlaken z ruznych planovacich 
front a obcas dokonce pouziti aktivniho cekani.

Pokud vite, ze Vase sychnronizacni primitivum (mutex, semafor, 
podminkova promenna apod.) je naimplementovano spravne a ma rozumne API, 
potom je jeho pouziti v miste, kde je fakticky potreba neco 
synchronizovat, typicky velmi jednoduche, primocare a predevsim 
prehledne. Lze doslova na prvni pohled poznat, ze se synchronizuje 
spravne, protoze veskera slozitost problemu je odabstrahovana pryc, mimo 
business kod.

Je to podobne jako z estetikou zdrojaku: Slozite a tezko pochopitelne 
synchronizacni konstrukce v kodu, ktery neslouzi primarne k 
synchronizaci (ma jen tu "smulu", ze nejakou synchronizaci pristupu ke 
sdilenym datum potrebuje), zpusobuji, ze je velmi slozite rozhodnout 
(natoz "videt na prvni pohled"), zda je vse v poradku. Snadno se do 
takoveho kodu nejakym rutinnim zasahem zanese chyba a i pri podrobnem 
zkoumani muze dlouho unikat pozornosti.


Zaverem pevne doufam, ze i pres netrivialni mnozstvi prace, ktere jste 
museli na dokonceni semestralek z OSu vynalozit, Vam tato zkusenost neco 
pozitivniho dala. Preji Vam hodne uspechu v dalsim studiu!


M.D.