helenos-nicf team mailing list archive

[Radim Vansa <radim.vansa@xxxxxxxxx>]

Díky za feedback.

Myslíš si, že reimplementace některé _impl funkce by byla driver 
specifická? Mám na mysli něco, co by nebyla jenom určitá obálka 
existující implementace (která lze udělat i v současnosti), ale 
složitější změna, která by nutila šahat přímo na strukturu nic_t. Ptám 
se jako autora driveru, protože mám pocit, že takovéto změny, které musí 
měnit způsob fungování vnitřních částí NICF, jsou něco obecnějšího - je 
samozřejmě možné, že něčemu současná podoba frameworku nebude vyhovovat. 
V takovém případě by však měl by autor driveru vytvořit alternativní 
*obecnou* implementaci (když už se stejně chce hrabat v NICF) a ve svém 
driveru ji pak využít. Samozřejmě, nemusí ji vkládat do samotné knihovny 
libnic, stačí pouze definovat v daném souboru (či v Makefile) makro, 
které označuje tento kód jako kód logicky přináležející do NICF. Myslím 
si, že ochrana přístupu je dobrá věc (proto ji ostatně OO jazyky 
používají) a tato nutnost definovat makro s sebou nese upozorněni 
"Hrabeš do NICF!" a nutí autora driveru lépe strukturovat to, co dělá. V 
principu nikdo nebrání té nové implementaci.

Za ty caps_max se omlouvám, vytvořím pro to taktéž funkci - některé 
detaily mi ušly a je dobře, že mne na ně upozorníš.

Radim

On 16.6.2011 13:25, Jirka Michalec wrote:
> Ahoj,
>
> při namergeování posledních změn NICF jsem dospěl k názoru, že 
> schování nic_t struktury před autory driverů nebyl příliš dobrý nápad.
>
> Jedna z velmi diskutabilních věcí je práce s nic_t v _impl funkcích. 
> _impl funkce byly zamýšleny jako typické postupy při obsluze daného 
> callbacku, ale autor měl mít možnost v případě potřeby napsat a použít 
> funkci vlastní (a to i jen jednu, pokud mu ostatní _impl funkce u dané 
> funkcionality vyhovují). Autor by tedy měl mít k dispozici vše, co 
> _impl funkce používají. Při pohledu na _impl funkce to ale možné není 
> - funkce zamykají zámky v nic_t, zapisují/čtou jinak nepřístupné 
> položky (mimochodem, nemožnost nastavit caps_max u WoL jsem už napsal 
> do mantisu),... Chce-li tedy autor upravit jedinou _impl funkci, musí 
> (kvůli nemožnosti v ní adekvátně zamykat, číst/měnit některé informace 
> z nic_t) v podstatě vytvořit vlastní kopii nic_t a napsat i vše 
> ostatní sám. Dle mého názoru by se mělo, má-li nic_t zůstat privátní, 
> rozšířit rozhraní přístupu k ní tak, aby bylo možno přepsat 
> kteroukoliv _impl funkci způsobem nevyužívajícím privátní hlavičkové 
> soubory frameworku.
>
> Pokud někdo píše driver, dá se předpokládat dobrá znalost fungování 
> HW, schopnost číst dokumentaci a jednat podle ní. Tedy hlavní věc, 
> která stačí ke správnému využívání frameworků, je jejich dobré 
> zdokumentování. Schovávat před programátory implementační detaily je 
> IMO na úrovni ovladačů HW dosti podivné, místo toho se případnému 
> špatnému přístupu k strukturám frameworku dá předejít dobrým 
> zdokumentováním, co za jakých okolností framework vyžaduje (hodnoty 
> položek struktury, kdy se co má zamykat, kdy co framework zamyká,...).
>
> Jaký na to máte názor vy?
>
> Michy
>
> _______________________________________________
> 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