nahrazeni syscallu?

Dan Lukes dan at obluda.cz
Tue Mar 2 21:25:11 CET 2004


On Tue, 2 Mar 2004, Tomas Pluskal wrote:

> programuji modul, ktery ma nahradit nejake syscally vlastnimi handlery,
> ktere potom volaji puvodni obsluhy syscallu. otazka ktera me zajima -
> pokud puvodni obsluha syscallu byla take "napichnuta" nejakym modulem, tak
> ja na konci sve funkce budu volat funkci (handler) patrici tomuto modulu.
> pokud se ten modul ovsem zrusi (unloaduje), jak se to dozvim?

	No budes poslouchat na syscallu pro "unload" modulu ...


	Mimochodem - copak asi udela takovy modul, kdyz se unloaduje ? No -
pokud je napsany slusne, tak se podiva, jestli aktualni pointry syscallu
jsou "ty jeho" - a pokdu ne, odmitne se odloadovat s tim, ze to v danou
chvili neni mozne. Pokud ano, tak je nahradi ulozenymi puvodnimi. Bude
pritom doufat, ze ostatni moduly jsou stejne slusne jako on a mezi tim se mu
neodloadovaly a tak jsou navracene pointry stale pouzitelne (nebot' se
odmitly odloadovat, kdyz nenalezly na prislusnych adresach svoje pointry).

	No a nebo bude nejaky modul neslusny - pak proste nebude resit nic a
flakne na misto puvodni pointry - pak uz se ovsem tvuj modul "k lizu"
nedostane ...

	A pokud tam takovych neslusnych modulu bude vic nez jeden, tak
system stejen nakonec spadne, protoze vracene pointry drive nebo pozdeji
budou patriti jinemu jiz odloadovanemu modulu ...


	Uvedomujes si, predpokladam, ze resis ulohu, ktera nema standardni
reseni (a ani se nepocita s tim, ze by se nejake hledalo). Nemuzes doufat, v
nejake verejne zname a definovane chovani jinych modulu. To, ze vubec muzes
adresy syscallu prepisovat neni dano tim, ze by to bylo vhodne a rozumen
delat - ale proto, ze modul je soucasti jadra s pristupem ke vsemu a ocekava
se, ze vsechny moduly dohromady s jadrem tvori logicky jeden funkcni a
programovy celek - a jsou napsany nad "spolecnou databazi znalosti" - a
vsechny *spolecne a nerozlucne* spolupracuji na jedine uloze - stabilni a
funkcni OS.

	Varianta, ze je v jadre nejaky modul, ktery se mnou nespolupracuje v
te mire, v jake ja potrebuji - to jest, ze mi neda vedet, ze "odchazi", kdyz
ja to pro svoji praci vedet potrebuji - to je uloha, ktera je uplne mimo
tridu "vhodnych reseni". Moduly proste musi s jadrem i navzajem plne
spolupracovat.

	Spravna odpoved na tvoji otazku tedy je "modul mi to da vedet
mechanismem, ktery jsem od obou zapracoval - a spolecne se oba moduly dohodnou
jak dal a co s tim"

	Jinymi slovy - situace, kterou pozadujes resit nemuze na vhodne
spravovanem systemu vubec nastat - spravce nikdy nemuze soucasny vyskyt dvou
takovych nespolupracujicich modulu v systemu vubec pripustit.

	Mimochodem -  nenapadlo by me, ze po svete uvidim chodit ducha davno
zemrele filosofie DOSovskych rezidentnich programu - ty pouzivaly stejny
mechanismus a mely presne stejne problemy ...


								Dan




More information about the Users-l mailing list