[OSy] Re: OSy Digest, Vol 24, Issue 9

[Martin Decky]

> Tazatele uvedli jen kod, ktery pridali k jadru KOHLTO a tim vyzkouseli jeho funkcnost s vice VAS nez 1...:)

Bohuzel popis te chyby se (alespon ze zacatku) zdal jako stiznost na 
spatnou funkci zdedeneho kodu. Jak se ale nakonec ukazalo, bylo to spis 
nepochopeni spravne semantiky existujicich funkci.

> Po dalsim umornem zkouseni jsem jako posledni zachranu zkusil kopirovani presunout skutecne az do fce vykonavane threadem(2.vytovreny)

Skoda, ze jste misto metody umorneho zkouseni nepouzili metodu 
porozumeni. Podle vseho jste si dlouho mysleli, ze funkce 
thread_create_new_map() vytvori nove vlakno a vrati novy adresni 
prostor, se kterym lze potom (v puvodnim kontextu) manipulovat.

To ovsem odporuje jednak specifikaci chovani funkce ze zadani 2. 
semestralky a pravdepodobne take implementaci v jadru KoHlTo.

(S "cizim" adresnim prostorem jako s datovou strukturou lze pochopitelne 
prislusne manipulovat i "z venku", ale je to potreba delat explicitne. 
Pokud vytvorite vlakno s novym adresnim prostorem, tezko muzete 
ocekavat, ze jine vlakno/kontext, ktere ma jiny adresni prostor, uvidi 
stejna data.)

> Skutecne nam uz nezbyva cas hrat si s chybami predchozich skupin a tak zacinam studovat jadro KoDaGr a doufat, ze na nem to fungovat bude spravne.

Pochopitelne ani puvodni autori ani my nemuzeme 100% garantovat, ze 
starsi kernely neobsahuji zadne chyby. Na druhou stranu kernely prosly 
prislusnymi testy a jejich kod jsme prohledli, takze by to nemely byt 
chyby na prvni pohled zjevne.

Trochu me ovsem prekvapuje, ze tak zakladni vec jako vytvareni adresniho 
prostoru a kopirovani obrazu uzivatelskeho procesu ladite 4 dny pred 
odevzdanim. Kdybyste na tento problem narazili treba uz pred Vanoci, 
jiste by bylo snazsi vec resit s chladnou hlavou.


M.D.