11.9.2008 14:42
stativ | skóre: 54
| blog: SlaNé roury
Rozbalit Rozbalit vše Re: Jaderné noviny - 30. 7. 2008
Portál AbcLinuxu, 5. května 2025 16:43
Aktuální jádro: 2.6.27-rc1. Citáty týdne: Linus Torvalds, Ingo Molnár, Matthew Dillon, Andrew Morton. 2.6.27 - zbytek příběhu. Bezzámková cache stránek. OLS: Stav bezdrátového síťování v Linuxu.
Současné vývojové jádro je 2.6.27-rc1 vydané Linusem 28. července. Během začleňovacího okna 2.6.27 bylo začleněno okolo 8100 sad změn; shrnutí naleznete ve článku níže. Významné změny ve 2.6.27 budou zahrnovat spoustu nových ovladačů (včetně ovladačů pro webové kamery gspca), podporu pro hardwarové testování integrity dat v blokové vrstvě, podporu pro kontrolní body [checkpointing] a obnovu virtuálních strojů v Xenu, sledovací framework ftrace, mmiotrace, patche tracehook, zpožděnou alokaci v ext4, souborový systém UBIFS, vícefrontové síťování, kexec skok, rozšíření počtu systémových volání pro bezpečnější programování v uživatelském prostoru, bezzámkovou cache stránek (vizte níže) a mnoho dalšího. Detaily vizte ve zkráceném changelogu, spoustu detailů v kompletním changelogu.
V době psaní tohoto článku nebyly do repozitáře hlavní řady po vydání 2.6.27-rc1 začleněny žádné patche.
Současné stabilní jádro je stále 2.6.26; toto jádro zatím nebylo nijak aktualizováno, ale říká se, že hromádka patchů pro takovou aktualizaci roste.
2.6.25.13 bylo vydáno 28. července s mnoha se síťováním spojenými opravami; zdá se, že některé z nich řeší závažné problémy. 2.6.25.12, obsahující dlouhý seznam oprav, bylo vydáno 24. července.
OK, takže teď, když jsem urazil tebe a tvoje domácí mazlíčky (jsou oškliví!), ukaž, kde se pletu, a řekni, že jsem b*bec ("Linusi - jsi b*bec a nepochopil jsi problém, takže jsi velký b*bec. A můj mazlíček je možná ošklivý, ale tvůj smrdí.")
Nebo řekni "No jo, jsme hlupáci a tady je mnohem lepší patch. Už to víckrát neuděláme."
Úžasné! Tvůj kód, jakmile byl do jádra připojen řádně, dobře nabootoval na pěti různých x86 testovacích systémech, nabootoval dobře na all-yes-config jádře s MAXSMP a NR_CPUS=4096, nabootoval dobře na all-no-config (a na allmodconfig a na slušném množství náhodných configů)...
Protože v1 tvého kódu je tak frustrujícím a mysl ohromujícím způsobem stabilní při testování (překonává dlouhý rekord patchů v1 v této oblasti jádra) a protože perfektní patch z definice neexistuje, řekl jsem si, že zmíním, že po dlouhém hledání jsem v tvém kódu nalezl a opravil vydání znemožňující [showstopper] chybu: ve svých makrech jsi použil "1ul" místo správného "1UL" stylu. Poměr mezi použitím 1ul a 1UL je ve stromě 1:30, takže tvá volba velikosti písmen přípony celočíselných konstant byla odsouzena jako nelinuxová a nadobro opravena.
-- Ingo Molnár
V každém případě to vypadá, že Tux3 používá mnoho podobných nápadů. Myslím, že jsi na správné cestě. Přidám jedno velké varování, které pochází z mé zkušenosti při implementaci HAMMERu, protože si myslím, že narazíš na stejné problémy.
Strávil jsem 9 měsíců návrhem HAMMERu a 9 měsíců jeho implementací. Během implementace jsem vyházel asi 80 % původního návrhu.
-- Matthew Dillon. Celé vlákno je zajímavé čtení o návrhu souborových systémů
Samotná velikost jednotlivých -rc mě poněkud znervózňuje. Jasně, znamená to, že jsme dobří a podařilo se nám to všechno sloučit, ale musím říct, že se občas zamýšlím nad tím, jestli toho nezačleňujeme příliš mnoho naráz a dokonce i náš současný (vcelku krátký) vývojový cyklus není ve skutečnosti příliš dlouhý.
To je nicméně diskuze pro jinou příležitost
Zdá se mi, že slyším spoustu ticha o podpoře SSD zařízení. Mám takovou mlhavou obavu, že se na trhu objeví spousta SSD hardwaru a Linux bude přistižen s kalhotami kolem kotníků.
Začleňovací okno 2.6.27 se uzavřelo s vydáním 2.6.27-rc1 28. července. Tentokrát bylo začleněno okolo 8100 sad změn, což z 2.6.27 dělá další rušný vývojový cyklus. Od minulého týdne se dovnitř dostalo mnoho zajímavých věcí; nejvýznamnější změny viditelné pro uživatele Linuxu zahrnují:
Jsou zde nové ovladače pro:
Také byl přidán "mISDN", nový - modulární - ISDN ovladač zamýšlený jako náhrada staršího kódu pro mnoho ISDN karet. Byla přidána podpora pro používání mISDN ovladačů vzdáleně přes IP tunel.
Nyní je podporován příruční počítač Palm T|X.
Souborový systém tmpfs získal podporu pro asynchronní I/O.
Mechanismus hugetlbfs nyní může podporovat několik velikostí obrovských stránek. K dispozici je nový adresář (/sys/kernel/hugepages), který obsahuje informace o alokacích obrovských stránek. Architektura x86 (64-bit) nyní podporuje 1GB stránky; PowerPC může jít až na 16 GB.
Většina systémových volání, která vytvářejí popisovače souborů, nyní může přijímat sadu příznaků; tato změna umožňuje vytváření zavřít-při-spuštění [close-on-exec] sémantiky, požadování neblokujících otevření a dalších věcí bez souběhů. Vývojáři, kteří tuto schopnost chtějí využít, budou muset počkat na verzi glibc, která přidá potřebná rozhraní.
Nespravovaná architektura v850 byla odstraněna.
Sada patchů kexec skoků, která používá mechanismus kexec jako alternativní způsob implementace uspání na disk, byla začleněna.
Byl začleněn souborový systém omfs
/proc nyní obsahuje soubor (nazvaný syscall) pro každý proces; když je přečten, zobrazí současné systémové volání procesu a předané argumenty.
Uživatelé, kteří v blízké budoucnosti doufají v upgrade svých strojů, rádi uslyší, že byla začleněna série patchů určená k tomu, aby jádro škálovalo až do 4096 procesorů.
Změny viditelné pro vývojáře jádra zahrnují:
Mechanismus sledovacích háčků definující statické sledovací body (popsané v tomto článku) byl začleněn společně s mnoha sledovacími body ve vnitřním jádře [core kernel].
Byla přidána nová bezzámková forma funkce get_user_pages():
int get_user_pages_fast(unsigned long start, int nr_pages, int write,
struct page **pages);
Detaily o tomto rozhraní lze nalézt v článkuSměrem k lepší škálovatelnosti přímého I/O s poznámkou, že první verze byly nazvány fast_gup(). (Také vizte práci na bezzámkové cache, která také byla začleněna.)Dlouho diskutovaný patch mmu-notifikátorů byl začleněn. Notifikátory umožňují externím jednotkám správy paměti (které jsou k vidění v některých grafických kartách nebo virtualizovaných hostech) sdělit informace o rozhodnutí, která provedl vnitřní kód správy paměti.
Přibyl nový framework pro ladění inicializace paměti v době bootu; také je v kódu "několik základních obranných opatření" zamýšlených k prevenci těžko laditelných problémů bootu.
Nová funkce:
int object_is_on_stack(void *obj);
vrací pravdivou hodnotu, pokud je objekt, na který je ukazováno, na současném jaderném zásobníku.
Nové makro pro vypisování varování:
WARN(condition, format, ...);
Je velmi podobné WARN_ON() v tom, že vyprodukuje kompletní oops výpis; rozdílem je přidaný formát a argumenty ve stylu printk().
Nová pomocná funkce:
int flush_work(struct work_struct *work);
čeká na dokončení specifické úlohy v pracovní frontě.
dma_mapping_error() a pci_dma_mapping_error() mají nové prototypy:
int dma_mapping_error(struct device *dev, dma_addr_t dma_addr); int pci_dma_mapping_error(struct pci_dev *hwdev, dma_addr_t dma_addr);
V obou případech získaly nový argument, který specifikuje, pro které zařízení se mapování provádí.
Je zde pár nových funkcí pro radix stromy:
unsigned int radix_tree_gang_lookup_slot(struct radix_tree_root *root,
void ***results,
unsigned long first_index,
unsigned int max_items);
unsigned int radix_tree_gang_lookup_tag_slot(struct radix_tree_root *root,
void ***results,
unsigned long first_index,
unsigned int max_items,
unsigned int tag);
Jsou užitečné pro vyhledávání několika položek v jednom volání.
Konstruktory slab cache již nemají za argument ukazatel přímo na cache; místo toho přebírají jeden void * ukazatel na samotný objekt.
Dlouhý seznam ioctl() callbacků Video4Linux2 byl přesunut do vlastní struktury (struct v4l2_ioctl_ops), na kterou ukazuje člen ioctl_ops struktury struct video_device.
Nyní začíná dlouhý úkol najít a odstranit všechny chyby v tomto novém kódu. Jestliže vydrží obvyklý postup, bude tento proces trvat okolo dvou měsíců, což naznačuje, že 2.6.27 můžeme očekávat někdy v říjnu.
Jedním z největších problémů při vývoji jádra je potýkání se se souběžností. V systému, kde se může dít víc než jedna věc naráz, je vždy nutné dávat pozor na to, aby se několik vláken navzájem neovlivňovalo a nepoškodilo systém jako celek. Stejným způsobem, jakým jsou dvě silnice nebezpečnější, když se protínají, připojování dvou procesorů ke stejné paměti značně zvyšuje jejich potenciál vytvořit chaos.
Cestovatele ve Spojených státech nezřídka pobaví (nebo naštve) často preferované řešení souběžnosti silnic: vložení semaforů. Takový semafor (pokud ho někdo nepřehlédne) eliminuje možnost mnoha nepříjemných souběhů na křižovatkách, ale za cenu ztráty výkonnosti: provoz přes křižovatku musí často zastavit a čekat. Toto řešení také uboze škáluje; když do jedné křižovatky přidáte víc silnic (nebo cest s různými směry), každá z nich zažívá víc červené.
V programování jádra je první nástroj pro řízení souběžnosti - zámky v různých formách - přímo analogický k semaforům. Jméno pro běžné zamykací primitivum - semafor - nebylo vybráno náhodou. Zámky vynucují exkluzivní přístup k jadernému zdroji stejným způsobem, jakým semafor vynucuje exkluzivní přístup ke křížení, a s mnoha stejnými náklady. Když příliš mnoho procesorů čeká na stejný zámek, výkonnost systému jako celku může výrazně trpět.
Pro řešení problémů se škálovatelností při použití zámků existují dva přístupy. Po mnoho let poté, co vyšlo jádro 2.0, byly tyto problémy řešeny vytvářením menších zámků, z nichž každý platil pro menší zdroj. Zmnožování [proliferation] zámků je efektivní tím, že snižuje šanci, že budou dva procesory zkoušet získat stejný zámek ve stejném čase. Díky tomu, že to funguje tak dobře, vedl tento přístup v linuxovém jádře k vytvoření tisíců zámků.
Zmnožování ale má svá omezení. Přidávání zámků zvyšuje komplexitu; konkrétně se se zvyšujícím počtem zámků zvyšuje šance na vytvoření příležitostného deadlocku. Deadlockům se lze vyhnout opatrným dodržováním pravidel získávání zámků, konkrétně pořadím, ve kterém jsou získávány. Nikdo ale nikdy nebude schopen vyřešit - a zdokumentovat - správné relativní pořadí zamykání pro tisíce zámků. Jaderní vývojáři tedy musí vystačit s pravidly pro některé z nejvýznamnějších zámků a bdělostí nástroje lockdep, který hledá zbývající problémy.
Druhý problém se zmnožováním zámků se obchází obtížněji. Získání zámku vyžaduje zápis hodnoty do místa ve sdílené paměti. Každý procesor, který získá zámek, musí tuto hodnotu změnit, což způsobí, že tento procesor získá exkluzivní přístup k řádku v cache, který tuto proměnnou zámku uchovává. Řádky v cache často využívaných zámků poté létají systémem způsobem, který negativně ovlivňuje výkonnost, i když žádný procesor nemusí čekat, až jiný uvolní zámek. Přidávání více zámků tento problém nevyřeší; místo toho se jenom vytvoří více poskakujících řádek v cache a věci se zhorší.
S tím, jak roste množství procesorů, cesta k pokračování škálovatelnosti nesmí zahrnovat hromadné vytváření nových zámků; místo toho vyžaduje odstranění zámků na cestách, které jsou nejdůležitější pro výkonnost kódu. A to je to, k čemu vede tento sáhodlouhý úvod: jádro 2.6.27 bude zahrnovat některé změny od Nicka Piggina, které implementují bezzámkové operace v některých důležitých částech subsystému virtuální paměti. A ty zase povedou k rychlejší práci víceprocesorových systémů.
První z těchto změn je nová funkce pro získání přímého přístupu k uživatelským stránkám v jádře:
int get_user_pages_fast(unsigned long start, int nr_pages, int write,
struct page **pages);
Tato funkce pracuje v podstatě podobně jako get_user_pages(), ale výměnou za některá omezení ve svém fungování je schopna dělat svou práci bez získávání semaforu mmap. To obratem může vést k 10% zvýšení výkonnosti při "vícevláknové databázové zátěži". Detaily o tom, jak tato funkce pracuje, jsou popsány v březnových Jaderných novinách (i když tenkrát se funkce nazývala fast_gup()), takže je zde nebudeme opakovat.
Další velká změna je sada patchů, na které Nick pracoval nějaký čas: bezzámková cache stránek. Tato cache v paměti udržuje kopie stránek ze souborů na disku; jejím účelem je vylepšit výkonnost minimalizací diskového I/O. Vyhledávání stránek v cache stránek je běžná aktivita; následuje po I/O se soubory, selhání stránek a dalších. Musí tedy být rychlá. V jádrech 2.6.26 má každé mapování (každé spojení mezi cache stránek a specifickým souborem někde v souborovém systému) svůj vlastní zámek. Procesory tak obvykle nesoupeří o zámky, pokud nepracují se stejným souborem. Zámky pro soubory, ke kterým se přistupuje často (například sdílené knihovny), ale pravděpodobně skáčou mezi procesory.
Většina operací s cache je vyhledávání - operace pouze pro čtení, která nedělá žádné změny. Při vyhledávací operaci zámek chrání několik aspektů tohoto úkolu včetně:
Daná stránka v mapování musí být vyhledávána v radix stromu mapování, aby našla své umístění v paměti (pokud je).
Jestliže je stránka přítomna v cache stránek, musí se zvýšit její počet odkazů [reference count] tak, aby nebyla odstraněna do doby, než kód provádějící hledání dodělá to, co potřebuje dodělat.
Radix strom sám je komplikovaná datová struktura; musí být chráněna před změnami, dokud se provádí vyhledávání. Tato ochrana je v částech kódu radix-stromů kritických pro výkonnost zajištěna (1) nějakými pravidly o tom, kdy mohou být volány a (2) použitím čtení-kopírování-aktualizace [read-copy-update, RCU]. Výsledkem je, že vyhledávání v radix stromu je možné bezzámkovým způsobem.
Stále je zde ale problém: daná stránka může být z cache stránek odstraněna (nebo jednoduše přesunuta) mezi kroky (1) a (2) výše. Kdyby se to stalo, druhý krok zvýší počet odkazů stránce, která teď náleží jinému mapování, a vrátí nesprávný ukazatel. Jaderní vývojáři díky mnohaletým zkušenostem přišli na to, že pády systému způsobené poškozením dat značně snižují výkonnost. Skutečná škálovatelnost tedy vyžaduje, aby k tomu nedošlo; proto ten semafor mapování, který brání změnám cache, dokud se počet odkazů správně neaktualizuje.
Nick pozoroval zajímavou věc: ve skutečnosti nezáleží na tom, jestli je inkrementován nesprávný počet odkazů, pokud se zajistí, že je specifické mapování stránky poté stále platné. Výsledkem je nová nízkoúrovňová funkce cache stránek:
int page_cache_get_speculative(struct page *stranka);
Jestliže má daná stranka počet odkazů nulový, byla odstraněna z cache stránek; v takovém případě funkce vrátí nulu a počet odkazů se nezvýší. Jestliže je ale počet odkazů nenulový, zvýší se a je vrácena nenulová hodnota.
Inkrementace počtu odkazů na stránku zabrání odstranění této stránky i jejímu přesunu, dokud se počet nesníží zpět na nulu. Jaderný kód, který inkrementoval počet odkazů specifické stránky, tak má jistotu, že stránka zůstane ve svém současném stavu. V případě cache stránek může kód získat spekulativní odkaz na stránku nalezenou v radix stromu mapování. Neví ale ještě, jestli skutečně dostal odkaz na stránku, kterou hledal - mezi vyhledáváním v radix stromě a získáním odkazu se mohlo něco stát. Proto se musí přesvědčit - poté, co byl získán odkaz - jestli jde o správnou stránku. Jestliže ne, uvolní odkaz a zkusí to znovu. Nakonec buď najde správnou stránku, nebo ověří, že relevantní část souboru v paměti není přítomna.
Bezzámková operace vynucuje o něco pečlivější přístup na straně kódu znovuzískávání stránek, který se snaží snížit počet odkazů na stránku na nulu, aby mohl stránku odstranit. Vzhledem k tomu, že nyní okolo počtu odkazů není žádné zamykání, znovuzískávající kód musí počet nastavit na nulu a zároveň atomickým způsobem testovat, že ho nikdo jiný neinkrementoval. To je účelem funkce atomic_cmpxchg, která operaci provede jenom v případě, že nekoliduje s jiným procesorem. Díky tomu, že page_cache_get_speculative() neinkrementuje počet odkazů, pokud je nulový, znovuzískávající kód ví, že snížením této hodnoty na nulu získává exkluzivní kontrolu stránky.
Konečným výsledkem toho všeho je, že z vnitřku cache stránek byla odstraněna sada zamykacích operací a zvýšena škálovatelnost tohoto kódu. Samozřejmě je zde cena ve formě záludnějšího kódu s komplexnější sadou pravidel, která je třeba dodržovat. Je ale šance, že takového kódu uvidíme víc s tím, jak se bude počet procesorů v našich systémech zvětšovat.
Správce bezdrátového síťování v jádře John Linville načrtl první den na letošním Ottawa Linux symposiu minulost, přítomnost a budoucnost linuxového bezdrátového stacku. Jeho prezentace obsahovala informace v rozpětí od prvních snah, které byly pro Linux bolavým místem, po budoucnost, ve které je pravděpodobné, že Linux bude mít podporu pro některé vlastnosti před tím druhým OS. Přitom se podíval na některé problémy, kterým bezdrátová podpora v Linuxu čelí, včetně účasti prodejců, uspávání a probouzení a záležitostí ohledně právních předpisů pro její používání.
John je správcem linuxového bezdrátového síťování dva a půl roku od doby, kdy ho do této práce rekrutovali David Miller a Jeff Garzik. Když ji převzal, byla podpora pro bezdráty v dezolátním stavu, obsahovala různé soupeřící stacky pro podporu různého hardwaru. Uživatelé čelili mnoha obtížím ve snaze věci rozchodit, když jenom chtěli, aby jejich hardware fungoval, řekl John. Od té doby se věci hodně změnily
Původní bezdrátový hardware byl to, co se nazývá "plně MAC hardware", kde je implementace bezdrátových protokolů zajišťována hardwarem obecně ve firmwaru. Ovladače zjišťovaly, že tato zařízení se v systému objevovala jako obvyklé drátové ethernetové adaptéry, které potřebovaly nějakou speciální konfiguraci, jako je nastavení SSID a podobné. Protože hardware vynucoval různé požadavky, co se předpisů týče, výrobci obecně spolupracovali s komunitou, aby byl hardware podporován.
To vše se změnilo s úsvitem "soft MAC hardwaru" - který John přirovnal k winmodemům - kde většinu protokolu implementuje CPU. Pro výrobce je to levnější řešení, ale vyžaduje 802.11 stack v jádře. Pro podporu Intel Centrino hardwaru vyšly ovladače ieee80211, ale ty podporovaly jenom těch pár zařízení. Johannes Berg přidal ovladač ieee80211softmac, který přidal podporu nějakého dalšího hardwaru, ale to byla jenom improvizace. Od té doby, řekl John, si lidé uvědomili, že jít touto cestou byla trochu chyba.
Příchod stacku Devicescape. Šlo o 802.11 stack pro Linux bohatý na vlastnosti, který byl u vývojářů populární. Poté, co byly vyřešeny některé problémy se zamykáním a SMP, byl začleněn do 2.6.22 jako ovladač mac80211. Jakmile se tak stalo, bezdrátové ovladače ho začaly používat tak, že když John ukazoval graf současných ovladačů, téměř všechny z nich používaly mac80211. Použít kód mac80221 pro nás byla spása.
Jeden významný ovladač, který mac80211 nepodporuje, je ovladač libertas pro OLPC. Na rozdíl od ostatních současných zařízení je plně MAC se speciálními požadavky. Má podporu pro režimy úspory energie, které v mac80211 ještě neexistují. Protože je to zařízení pro mesh-síťování, které se účastní přeposílání síťového provozu, i když je systém vypnut, má požadavky, které ještě nejsou podporovány.
Ovladače, na kterých se pracuje, bylo další téma, kterému se John věnoval. Některé z nich potřebují vývojáře, kteří by na nich pracovali, specificky Airgo čipset a Atmel USB čipset. Ohledně ovladačů pro čipset TI se objevily nějaké otázky na proces reverzního inženýrství a budou potřebovat nějakou právní prohlídku podobnou té, kterou dělalo SFLC pro ath5k. Marvell sponzoruje vývoj ovladače založeného na mac80211 pro svůj hardware. Tento ovladač by také mohl podporovat 802.11n, který umožňuje větší dosah a vyšší rychlosti než 802.11 současné generace.
S pomocí dat z LWN se John podíval na úroveň aktivity bezdrátového vývoje v Linuxu. Byl překvapen, když poznamenal, kolik z jádra 2.6.26 prošlo přes tento laptop. S použitím svého podepsáno-kým [signed-off-by] jako proxy pro commity bezdrátového LAN zjistil, že 4,3 - 5,6 % jaderných commitů v posledních třech vydáních (.24 - .26) bylo pro bezdráty. V každém jádře bylo bezdrátové síťování buď na pátém, nebo na čtvrtém místě v počtu commitů.
Projekt compat-wireless-2.6 má za cíl podporu novějšího hardwaru ve starších jádrech. Protože se lidé obávají používat jádra z kernel.org nebo jejich distribuce podporuje starší jádro - ale chtějí používat nejnovější hardware - projekt backportuje bezdrátové ovladače až do jádra 2.6.21. Jedná se o sadu skriptů a patchů, které se překládají proti uživatelovu jádru. Bohužel, projekt možná nebude fungovat příliš dlouho, protože vícefrontové změny, které byly začleněny do 2.6.27, mohou změnit ovladače natolik, že nebude možné je backportovat.
Na vrcholu seznamu nových vlastností je odstranění bezdrátových rozšíření [wireless extensions] ve prospěch nového mechanismu cfg80211. Podle Johna nikdo nemá rád bezdrátová rozšíření a nikdo nemá rád existující nástroje. Bezdrátová rozšíření mají nejasnou sémantiku, mohou mít problémy se souběhy a protože jsou implementována pomocí ioctl() volání, podporují duplikaci kódu v mnoha v ovladačích. cfg80211 přinese mnohem čistší API, společně s opravou několika existujících chyb, jako je omezení na 31 znaků pro SSID.
Režim přístupového bodu (AP) je další vlastnost, která je na dohled. AP typicky používají podobný nebo stejný hardware, jaký je v bezdrátových MAC. Pro soft MAC hardware je jediné, co je potřeba pro AP režim, podpora na straně CPU, která se dostane do mac80211. Tam také přichází mesh síťování popularizované projektem OLPC. Cozybit poskytl implementaci, která Linuxu umožní mít vlastnost, která ve Windows není dostupná.
Oblasti, které jsou zapotřebí, ale na kterých se nepracuje, byly v Johnově prezentaci další na řadě. Podpora pro uspávání a probouzení je v mac80211 vadná kvůli záležitostem ohledně správy spojení. Protože mac80211 probouzení a uspávání nezná, ovladače ho musí obcházet vlastním odregistrováním a novou registrací, což může být pomalé. Přidání podpory pro uspávání je na seznamu, stejně tak podpora režimu úspory energie.
John pokračoval zmínkou o třech velkých problémech, které jsou z větší části mimo kontrolu bezdrátových hackerů: licencování firmwaru, účasti výrobců a záležitostí ohledně předpisů. Protože ovladače pro Windows přicházejí s firmwarem v ovladači, mnoho výrobců hardwaru nelicencuje blob firmwaru odděleně. To znamená, že není jasné, co s těmito bloby lze dělat. Někteří výrobci - specificky byli zmíněni Intel a Ralink - poskytují pro svůj firmware liberální licence. Uživatelé jsou vyzývání k tomu, aby volili peněženkou a kupovali zařízení, která buď firmware nepoužívají, nebo která mají jasnou a pro svobodný software příznivou licenci.
Další kritérium při rozhodování, kterého výrobce podpořit, je, jestli spolupracuje s komunitou. Většina výrobců kromě Broadcomu pracuje s bezdrátovými vývojáři tak, že jim poskytuje dokumentaci a/nebo zdrojový kód. Někteří dokonce poskytují vývojáře zaměřené na práci na ovladačích pro Linux - Intel byl první, ale jak Atheros (který právě vydal ovladač pro svůj ath9k hardware), tak Marvell začali dělat totéž.
Vládní nařízení o tom, co se smí a nesmí dělat v nelicencovaných frekvenčních pásmech pro bezdrátové síťování, jsou další obavou, kterou výrobci často citují, když odmítají spolupracovat s komunitou. Jejich obavy bohužel nejsou nepodložené, neboť je to výrobce, od koho se očekává, že zajistí, aby zařízení vyhovovalo předpisům. Pro tyto firmy by nedodržování mohlo znamenat velké ztráty. Jak ale John zdůraznil, většina výrobců našla způsob, jak linuxové ovladače podporovat.
V odpovědi na otázku John řekl, že většina WiMAX a 3G bezdrátových zařízení jsou plně MAC, takže by měly být malé nebo žádné obavy z předpisů, což znamená, že podpora pro Linux by neměla být velký problém - do doby, než se objeví soft MAC zařízení. Ve zkratce: linuxové bezdrátové síťování ušlo dlouhou cestu, ale ještě zbývá hodně udělat. Vypadá to, že bezdrátový tým je na tento úkol připraven.
11.9.2008 14:42
stativ | skóre: 54
| blog: SlaNé roury
11.9.2008 20:54
Pavel Půlpán | skóre: 22
| Trutnov
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.