Jaderné noviny – 15. 9. 2011: Multiplatformní ovladače a Linux (diskuse)

[tomo]

Ku tomu brcmsmac ovladacu by som len dodal ze som tym stastnym majitelom broadcom sietovky. Tudiz pravidelne sledujem ako na tom dany ovladac je. A smutne musim konstatovat ze pravdepodobne je kompatibilny s inymi operacnymi systemmi a dokaze sa vybuildit i v tom nasom linuxe. Na druhu stranu nieje pristupny (alebo aspon do nedavna vobec nebol) firmware ktory by dany ovladac zaviedol a tak mohol stastne multiplatformne fungovat.

Takze namiesto toho mam zavedeny nejaky binarny dvojmegovy kram ktory sa mi stara o sietovku a po 4-5 zmenach essid-u mozem akurat restartovat bo sa uz nejako nechyta. No a to ze treba pri kazdej mensej zmene cakat nato kym to niekto schopny z broadcomu zasa zkompatibilni...

[Ondrej 'SanTiago' Zajicek]

A neni jednodussi vymenit sitovku? Nova (treba od Intelu) vyjde na nekolik stovek a je po problemech.

[tomo]

Popravde toto ma to napadlo tiez tak som docasne kupil udajne podporovanu wifi do usb portu. Problem bol len v tom ze sa mi ovladac nezkompiloval voci recent kernelu (v tej dobe to bol tusim 2.6.39). Takze som sa chtiac nechtiac vratil ku boju s integrovanou.

Za druhe ide o notebook - samozrejme vymenit je mozne i tam ale ked uz na tom chlapci tak utesene robia...

Podla mna maju sancu udrzat ovladac napriec platformami iba po dobu ked bude v stagging akonahle "bude na ociach" tak so neho niekto nieco napise/ vyhodi a to uz zasa nebude kompatibilne z ich original ovladacom. A ak problem aspon trocha chapem tak nemozu len tak vystrihnut cudzi GPL kod a pichnut si ho do svojho uzavreteho ovladaca.

[Pali]

> A ak problem aspon trocha chapem tak nemozu len tak vystrihnut cudzi GPL kod a pichnut si ho do svojho uzavreteho ovladaca.

To som chcel prave napisat. GPL hovori nieco o derivative work, teda bud budu musiet otvorit aj ich windowsove ovladace pod GPL alebo nepouzit kod z linuxoveho kernelu - co ale uz nebude mutiplatformove...

[frr]

Mám pocit, že momentálně nejvanilkovější WiFi hardware je Atheros - PCI, USB, nejsem si jist nakolik i PCI-e. Konkrétní destičky hledejte u wifinářů: ASPA, i4wifi apod. Někteří lidé tvrdí, že hardware Mikrotik je lepší než ostatní značky (ačkoli to všem letuje třeba Wistron). Taková R52 mě pro běžné použití nikdy nezklamala - pod Linuxem ani pod Windows. Už jsem touto kartou nahradil spoustu podivných originálně dodaných wifin od značek jako je Via, Ralink apod.

[Luboš Doležel (Doli)]

Atheros R52 - tolik kernel panicků jsem ještě nezažil. Kamarádčin notebook s Windows mi dokázal server vždycky spolehlivě sundat

Pak jsem jí strčil do zakázaných MAC adres. Od té doby jsem neměl odvahu to znovu povolit.

[frr]

Žeby rozdíl spočíval v tom, že jsem R52 používal převážně jako klienta? Ta karta dokonce s ohyzdnou novotou zvanou CRDA nechce moc chodit v AP režimu... Jak je to dlouho, jaké jste používal ovladače, jakou verzi kernelu?

[Luboš Doležel (Doli)]

2.6.32, ovladač v jádře i aktuální z wireless-compat. A nikdy se mi nepodařilo tu kartu donutit používat všech evropských 13 kanálů. Zkusil jsem spoustu věcí, ale bez výsledku.

Teď tam mám 3.0.x, ale už se mi s tím nechce blbnout, jsem rád, že to běží.

[frr]

Jasně. Já se snažil naposled v 2.6.33.4. Od té doby nebyl čas a motivace. Jako jeden z nápadů na dlouhé zimní večery vidím "úplně vykostit CRDU". Právě aby ovladače povolily všechny kanály. Někde celou CRDU utnout hezky u kořene. Nastavit si country=CZ jako default ve zdrojácích kupodivu nestačí. Tuším jsem to někde četl, že s jinými ovladači není problém jet tu kartu v AP režimu na kterémkoli kanále (už si nepamatuju, jestli MadWifi nebo RouterOS). Aby mě někdo špatně nepochopil: mě nejde o to, používat nepovolené kanály. Mě jde o to, jet AP režim vůbec na nějakých kanálech - zejména na "povolených vyšších evropských". Třeba ČTÚ má mapu spektra celou přehledně čitelnou na webu, tak jaképak s tím softwarové vymyšlenosti. Celý tenhle regulatory softwarový blázinec je pěkná koule na noze. Zejména je natolik neintuitivní, že je prakticky nepoužitelný (zatím předpokládám, že je chyba spíš ve mně, že to není celé mozkově mrtvé, jak by řekl někdo méně trpělivý). Vnímám to jako opatření jak zařídit, aby se americký regulatory vlk (FCC?) nažral a open-source koza zůstala (skoro) celá. Že s tím zbytek světa bojuje, to hlavní vývojáře Amíky (žejo Linusi) nijak zvlášť netrápí. Asi je to prostě menší zlo.

[petr_p]

Nástroj iw umožňuje za běhu přepnout regulační doménu.

Definice regulačních domén má dva zdroje. Za prvé jednu tabulku můžete mít zakompilovanou přímo v jádře (CFG80211_INTERNAL_REGDB), za druhé tabulku můžete do jádra nahrát později nástrojem crda. Tabulka z uživatelského prostoru by měla jadernou přepsat. Integrace jde tak daleko, že když jádro údaje pro konkrétní doménu nemá, pošle netlinkem zprávu, tu zachytí udev a spustí crda, který jádru potřebné udaje dodá.

Pokud chcete mít regulační domény definované ještě před inicializací ovladačů rádií, zavádějte modul cfg80211 s parametrem ieee8021_regdom=CZ.

Z názvu modulu vyplývá, že regulační databáze je dostupná jen ovladačům, které používají infrastrukturu cfg80211, například ovladače nad vrstvou mac80211. Prakticky jsou to ty, které lze ovládat nástrojem iw. Dejete si pozor, že ovladače mimo hlavní strom si často vláčí vlastní historickou verzi mac80211, která s cfg80211 nemluví.

Nakonec je ještě třeba dodat, že existuje rozšíření 802.11 (mám dojem, že se schovává pod písmenem d), které umožňuje ápéčkám oznamovat identifikátor regulační domény nebo dokonce přímo frekvenční definici domény klientům. Takže pokud si někdo koupí router z dovozu, může se stát, že začne oznamovat blbosti. Oznamovaný kód lze najít na výpisu scanu nástrojem iw.

Jako úvod do problematiky doporučuji stránku na LinuxWireless.

[frr]

Ta externí REGDB, není v nějakém binárním formátu, nemusí být podepsaná? Pokud ano, dá se svévolně modifikovat? Ona věc stojí ale jinak: my nepotřebujeme hackovat REGDB. Defaultní REGDB obsahuje pro naši doménu správná data - není důvod záznamy modifikovat.

Horší je, že změna domény za chodu není úplně čistá. Ovladač si při startu usmyslí nějakou výchozí defaultní doménu. V případě ath5k a R52 EEPROMka indikuje, že ovladač má použít svůj default. A ovladač má ve zdrojáku natvrdo zadáno, že v téhle situaci defaultní doména je US. Pokud změníte doménu za jízdy na CZ, tak se prostě nevymění předpis pro US na předpis pro CZ. CDRA z obou domén vyrobí "společnou podmnožinu povoleného pásma". Fakt je, že jsem nezkoumal, jestli náhodou v našem případě tenhle průnik není identický s celou doménou CZ - ale obecně mi to leze krkem.

Má to řešení: v drivers/net/wireless/ath/regd.c je potřeba změnit zmíněný tvrdý default na CTRY_CZECH:

        if (reg->country_code == CTRY_DEFAULT &&
            regdmn == CTRY_DEFAULT) {
                printk(KERN_DEBUG "ath: EEPROM indicates default "
                       "country code should be used\n");
                reg->country_code = CTRY_CZECH;
        }

No a když jsem tohle všecko udělal, tak mi stejně R52 nechce na 5 GHz povolit AP režim. Všimněte si, že takové omezení v REGDB není přítomno (možná není ani kódovatelné? nebo ano?)

Co tam ještě schází? Zamítavý result kód vrací navenek CRDA. Ale mám podezření, že uvnitř za to může callback driveru ath5k, který se ještě navrch zeptá (opět) EEPROMky na kartě (a vrátí výsledek crdě). Tenhle callback je zmíněný v dokumentaci, měl by se jmenovat reg_notifier(). Takže odsud budu čenichat dál, až se k tomu zase dostanu

Ostatně jsem přímo tady na Ábíčku našel jeden konkrétní způsob

[petr_p]

Ta externí REGDB, není v nějakém binárním formátu, nemusí být podepsaná? Pokud ano, dá se svévolně modifikovat?

Pokud je crda přeložen s podporou kryptografie, pak přijímá jen podepsanou databázi. Veřejné klíče pro ověření lze doinstalovat vlastní. Postup je popsán na stránce, co jsem odkazoval.

CDRA z obou domén vyrobí "společnou podmnožinu povoleného pásma".

Ano, to je vlastnost. Výrobci zařízení se bojí, že by jinak nedostali od FCC certifikaci.

A ovladač má ve zdrojáku natvrdo zadáno, že v téhle situaci defaultní doména je US.

Z hlediska softwaru to je chyba. Z hlediska výrobce hardwaru to je vlastnost. Výrobce občas umožňuje hodnotu v EEPROM přeprogramovat. Samozřejmě z hlediska uživatele to je opruz. Napiš autorovi ovladače (nebo do mailing listu), co se s tím dá dělat.

[Majk]

Hoši, co se to tam stalo???

[pepazdepa]

broadcom ovladac je napsan pod NDA? pokud vyrobce poskytne dokumentaci pro vyvojare, tak si snad napisou vlastni ovladac a mohou (na)tlak vyrobce preposlat do patricnych mezi.

[osel]

Podle mě jsou jedinými problémy vývoje multiplatformního ovladače jeho začlenění do jádra a zpětně nekompatibilní změny použitých funkcí. Všechny ostatní věci v článku se dají bez problémů vyřešit. Třeba duplikace kódu, tak jak je popsaná v článku, je důsledkem špatného vývoje a rozhodně to není věc, která musí být v každém multiplatformním ovladači. Ale pokud by byli ovladače mimo jádro, tak by to vlastně znamenalo odklon od monolitického kernelu (museli by se definovat veřejná rozhraní pro připojení ovladačů).

[Luboš Doležel (Doli)]

Já si myslím, že nejlepší bude, když si ty svoje ovladače budou udržovat mimo jádro, zatímco komunita si bude v klidu hackovat "normální" ovladač.

[j]

Zjevne si to nepochopil, vem si nasledujici situaci:

system A podporuje funkci X system B ji nepodporuje

=> funkci X si musim do ovladace napsat. Mam dve moznosti - bud napisu extra volani ty funkce pro kazdy system zvlast (= pro me 2x prace), nebo to napisu jednou, protoze tu funkci sem si stejne dopsal. To ale bude znamenat, ze v systemu A se bude zbytecne volat moje funkce, kdyz system ji ma v sobe primo. Navic kdyz nekdo v systemu A zmeni volani X, tak bych musel prepisovat ovladac, coz takhle nemusim => presne jak je v clanecku to vede k pouzivani nezbytne nutnyho minima spolecnych funkcionalit a k nesmyslne obrovskym ovladacum.

Pokud bych sel tou pro me pracnejsi cestou => ze si napisu to volani pro kazdej system extra, tak uz neni zadnej podstatnej rozdil v napsani samostatnyho driveru pro kazdej system (kterej muze pripadne sdilet nejakou cast zdrojaku).

IMO vubecnejlepsi cesta by byla napsat driver pro rozsireny systemy + zverejnit nejakou rozumnou dokumentaci k tomu zelezu a pripadne nejaky nastrel zdrojaku, on uz se nekdo najde kdo to napise.

[Mordae]

Jo, souhlasim. Zverejnit komplet dokumentaci k HW a wokenni ovladac, on to na Linux uz nekdo naportuje.

[lertimir]

To je pravda, ale je pár vyjímek, Ve většině případů, když je ovladač sice méně efektivně implementován, ale správně, nic se neděje, hardware utlačí tu menší efektivitu. Ale grafické karty potřebují maximální efektivitu datových toků. Tam je vidět že bloby nvidie i AMD jsou výrazně rychlejší než komunitní ovladače. A AMD specifikaci uvolnila.

[jdsulin]

add b43 .. tady je zrovna situace celkem jednoducha. Kdyz uz je broadcom tak mily a zverejni zdrojove kody pro svou sitovku, pak nevidim duvod pro to, proc nemit ovladace 2. Jeden podporovany jako modul od broadcomu, s otevrenym zdrojovym kodem (klidne i pod necim jinym nez GPL) a druhy v jadre. Nejen, ze by ten v jadre podporoval i starsi sitove karty, ale mohla by do nej byt pretahovana podpora pro nove chipy a broadcom by si zachoval kontrolu nad svym ovladacem, vzdyt tak se to prece dela vsude ne ? Navic specialne u wifi karet - jejich pouziti je hlavne u wifi routeru a notebooku a tam je hlavni duvod funkcnost, vsem je jedno, jak a proc a jaka licence, kdyz se nepripoji na internet, tak tam stejne nakonec nahraji ovladac pres ndiswrapper. A co se tyka licence, pak neni na co si stezovat, ovaladace maji otevrene zdrojove kody. Jediny kdo si muze stezovat je tak maximalne Richard Stallman, ze nevi jak je navrzeny chip uvnitr.

[Mmad]

Průser je aktuálně jinde. M$ chtějí blokovat Linux pomocí podepisování UEFI - a bez podpisu se to prý nerozjede!
Návrh: Někdo koupí dostatek strojů s touto ochranou a pak je hodí výrobci na hlava pro a) nesouhlas se smlouvou M$ (nepotěšíte Ballmera), b) vázaný prodej (zdraví ČOI) a c) nemožnost nainstalovat jiný OS, který splňuje specifikaci, ale není podepsán (nakrknete dodavatele výrobce). V nejhorším hacknout certifikáty nebo napsat vlastní svobodnou implementaci UEFI a pak nechat manuálně aktualizovat chipy (nakrknete všechny).
Totální finále by ale asi bylo postavit si vlastní architekturu, která by byla kompletně pod svobodnými licencemi.

[Mmad]

Tak sorry, koukám, že už to tu drbete.