| Thread Previous • Date Previous • Date Next • Thread Next |
Ahoj,
nesnažil jsi se použít přímo fun->driver_data? Když jsem se totiž kouknul do toho, jak se k tomu přistupuje v impl funkcích, tak nic_t musíš získat jako fun->dev->driver_data, nic_t se do driver_data fun nevyplňují.
Aha, má chyba - této změny jsem si při mergeování zavedení ddf_fun_t nevšiml, stále jsem k argumentu přistupoval jako ke starému device_t... (a tím, že ddf_fun_t i ddf_dev_t mají (stejně jako device_t) položku driver_data tuto záměnu kompilátor neodhalil). Díky za info, chyba tam tedy žádná není...
Já se moc ve víceportových síťovkách nevyznám, myslíte, že se nic_t tak, jak je v současnosti, vztahuje k celé síťovce, nebo jenom k jednomu portu (funkci)? V případě třeba WOLů, popř. ACTIVE/STOPPED stavy je to per síťovka, zase třeba DOWN mi připadá jako stav per port, stejně tak nastavení filtrování a samozřejmě každá má vlastní adresu. Nějak na ty víceportové opravdu moc nepamatujeme...
Naopak mi ACTIVE/STOPPED dávají více smysl per port - stavy říkají, jestli dané síťové zařízení přijímá packety, čili stav z pohledu "přijímá/nepřijímá", nikoliv z pohledu "je fyzicky zapnuté/není fyzicky zapnuté". Klidně můžeš mít jeden port ACTIVE a jeden STOPPED - to v případě, že zrovna jeden port není vůbec využíván a nemá smysl ho tedy logicky zapínat. Jestli to fyzicky bude implementováno tak, že druhý port bude zapnutý s nastavením, že nemá nic přijímat, je věc druhá (odhaduji, že víceportové karty mají možnost ovládat zapnutí/vypnutí jednotlivých portů samostatně, ale do dokumentace k žádné takové kartě jsem se nekoukal - každopádně toto se snadno nasimuluje při zapnutém portu i na vyšší úrovni). U WoL také můžeš chtít přijímat WoL jen z protu připojeném k privátní síti - ale zde už opravdu záleží na tom, jestli multiportové karty podporují nastavení WoL per port, to už se vyšší vrstvou neodfiltruje...
Michy
| Thread Previous • Date Previous • Date Next • Thread Next |
