<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-03-21 20:46 GMT+01:00 Martin Decky <span dir="ltr"><<a href="mailto:decky@d3s.mff.cuni.cz" target="_blank">decky@d3s.mff.cuni.cz</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Vážený pane kolego,<br>
<br>
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.<br>
<br>
Dovolte mi, abych k VaÅ¡im připomínkám přidal několik svých osobních komentářů.<br>
<br>
<br>
Ad "zruÅ¡it dokumentaci"<br>
-----------------------<br>
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". <br></blockquote><div>Já naprosto souhlasím, Å¾e reálný softwarový projekt si dokumentaci zasouží. OvÅ¡em myslím si, Å¾e reálný softwarový projekt se odliÅ¡uje již v samotném procesu tvorby od OSů natolik, Å¾e není třeba se snažit k němu přiblížit v dokumentaci. Navíc, jak jsem již psal, od podobání se reálnému softwarovému projektu tu máme předmět softwarový projekt.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
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.<br>
<br>
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.<br></blockquote><div>Pokud bychom na začátku věděli, Å¾e to, co se po nás chce, je fotit si tabule, na kterých si malujeme, jak to má vypadat, a pak k tomu napsat pár vět a odevzdat to jako ÄÃ¡st dokumentace, pak bychom asi měli z dokumentování lepší pocit. Ale když se celé zadání tváří jako enterprise projekt, tak nás to ani nenapadlo, protože to nemělo korporátní formu.  <br><br></div><div>Možná je to nedostatkem zkuÅ¡eností (ale ty jsme právě na OSech nabrali), ale i když jsme měli stavební kameny dopředu jasné, tak stejně větÅ¡ina struktur a funkcí doznala významných změn, když při testech / zkouÅ¡ení vyÅ¡ly najevo okrajové případy, na které jsme během návrhu nepomysleli.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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 :)<br></blockquote><div>Buďme tedy se 4.5 body praktickým protipříkladem.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Ad "debuggovací výpisy"<br>
-----------------------<br>
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).<br>
<br>
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.<br>
<br>
<br>
Ad "rucni průběžná kontrola"<br>
----------------------------<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
Ad "upravit deadline"<br>
---------------------<br>
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.<br></blockquote><div> Myslím si, Å¾e to k odkládání věcí na poslední chvíli nemotvuje o moc více než současný systém. Věci se na poslední chvíli dělají a dělat budou a možnost odladit nějakou drobnost (protože víc se stejně nestihne), která se objevila na poslední chvíli, potěší. Do půlnoci bude programovat skoro každý bez problémů, ale když si mám vybrat mezi (programováním do rána a ztrátou bodu) a (možností se vyspat a o bod více), radÅ¡i se vyspím.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Ad "upravit bodování"<br>
---------------------<br>
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).<br></blockquote><div>Množství komentářů sice není kritériem, ale chybějící komentáře jsou strhávány body...<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Bonusové body za doplňkovou funcionalitu nad rámec zadání udělujeme a od prvního cvičení k tomu skupiny motivujeme.<br></blockquote><div>Ano, bonusový minus Ätvrtbod za pokus o implementaci forku a execu. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Ad "testování na reálném HW"<br>
----------------------------<br>
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).<br>
<br>
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).<br>
<br>
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í.<br></blockquote><div> </div><div>Navrhuji, aby skupiny, pokud budou chtít, dostaly k dispozici nějaký HW typu routerboard, aby to bylo inzerováno a aby to bylo podporováno. Viděl jsem, Å¾e to jde udělat, ale pro praktické použití by bylo fajn, aby již v kalistu bylo implementováno putc a getc přes sériovou konzoli a aby byl v Makefilu cíl pro reálný hardware. Je mi jasné, Å¾e debugování na reálném hardwaru je náročnější na Äas a Å¾e nejste schopni nám poskytovat detailní podporu, ale je rozdíl mezi "Má to stejnou architekturu, tak si to naportujte sami" a "Pro kompilaci na reálný hardware napiÅ¡te "make hw", binárku si nahrajte podle tohoto návodu a putc a getc vám chodí na sériovou konzoli, zbytek si ale budete muset napsat sami". Upravovat něco, co už trochu funguje je mnohem snazší, než psát věci, které jsem nikdy nepsal, na hardware, který jsem nikdy předtím neměl.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Å koda, Å¾e jste toto přání neprojevil dřív. Minimálně jeden RouterBoard k případnému zapůjčení máme.<br>
<br>
<br>
Ad "drobnosti pro debuggování"<br>
------------------------------<br>
Díky za návrhy, větÅ¡inu z nich jistě můžeme implementovat, pokud nám to Äas dovolí.<br>
<br>
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.<br></blockquote><div>To by asi fungovalo, ale pak by v trace chyběla informace o tom, kdy byl vypsán znak. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br></blockquote><div>A kde je to napsané v dokumentaci msimu? Když dám load, tak bych intuitivně předpokládal, Å¾e chci disk právě tak velký, jako je soubor a hlavně bych Äekal, Å¾e chování load a fmap bude identické, až na to, Å¾e změny v disku nataženém přes load se do souboru nepromítnou a přes fmap ano.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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í :)<br>
<br>
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ě.<br>
<br>
<br>
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.<br>
<br>
<br>
[1] <a href="http://d3s.mff.cuni.cz/~holub/sw/msim/" target="_blank">http://d3s.mff.cuni.cz/~holub/<u></u>sw/msim/</a><br>
<br>
<br>
S pozdravem<br>
<br>
Martin Děcký<br>
<br>
______________________________<u></u>_________________<br>
OSy mailing list<br>
<a href="mailto:OSy@d3s.mff.cuni.cz" target="_blank">OSy@d3s.mff.cuni.cz</a><br>
<a href="https://d3s.mff.cuni.cz/mailman/listinfo/osy" target="_blank">https://d3s.mff.cuni.cz/<u></u>mailman/listinfo/osy</a><br></blockquote><div><br></div><div>A jeÅ¡tě si rýpnu, když už se po nás chce dodržovat deadliny, byli bychom rádi, kdyby konec dubna nebyl v druhé polovině května.  <br></div></div><br></div><div class="gmail_extra">S pozdravem<br></div><div class="gmail_extra">Tomáš Pokorný<br></div></div>