helenos-nicf team mailing list archive

[Zdenek Bouska <zdenek.bouska@xxxxxxxxx>]

Struktura mi prijde dobra.

> Co se jednotlivých částí týče, viděl bych to asi takto (ano, vím že
> některé části už v dokumentaci jsou):
> 1) Obsah s odkazy - ví někdo, jak toho docílit? Nejlépe tak, aby ve
> vytištěné dokumentaci byla čísla stránek?
Udelal bych to stejne jako HelUSB. Kdyztak se jich muzem zeptat.
> 2) Úvod s tím, co je HelenOS, že je síťování důležitou součástí dnešních
> operačních systémů...
> ---- prostě zdůraznění užitečnosti naší práce
> ---- ve stávajícím textu vypustit zmíňky o předpokládaných znalostech a
> vše relevantní popsat
Sohlas se zdurazneni uzitecnosti. Mozna vic zminit uzitacnost NIC 
frameworku pri pdani driveru.
> 3) Přehledový popis architektury síťového stacku, DDF a memory
> managementu v HelenOS
> ---- principy IPC v HelenOS, async session a výhody
> ---- principy memory backendů
> ---- v podstatě to co tam je, nejlépe rozšířit o přehledové obrázky
> (přeci obrázek občas zastoupí i několik odstavců textu)
Myslim ze ten obrazek APP<->IL<->NIL<->NIC staci.
> 4) Popis NICF
> ---- zdůraznit snahu o přesunutí co nejvíce práce do defaultních
> implementací (zejména snaha o volání ručně psaného kódu jen pokud je
> třeba sáhnout na HW)
Sohlas, jak jsem psal vyse, tohle zminit i uz v uvodu.
> ---- napojení na DDF, obrázek zobrazující možnou spolupráci DDF vrstvy,
> NICF rozhraní, defaultních implementací, ručně psaného kódu (příp. i
> HW), NICF knihovny (draft obrázku jsem si načrtl na papír, takže ho
> předělám do elekntronického formátu)
Ok super.
> ---- nejsem si jist, jestli výčet všech funkcí tak, jak je, je vhodný do
> dokumentace, spíše do nějaké přílohy, spíše napsat, z jakých částí se
> celkově NICF skládá a co k čemu slouží (libnic, nic_interface,...)
Asi podle toho jak to bude dlouhe. Chtelo by to taky popsat ty defaulni 
implemntace a jake funkce se volaji z nich. To je dost dulezita 
informace pokud pisu driver, mozna tedy spis do kapitoly Jak napsat driver.

> 6) Popis jednotlivých implementovaných driverů
> ---- tady je víceméně jasné, že kdo co dělal si zdokumentuje, bude
> stačit popis toho, co karta umí, specifika jak pracuje a co je
> implementované
U E1000 jsem neco commitnul, ale jste to chce doupravit.
> 7) Vyvinuté nástroje + nepřímo související věci (mm registry v
> přerušení),...
> ---- spíše než koncepce ala man pages včetně všech možných argumentů (to
> by bylo též vhodné spíše přesunout do přílohy) co to umí, proč to tam je
> a příklady použití
Jo priklady pouziti jsou dobrej napad.
> 8) Jak napsat NIC driver
> ---- základní driver, v podstatě po doplnění (a kontrole odpovídá-li to
> současnému stavu) to, co napsal Radim
Jak jsem psal vyse. Lepe popsat ty _impl funkce. Treba write_packet je 
volan myslim se send_message_impl.
> 9) Jak otestovat driver
> ---- spuštění qemu, ping, spuštění více instancí, nictest
> ---- čili jednak návod pro autora driveru, jak si co nejlépe otestovat
> driver (aby měl i parametry qemu po ruce)
> ---- a zároveň návod pro toho, kdo bude projekt testovat, jak si naše
> vymoženosti vyzkouší
> ---- tady mám docela rozmyšleno, co tam napsat, takže to bude další věc,
> které bych se ujal přednostně sám
OK fajn.
> 10) User dokumentace
> ---- popis jak si někdo může přeložit náš kód, kde získat aktuální
> verzi, na jakých platformách apod.
Asi staci odkazat na toolchain. Zminit se ze na zacatku vyopise 
zavyslosti. Odkaz na launchpad. a helenos.org
> Future development
> ---- určitě přidávání dalších driverů
> ---- power management (uspávání při vytažení kabelu,...)
> ---- další nápady?
Karty s vice rozhranima. To myslim ted bez upravy NIC nepujde.
> ---- třeba odebírání karet (USB/PCMCIA)

> Co tam má být dále dle pořadavků z pravidel projektu:
> - Zasazení vytvořeného díla do kontextu existujících programových děl
> řešících obdobnou problematiku
> ---- což chápu tak, že bychom měli uvést i případná řešení v jiných OS,
> dal bych to jako součást úvodu
> - kritické zhodnocení přijatých řešení a možnosti dalšího vývoje
> ---- čili zmínit kontroverznější rozhodnutí a zvažované alternativy, z
> hlavy si vzpomínám na architektury filtrů a stavy, ze zápisů toho bude
> zřejmé více
Ja si tady vzpominam na alokaci paketu, zda se musi nutne alokovat v 
nejake nizsi casti pameti. Zda se ohlizet na karty s mesim adresnim 
prostorem nez ma architektura.

> A Honzu bych poprosil o nějaké přehledové představení memory
> serveru (řeší nebezpečí uvolnění paměti při pádu driveru, ačkoliv
> hardware ji stále používá - memory server si ji na žádost driveru
> nasdílí dokud mu driver neřekne, že danou paměť už HW nepoužívá),
> abychom toto mohli ještě zakomponovat do driverů. A rozhodně by to pak
> nemělo chybět v celkové dokumentaci.
U E1000 dokumntace jsem zminil ze pouzivam packet->phys_addr a ze 
pripadne pri vyhozeni packet serveru by se to dalo predelat na 
dma_lock/dma_unlock. Mozna to zminit i nekde v obecne casti.

> Prosím vyjádřete se k tomu, zda-li s takovouto strukturou souhlasíte, co
> tam je navíc, chybí či má být jinak. Dále napiště, kdo co bude udělat
> (včetně již naplánované práce jako testování či nedodělky v kódu). V
> podstatě jsem vycházel z již stávajícího Radimova základu a podíval se
> do pravidel projektů a dokumentace usb projektu.
Se strukturou souhlasim.
Chci to otestovat proti RTL. Za urcitych okolnosti mi to hazelo CRC chyby.
Dlouho jsem nezkousel ping, tak ho chci zas zkusit.
Dale jsem zatim jeste vubec netestoval VLAN podporu.

Zdenek