helenos-nicf team mailing list archive

[Radim Vansa <radim.vansa@xxxxxxxxx>]

> Ale ona si aplikace prece rekne o paket a knihovna, ktere se pta uz 
> zaruci aby byl nalokovan pouzitalne i pro driver... i baz packet serveru.
> Pokud jde o 32bitovou kartu v 64bitovem systemu, tak ta knihovna muze 
> zarucit (misto paket serveru) alokaci nize v dolnich 32 bitech. Nebo 
> to muze driver kopirovat, jen pokud zjisti, ze adresa je vetsi.
> Nemuset vubec kopirovat pakety je dulezite u velkych prenosovych 
> rychlosti.
Souhlas.
> Mozna bychom se o tomhle mohli vice pobavit i s Deckym!
Nevím, tohle se mi zdá zbytečné a stejně to nejspíše nechá na nás.
> > Takova funkce uz tam je: nic_driver_release_packet
> Aha, nak jsem ji prehledl...
> Tak jak je tedka implementovana, tak ale pouzit nejde, ten zamek je 
> zamcen pro cteni a nic_driver_release_packet() by ho zamykala pro zapis.
> Zacinam si rikat, jestli nebude lepsi, kdyz si prece jen udelam 
> vlastni send_message().
Pokud je packet uvolňován v send message, tak se to dělo bez téhle 
funkce. Pokud je uvolňován v handleru interruptu, tak žádný zámek 
zamknut není, čili můžeš ji použít. Pravda, že ve write_packet použít 
nejde - tak si říkám, že je tam tím pádem ještě bug, protože pro 
posílání zprávy NETu by se měl main_lock zamykat pro zápis. Napadá vás 
někoho, jak transparentně zjistit, jestli se to volá nepřímo ze send 
message (teda bez zkoumání stacku), nebo jí musíme předávat nějaký extra 
argument, což není tak elegantní?
> _______________________________________________
> Mailing list: https://launchpad.net/~helenos-nicf
> Post to : helenos-nicf@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~helenos-nicf
> More help : https://help.launchpad.net/ListHelp