Jaderné noviny - 25. 10. 2006

20. 11. 2006 | Robert Krátký | Jaderné noviny | 4533×

Aktuální verze jádra: 2.6.19-rc3. Používání sparse pro ověření endianity. GPL symboly a ndiswrapper. Síťové kanály. /dev/kvm.

Aktuální verze jádra: 2.6.19-rc3

Aktuální předverze je 2.6.19-rc3, vydaná 23. října. Obsahuje poměrně dost oprav, ale vypadá to, že dochází ke zpomalení přílivu. Vizte podrobnosti v dlouhém changelogu.

Od vydání 2.6.19-rc3 bylo začleněno jen velmi málo patchů - a většinou to byly opravy.

Adrian Bunk udržuje seznam regresí v 2.6.19, který je překvapivě krátký.

Aktuální verze -mm stromu je 2.6.19-rc2-mm2. Mezi nedávné změny patří přidání stromu s I/OAT DMA engine, velká sada x86 patchů, sdílení tabulek stránek u velkých TLB stránek, sada knihovnových funkcí pro obracení bitů v hodnotě a pokračující práce na ovladači tty.

Používání sparse pro ověření endianity

Vývojáři rádi žertují o tom, jakou má Al Viro v LKML hrůzu nahánějící pověst. Ve skutečnosti se tam však poslední dobou příliš neprojevoval. To ale neznamená, že by se stal vývojářem Plan 9 na plný úvazek. Místo toho pracoval na vylepšování nástrojů pro statickou analýzu používaných pro objevování chyb, než na ně doplatí nějaký uživatel.

Nedávno vyústila tato práce v dlouhou sérii patchů začleněných do hlavního jádra - téměř všechny byly vedeny jako "označení endianity". Patche povětšinou měnily deklarované typy u různých funkcí, proměnných a členů struktur. Nové typy možná mnoho lidi nepozná, protože jsou relativně nové - i když na zas tak moc; byly zavedeny v 2.6.9. Jde o __le16, __le32, __le64, __be16, __be32 a __be64.

Cílem je pokusit se vyznačit, jestli je daná (bezznaménková) celočíselná hodnota big-endian (nejvýznamnější bajt první) nebo little-endian. Ve většině případů není u programování - dokonce ani v jádře - endianita důležitá; věci prostě fungují, aniž by se jimi musel programátor zvláště zabývat. Jaderný kód však musí často pracovat s daty kódovanými pomocí určitého řazení bajtů. Příkladem jsou třeba síťové protokoly, datové struktury souborových systémů na disku a registry zařízení. Obecně platí, že pokud jádro pracuje s daty řazenými jiným než nativním způsobem, musí bajty nejprve prohodit, aby odpovídaly tomu, co očekává procesor. Když se tak nestane, může docházet k nejrůznějším podivným chybám.

Existuje dost maker, která s tímto úkolem mohou pomoci. Například klasická funkce jako htonl(), která převádí 32bitové celé číslo od hostitele na "síťové" (big-endian) řazení. Pro obecnější použití nabízí jádro makra jako __le32_to_cpu(), které převede little-endian 32bitovou veličinu na řazení vyžadované procesorem. Tato makra umožňují portování kódu; na systémech, kde je to potřeba, provedou požadovanou změnu a ve zbývajících případech prostě zmizí.

Konverzní funkce však fungují pouze tehdy, když si je programátor vzpomene použít. V případě jejich nepřítomnosti vypadají hodnoty s nenativním řazením jako celá čísla a chybu nelze zachytit, dokud něco nebouchne. A to se vůbec nemusí stát původnímu vývojáři; kód může fungovat bezchybně, dokud se jej někdo nepokusí spustit na jiné architektuře - pak jdou věci do háje.

Bylo by fajn zachytávat chyby endianity dříve. A to je účel typů jako __be32; umožňují programátorovi u dat vyznačit určité řazení hned při prvním vstupu do systému. Pak už může příhodně chytrý nástroj zkontrolovat kód, který s daty manipuluje, a zajistit, aby je nemíchal s nativně řazenými daty, nezkoušel na nich aritmetiku atd. Jakmile je vše označeno, mohou být odchyceny celé třídy chyb ještě než by bylo jádro nabootováno. A to nemůže být nic špatného.

Ten "příhodně chytrý nástroj", který práci provede, je "sparse". Statický kontrolor, který původně napsal Linus Torvalds. Systém pro sestavení jádra má podporu sparse zabudovanou, takže je snadné hledat chyby. Složité je ten nástroj získat. Balíčky poskytuje jen málo distribucí, takže případní uživatelé si musí kód zkompilovat sami.

Pravým zdrojem sparse je git repozitář na kernel.org. Pomocí gitu stačí:

    git clone  git://git.kernel.org/pub/scm/devel/sparse/sparse.git

A jednoduché "make" ve výsledném adresáři vám dá funkční binárku sparse. Nástroj se mění tak často, že je pravděpodobně vhodné pravidelně aktualizovat z repozitáře. Nemáte-li po ruce git, můžete si stáhnout tarball ze stránky Davea Jonese.

Jakmile máte sparse nainstalovaný, je velmi snadné jej pustit na zdrojové kódy jádra. V adresáři se zdrojáky proveďte:

    make C=2

Parametr C=2 způsobí, že bude sparse spuštěn na každý .c soubor; použijete-li C=1, budou zkontrolovány pouze soubory, které musí být zkompilovány. Kontrola endianity vyžaduje ještě jeden parametr:

    make C=2 CF=-D__CHECK_ENDIAN__

Počet varování, která takový příkaz vypíše, může být dost vysoký - ale jak se Al propracovává kódem, tak pomalu mizí.

Velmi se doporučuje kontrolovat pomocí sparse veškerý posílaný kód - je to jeden z kroků uvedených v seznamu kroků před odesláním patche dodávaném s jádrem. Používání sparse je však pořád spíše výjimka než pravidlo. Ale je to velmi snadné a velmi užitečné - takže skutečně není důvod kód nezkontrolovat. Je koneckonců daleko lepší, když za vás hloupé chyby odhalí počítač v soukromí, než když je vytroubíte do světa.

GPL symboly a ndiswrapper

Ndiswrapper je modul, který umožňuje natažení NDIS ovladačů z Windows do linuxového jádra. Používá se na systémech s hardwarem (hlavně bezdrátové síťové adaptéry), který linuxové ovladače nepodporují; natažením ovladače z Windows umožní ndiswrapper používání takového hardwaru. Ale protože jde o mechanismus vytvořený k tomu, aby do linuxového jádra cpal ty nejproprietárnější binární moduly, vždycky vzbuzoval trochu nedůvěru.

Jednou ze změn, které se dostaly do jádra 2.6.16, byla explicitní kontrola, jestli není přítomen modul ndiswrapper. Je skutečně velmi explicitní:

    if (strcmp(mod->name, "ndiswrapper") == 0)
	add_taint_module(mod, TAINT_PROPRIETARY_MODULE);

Tento test znamená, že jakýkoliv systém s nataženým modulem ndiswrapper bude mít nastaven příznak "proprietární modul". A v důsledku toho je dost nepravděpodobné, že by vývojáři jádra byli ochotni pomoci s problémy, které se objeví při provozu takového jádra. Ale protože 2.6.16 bylo vydáno v březnu, mohl by se člověk divit, že se autor ndiswrapperu Giridhar Pemmasani ozval až teď. Ukázalo se, že vývojáři celou věc posunuli s vydáním jader 2.6.19-rc ještě o krok dále.

Jádro už dlouho modulům exportuje symboly ve dvou režimech. Symboly exportované s EXPORT_SYMBOL jsou k dispozici všem nataženým modulům, kdežto ty, které jsou exportovány s EXPORT_SYMBOL_GPL, mohou být používány pouze těmi, které o sobě tvrdí, že mají GPL kompatibilní licenci. Takové rozlišení ndiswrapperu nikdy nevadilo, protože je licencován GPL. Takže i po přidání explicitní kontroly mohl být ndiswrapper natažen a normálně fungovat.

Do 2.6.19 byl ale začleněn patch od Florina Mality, který mírně mění určování GPL symbolů. Místo kontrolování, jestli má modul GPL kompatibilní licenci, ověřuje nový kód, jestli má modul nastaven bit "proprietární modul". Ve většině případů je výsledek stejný. Pro ndiswrapper to však znamená, že GPL symboly, ke kterým měl dříve přístup, už nejsou k dispozici. A to znamená, že ndiswrapper už do jádra nelze natáhnout. Autor modulu si myslí, že to není fér, protože ndiswrapper je licencován GPL.

Alan Cox odpověděl takto:

EXPORT_SYMBOL_GPL() se používá k zaručení toho, že jde naprosto jistě o neveřejný symbol. EXPORT_SYMBOL exportuje symboly, které by veřejné mohly být, ale i tak platí pravidlo o odvozené práci. Označíš-li ovladač jako GPL, pak je mu povoleno používat _GPL symboly. Ale pokud je používá, nemůže pak jít a natáhnout nějaký jiné ne-GPL modul, aniž by se lidi nepozastavili nad tím, jestli je to správné.

Základní idea dává smysl: GPL omezení nejsou příliš platná, lze-li je jednoduše obejít natažením zprostředkovacího modulu. Zůstává však otázkou, jestli byl v tomto případě vybrán ten správný terč.

Účelem GPL exportů je zabránit vytváření proprietárních produktů odvozených od jádra. Těžko si představit argumentaci, podle které by mohl být typický NDIS modul odvozeným produktem linuxového jádra. Tyto ovladače jsou psány pro úplně jiný operační systém lidmi, kteří pravděpodobně se zdrojovými kódy Linuxu nikdy nepřišli do styku. Na rozdíl od jiných druhů proprietárních modulů jsou NDIS ovladače zcela jasně nezávislé práce. Nemusí se nám líbit představa natahování takového ovladače do jádra, ale těžko tvrdit, že by to nějak zakazoval copyrightový zákon.

Také se zdá divné trestat modul za to, že má určité jméno. Například natahování modulu MadWifi, který také využívá binární komponentu, kontrolováno není. Obyčejné přejmenování modulu by tuto kontrolu obešlo a vývojářům jádra by pár měsíců trvalo, než by zase díru zalepili. Dalo by se představit, že si zarputilý programátor vymyslí náhodné jméno při každé kompilaci modulu, což by tuto kontrolu porazilo zcela. Autora ndiswrapperu však podobné hry nelákají; místo toho se snažil s jadernou komunitou spolupracovat. Modul sám už přidává ne-GPL příznak, kdykoliv je natažen NDIS ovladač.

Jenže vývojářům se asi tuto změnu stáhnout nechce. To staví autora ndiswrapperu do pozice, kdy by musel buď celý modul předělat, aby nepoužíval GPL symboly, nebo vymyslet jiný způsob, jak zase umožnit jeho natahování. Možná to není to nejlepší řešení, ale ndiswrapper má nezanedbatelné množství uživatelů, kteří jej potřebují, aby mohli provozovat v Linuxu svůj hardware.

Síťové kanály

Na frontě síťových kanálů je už nějakou dobu klid. Ale to neznamená, že by se nic nedělo. Důkazem budiž skutečnost, že Jevgenij Poljakov přišel s novou verzí, o které tvrdí, že dokáže daleko lépe škálovat než současná implementace síťování.

Tato verze síťových kanálů se na problém zaměřuje více z pohledu uživatelského rozhraní a jadernou infrastrukturu nechává na jindy. Přidává proto nové systémové volání netchannel_control(), které propojuje funkci kanálů s uživatelským kódem. netchannel_control() je další z multiplexních rozhraní, která Evgeniy zjevně preferuje; funguje jako ioctl() volání s třemi hlavními operacemi:

• NETCHANNEL_CREATE vytváří nový kanál vázaný na dané lokální a vzdálené adresy. Je tam také specifikace "typy", která popisuje, jak kanál pracuje s uživatelským prostředím.
• NETCHANNEL_SEND odešle paket do sítě.
• NETCHANNEL_RECV blokuje, dokud není přijat příchozí paket, pak jej předá uživatelskému prostředí.

Jaderná strana implementace je prozatím jednoduchá a jasná: volání NETCHANNEL_SEND alokuje strukturu sk_buff a naplní ji uživatelskými daty pomocí copy_from_user(); paket je pak obvyklým způsobem odeslán tam, kam patří pomocí síťového stacku. Návrh předpokládá budoucí přidání dalších, rychlejších způsobů přenášení dat - například pomocí Evgenijova mechanismu síťového alokátoru.

Aktuální patch přidává síťový stack v uživatelském prostoru, který využívá nový mechanismus síťových kanálů. V současné době prý zvládá TCP a UDP a očekává se množství dalších funkcí; aplikacím je prezentováno "socketu podobné rozhraní". Zatím na tuto sadu patchů nikdo nereagoval, takže těžko říci, jestli ostatním vývojářům síťování připadá rozumná nebo ne. Evgenij však vypadá jako vytrvalý člověk, takže se s tímto kódem asi ještě setkáme.

/dev/kvm

Tato velká sada patchů (KVM), kterou poslal Avi Kivity, by mohla trochu probrat oblast virtualizace. Jedná se o implementaci virtualizačních rozšíření od Intelu (podpora od AMD je prý na spadnutí), která by Linuxu umožnila snadný provoz virtuální strojů bez potřeby supervizora jako je Xen. Mělo by se však zmínit, že patch obsahuje dost kódu z Xenu.

S tímto patchem implementuje Linux nové zařízení zvané /dev/kvm. Otevřením tohoto zařízení dojde k vytvoření virtuálního stroje se sadou ioctl() volání. Jedna z důležitých operací pro tento stroj vytváří virtuální procesory; v současné době je podporován pouze jeden virtuální procesor. Jiná operace přidává klientskému stroji paměťovou oblast. Paměť je organizována do "slotů" modelovaných podle skutečných slotů na základní desce; hodí se pro nastavování struktur jako je paměťová díra na 640K, která pořád na některých PC systémech je. A další operace umožňují vytváření záznamů v tabulce stránek na klientu, manipulaci s registry virtuálního stroje, zachycování operací s vyššími právy a vlastní spouštění programů v klientu. Je poskytnuta také sada debugovacích operací.

O patch je docela zájem; vypadá to, že by mohlo jít o (relativně!) snadný způsob přidání podpory hardwarové virtualizace do jádra. Jeden z komentářů si všiml podobnosti této funkčnosti s prací, která se týkala podpory "součinných procesních jednotek" (SPU - synergistic processing units) na architektuře Cell. Podpora SPU, která je v jádře od 2.6.16, používá k ovládání klientů místo ioctl() speciální souborový systém. Spojení těchto subsystémů by tedy pravděpodobně znamenalo i změnu rozhraní /dev/kvm. Tato sada patchů se proto ještě před případným začleněním může dost změnit.

       

Komentáře

[Thunder.m]

No teda to s ndiswrapperem je fakt hodně drsný, místo toho aby vývojáři pomohli rozšiřovat funknčí HW v Linuxu záměrně komplikují rozchození HW, je to fakt uplně ujetý. Čeho se dočkám v dalších jádrech? To že mi nepujde natahnout modul nvidia.ko? :)))

[Mr. Zdeeck]

Souhlasim s Vami do pismene. Posledni dobou (vlastne uz docela dlouho, zacalo to uz s pwc.o) zasahuje politikareni GPL-istu do skutecne pouzitelnosti kodu az moc. Fundamentalismus je nebezpecny sam o sobe, nezalezi za kterou stranou stoji.

[pic]

jasně a na příkladu novellu a microsoftu je jasně vidět, že čistota licencí je zbytečnost, vždyť po tom nikdo nejde a Ballmer si vyskakuje o tom, že linux porušuje pravděpodobně i jeho dobré trávení jen tak ze srandy.

[MoB]

Taky mám pocit, že to začíná být hodně ujeté. A binární driver nvidia by prý (!) - kdyby se uplatňovaly důsledně ty ci*oviny kolem GPL - neměl fungovat už teď. Někde jsem to četl... už nevím kde, ale děsí mě to.

[Michal Vyskočil]

Až na to, že ty ci*oviny kolem GPL se v tomto případě týkaly distribuce, nikoliv vývoje, nebo používání binárních ovladačů od nvidie .

[xvasek]

To není pravda. GPL neomezuje použití, modifikace, ani spouštění softwaru. Vztahuje se (skoro) výhradně na povinnosti při distribuování software. To, že si někdo natahuje do jádra u sebe doma nějaký proprietární modul, je pro GPL asi stejně důležité, jako barva mých spoďárů. Pokud nechci takový slepenec distribuovat dál, jsme z pohledu GPL já i vývojáři daného proprietárního modulu čistí.

Problém ndiswrapperu je, že vlastně už samotný ndiswrapper je dílo odvozené od proprietárních ovladačů a proto vývojáři jádra nechtějí uznat licenci GPL pro tento projekt, přestože se modul jako GPL hlásí. IMHO je to sice pravda (že ndiswrapper nejde distribuovat jako GPL), ale na druhou stranu není od vývojářů jádra úplně fér, že jej už dopředu diskvalifikují pomocí jména modulu. Čisté řešení by bylo pro ndiswrapper zvolit jinou licenci a nepoužívat GPL symboly jádra.

[Mr. Zdeeck]

No jo, jenze mne rozesmiva uz formulace "GPL symboly". Deje se presne to, co na "komercni" strane spektra - kazda blbost se oznaci jako GPL (na druhe strane jako patent/intellectual property) a nakonec opravdu free je snad jenom informace o posledni zmene souboru. Vyhanet certa dablem proste neni moje oblibena strategie....

[xvasek]

Holt GPL už je taková - klade na distributora software nároky, které musí splnit. Pořád je možnost využívat "svobodnější" (např. BSD) licence, což taky v případě ndiswrapperu navrhuju. Nejde o to, aby se zakazovala tvorba pod vlastní licencí (třeba nVidia to umí), jde o to, aby se jako GPL nenazývalo něco, co GPL není.

[Michal Kubeček]

Proč (opakovaně) tvrdíte, že ndiswrapper není GPL? Autor ho pod touto licencí distribuuje a AFAIK plní všechny své povinnosti, ke kterým se touto licencí zavázal. Odmítl snad někomu poskytnout zdrojové texty?

[xvasek]

Protože druhý odstavec GPL říká, že:

[...]Tyto požadavky se vztahují k modifikovanému dílu jako celku. Pokud lze identifikovat části takového díla, které zřejmě nejsou odvozeny z programu a mohou být samy o sobě rozumně považovány za nezávislá a samostatná díla, pak se tato licence a její ustanovení nevztahují na tyto části, jsou-li šířeny jako nezávislá díla. Avšak jakmile tytéž části rozšiřujete jako část celku, jímž je dílo založené na programu, musí být rozšiřování tohoto celku podřízeno ustanovením této licence tak, že povolení poskytnutá dalším uživatelům se rozšíří na celé dílo, tedy na všechny jeho části bez ohledu na to, kdo kterou část napsal.

Pak je obecně interpretace taková, že ndiswrapper je část celku, kde druhou částí celku je binární ovladač (což je samozřejmě těžké dokázat). Pak by ovšem autor musel pro dodržení GPL nabídnout i zdrojáky těch ovladačů.

Jasně, že je sporné, jestli je nebo není wrapper odvozeným dílem - máme tady celkem jasný názor Alana Coxe, který si myslí, že to odvozené dílo je, já si to spíš myslím taky, u Linuse a Stallmana bych vsadil trenky, že by taky řekli, že je to odvozené dílo. Vy si možná myslíte, že ne...

[Michal Kubeček]

Pak je obecně interpretace taková, že ndiswrapper je část celku, kde druhou částí celku je binární ovladač

Řekl bych, že tohle byste u soudu obhajoval velmi těžko i s velmi zručným právníkem. Jestliže je ndiswrapper vytvořen autorem AA pro platformu PA, licencován licencí LA a distribuován kanálem CA, zatímco příslušný driver je vytvořen autorem AB pro platformu PB, licencován licencí LB a šířen kanálem CB (zcela nezávisle na ndiswrapperu), pak považovat jejich potenciální kombinaci (která vznikne až v počítači uživatele na základě jeho osobního rozhodnutí a jeho akce) za "celek" podléhající licenci LA, mi připadá hodně přitažené za vlasy.

[xvasek]

Pokud chcete tvrdit, že ndiswrapper funguje s ndis ovladači čistě náhodou (a že od jejich funkčnosti není odvozený), já Vám v tom určitě bránit nebudu...

[medulin]

Ale ndiswrapper nemusí přece fungovat jen s binárními ovladači. Ty ovladače můžou mít různou licenci i GPL. Co potom?

[J]

Jenze ndiswrapper je jen rozhrani, je to stejny, jako kdybych firme, ktera pro nas aktualne vyvyji rozhrani mezi IS a skladovym systemem rek, ze to jejich rozhrani vlastne bez naseho IS je nanic => je jeho soucasti => vztahuje se na nej licence IS => trebas jim ho nehodlam zaplatit.

Ndiswrapper je proste nejak definovane GPL rozrhrani. Uplne stejne bych moh dospet k tomu, ze wine nemuze byt preci GPL protoze je urceno ke spousteni cizich binarek, ktere GPL nejsou a bez nich je vlastne cele wine nanic.

[Michal Kubeček]

Než začnete polemizovat s čtyři dny starým příspěvkem, podívejte se, jestli už se celé nedorozumění dávno nevysvětlilo…

[Filip Jirsák]

Ale ndiswrapper je dílo odvozené od jádra, ne od binárních ovladačů, ne? Binární ovladače od ndiswrapperu rozhodně odvozené nejsou, protože je lze používat samostatně. Dokud je ndiswrapper distribuován bez binárních ovladačů, není s licencí problém. Byl by nějaký odkaz k tomu, že ndiswrapper je odvozen od binárních ovladačů?

[Michal Vyskočil]

Jenže ndiswrapper není odvozené dílo těch ovladačů, ale části jaderného API Windows. A ta afaik (zde se můžu mýlit) nestanovuje žádná omezení na licenci k odvozeným dílům. Takový Virtual Dub, nebo cygwin by v tom případě porušoval GPL také, protože bez Windows nefungují, jenže něco takového jsem ještě nikoho tvrdit neslyšel. Samotný ndis je GPL a fakt, že si uživatel pomocí něho nahraje neGPL kód nemění nic na jeho licenci.

Samozřejmě, autor puntičkář by ještě napsal nějaký dummy modul a tvářit se, že jeho kód primárně slouží pro jeho GPL ovladač a možnost provozu Windows ovladačů je prostě shoda okolností

Stejně je to například s ovladačem bcm43xx, což je mezivrstva mezi OS a firmware, který pod GPL rozhodně není a jeho nikdo podobným způsobem nepostihuje ... takových případů by se našlo více.

[xvasek]

Hmm, tak to si sypu popel na hlavu. Myslel jsem, že to vzniknulo klasicky tak, že se prostě vzal kopec ovladačů, které o sobě tvrdily, že fungují stejně, pak se okolo toho reverzním inženýrstvím udělal nějaký obal na míru těm ovaladčům a celé se to vydalo (bez těch ovladačů) jako ndiswrapper. Pokud je to takto, tak tady ze sebe dělám pěkné jelito...

[Michal Vyskočil]

Mám to vyčtené se stránek — ndiswrapperu This project implements Windows kernel API and NDIS (Network Driver Interface Specification) API within Linux kernel.. To znamená, že je ndiswrapper odvozený jak z Windows API, tak z Linuxu a proto je GPL licence v pořádku.

[Tomas Vesely]

Ale ndiswrapper preci neprikazuje pouzivat proprietalni moduly, natahuje proste natahuje windows binarky, a mezi nimi klidne muhou byt i GPL ovladace.

[xvasek]

Ano, je to obecný nástroj; původně jsem myslel že je to tool dělaný speciálně pro nějakých (řekněme) dvacet vytipovaných přesně daných uzavřených ovladačů. Moje chyba, příště si přečtu informace než budu prohlašovat svoje domněnky za jedinou pravdu. Ještě jednou omluva za mystifikaci.

[disorder]

ked neloaduje GPL, tak by mal nastavovat taint...

[Ladislav Sückr]

no ona na tom asi nebude AMD-ATI lépe

[michich]

Nepřístupnost GPL symbolů pro ndiswrapper byla neplánovaným důsledkem jednoho patche. Od verze 2.6.19-rc4 už by to mělo zase fungovat jako dřív. Takže buďte klidní, můžete si dál prasit svoje kernely binárním svinstvem.

[faugusztin]

Pre vas mozno binarne svinstvo, pre mnohych jedina moznost ako rozchodit svoj hardware.

[DjAARA]

Příště lépe vybírat HW a uvidíte, že to půjde i bez binárního nepořádku třetích stran.

Sám jsem se dlouho trápil s fglrx, ale to už je teď minulostí - byla to špatná volba, ale tenkrát jiný NTB se "solidní" GK nebyl . Přešel jsem na r300 a jsem spokojen. To k čemu potřebuji 3D akceleraci běží a když pomůžu vývoji tohoto ovladače, tak mě to bude jen a jen těšit.

[pic]

už s tímhle ovladačem funguje tv out?

[DjAARA]

Ten mi nefungoval ani s fglrx, takže je to na stejno . (pravda je taková, že jsem to ani moc neřešil)

[Peter Lehotsky]

Zato ostatnim (vetsine) fungoval dokonale, nebude to rukama?

[DjAARA]

Jak říkám, neřešil jsem to. Televizi potkám tak jednou do měsíce a tím pro mě jakékoliv její využití nepřipadá v úvahu.

[michich]

Ještě je možnost takový hardware nekupovat.

[Thunder.m]

Prosil bych nějakou grafiku která má ovladače opensource a má kompletní podporu opengl 2.1 i v ovladačích, děkuji, prosil bych nějakou bezdrátovou kartu která podporuje 5GHz a neobsahuje žádné binární svinstvo, děkuji dvakrát!

[Robert Krátký]

A já bych prosil tepelnou elektrárnu bez zplodin, iPod bez DRM a cigarety bez kouře.

Tebe snad někdo či něco nutí mít a používat právě takovou grafickou nebo bezdrátovou kartu? Je to otázka priorit.

[Non_E]

No pak je právě otázka, jestli by bylo víc lidí, kteří by si pro elektrárnu bez zplodin, iPod bez DRM a cigarety bez kouře byli ochotni "svinit kernel binárním svinstvem" než těch, kteří by byli radši svinili ŽP, používali drm a kouřili ostatním pod nosem. Jak by hodnotil obě alternativy na příslověčnách vahách? Tolik k použitému příměru (když už byl dotažen ad absurdum).

Vždyť myšlenkou za gpl přece není bránění uživatelům v používání proprietárních ovladačů, nybrž v distribuci odvozených děl s gpl nekompatibliním prvkem. Pro některý hw ovladače prostě svobodné ovladače nejsou nebo nedosahují dostatečných kvalit. Při zachování všech legislativních a licenčních požadavků ale spotřebitel používat proprietární ovladače může, a tak nevidím důvod, proč by jejich užití měli vývojáři kernelu (zejména s odkazem na gpl) zakazovat.

Morální hledisko je jiná stránka, to ať ale nikdo nesvaluje na gpl.

Tebe snad někdo či něco nutí mít a používat právě takovou grafickou nebo bezdrátovou kartu? Je to otázka priorit.

Ekonomické faktory nejsou dostatečným tlakem? A co třeba výkon u grafických karet? Někde se dá najít alternativa relativně snadněji, třeba u zmíněných grafických karet o možnosti nahrazení zatím nevím.

[Robert Krátký]

No pak je právě otázka, jestli by bylo víc lidí, kteří by si pro elektrárnu bez zplodin, iPod bez DRM a cigarety bez kouře byli ochotni "svinit kernel binárním svinstvem" než těch, kteří by byli radši svinili ŽP, používali drm a kouřili ostatním pod nosem. Jak by hodnotil obě alternativy na příslověčnách vahách?

Tuhle konstrukci jsem nějak nepochopil. Já jsem chtěl tím příměrem pouze poukázat na to, že se to odvíjí jen od toho, jak moc člověku na daném principu záleží. Když si někdo chce koupit hardware, který bude fungovat se svobodnými ovladači, není to problém.

Při zachování všech legislativních a licenčních požadavků ale spotřebitel používat proprietární ovladače může

Já reagoval pouze na zmínku o nedostupnusti určitého hardwaru. Co se týče ostatních věcí diskutovaných v tomto vlákně, tak tam se přikláním spíše k tomu, co je řečeno už v článku: zakazovat natahování ndiswrapperu je nesmysl, protože NDIS ovladače nelze ani omylem považovat za odvozeniny jádra. Takže z hlediska GPL je vše v pořádku.

Tebe snad někdo či něco nutí mít a používat právě takovou grafickou nebo bezdrátovou kartu? Je to otázka priorit.

Ekonomické faktory nejsou dostatečným tlakem? A co třeba výkon u grafických karet? Někde se dá najít alternativa relativně snadněji, třeba u zmíněných grafických karet o možnosti nahrazení zatím nevím.

Ekonomický faktor? To by mě zajímalo, co člověka _nutí_ si kupovat takový hardware. U výkonu grafických karet je to stejné. Když někdo tvrdí, že _musí_ mít kartu s určitým výkonem, tak IMHO zapomíná, že např. hraní her není žádná nutnost. Jen záliba.

[Ladislav Sückr]

hardware se zrovna u notebooku ovlivňuje docela špatně - hlavně vzhledem k rozpočtu

3D používám třeba ve VariCADu a to moc hraní není

[Michal Vyskočil]

Ještě že se Intel grafiky poslední dobou docela vzmáhají ...

[Peter Lehotsky]

S tim ale moc nepotesite cloveka ktery si pred rokem (to intel stal za ...) poridil NTB na praci, rekneme za 80.000 .

[Non_E]

No pak je právě otázka, jestli by bylo víc lidí, kteří by si pro elektrárnu bez zplodin, iPod bez DRM a cigarety bez kouře byli ochotni "svinit kernel binárním svinstvem" než těch, kteří by byli radši svinili ŽP, používali drm a kouřili ostatním pod nosem. Jak by hodnotil obě alternativy na příslověčnách vahách?

Tuhle konstrukci jsem nějak nepochopil. Já jsem chtěl tím příměrem pouze poukázat na to, že se to odvíjí jen od toho, jak moc člověku na daném principu záleží. Když si někdo chce koupit hardware, který bude fungovat se svobodnými ovladači, není to problém.

Já chtěl poukázat na to, že jak wifi@5GHz tak elektrárny bez zplodin můžou být pro některé (nebudu si vymýšlet čísla) důležitější než čistota kernelu i když to pak nejde pouze s gpl ovladači. Nenapsal jsem to ale vůbec jasně a hlavní z mého pohledu je, že se v otázce NDISwrapperu shodujeme.

O vztahu nutnosti a záliby zde myslím nemá cenu debatovat. Určitě ne u překladu LKML.

[Thunder.m]

No to si teda piš že mě k tomu něco nutí, jinak bych to tu nepsal, bez wifi karet na 5GHz bychom museli kupovat zařízení za 50 000 Kč na peer-to-peer spoj a bez grafické karty bych si v novějších hrách ani neškrtnul, to bych si tam mohl rovnou nainstalovat Windows, kde to funguje!!!!!!!!!!

[Thunder.m]

Dodávám že to jsi asi přesně ten typ lidí "co nepotřebuju já určitě nepotřebuje nikdo jiný", přesně takových by se měly všechny projekty vyvarovat!

[Robert Krátký]

Velmi zajímavé, co jsi všechno z mojí reakce vyčetl. Tak předně jsem to vůbec neposuzoval podle svých potřeb, protože, světe div se, já taky na svém notebooku používám ndiswrapper a nijak se za to nestydím. Štve mě to, protože je s tím práce navíc, ale to je tak vše. Příště doporučuji reagovat s chladnou hlavou.

A za druhé: i přesto je stále pravda, že ani já, ani ty to ve skutečnosti _nepotřebujeme_ natolik, abychom byli _nuceni_ taková řešení používat. Dovedu-li to opět do přehnaného příkladu, tak kdyby nám na nějakých praštěných ideálech skutečně záleželo, tak bychom ani ty počítače k životu nepotřebovali. Je tedy nesmysl tvrdit, že jsi _nucen_ něco používat.

[Thunder.m]

ok, omlouvám se, špatně jsem to pochopil

[Robert Krátký]

Ale je pro tebe důležitější mít na počítači jen svobodný software, nebo je důležitější to připojení? Mně osobně nesvobodný software nijak extra nevadí, takže proti používání windows ovladačů v Linuxu nic nenamítám. Reagoval jsem však na to, že jsi tvrdil, že je to _nutnost_. Omyl. Není to nutnost. Je to skutečně jen otázka priorit. Asi jako kdyby někdo tvrdil, že hamburger bez masa se prostě nedá jíst (to je fakt...). Ale taky je tu možnost nejíst hamburgery. Otázka priorit.

[DjAARA]

+1

[Thunder.m]

No narážel jsem na poznámku kde mi daný člověk navrhoval daný HW nekupovat, to je ale podle mě dost blbá námitka když v této oblasti prostě není na výběr a buď binární nebo nic.

[Luboš Doležel (Doli)]

Problém nastává v momentu, kdy by takové ovladače začaly uživatele omezovat. Mám takový pocit, že win32 ovladače by v amd64 kernelu nejely a degradování systému na 32bit už bych bral jako značné omezení. To už bych hodně vzdoroval, kdybych musel měnit architekturu systému.

Do jaké míry má 32bit-64bit doopravdy vliv na výkon nechme stranou...

Ovšem ani open source ovladače nejsou spásou. Šéf si koupil notebook s integrovanou Wifinou od Intelu (už nevím jakou, nějaká z těch novějších, ipw2200 tipuju) a výsledkem (údajně stabilního) ovladače bylo v lepším případě rozjetí na čtvrtý load modulu, v horším okamžité zamrznutí systému. Bojoval jsem s tím kdoví jak dlouho a nehnul jsem s tím, ten ovladač fungoval naprosto nahodile

[DjAARA]

Tak moje zkušenosti s ipw2200 jsou jedny z nejlepších. V podstatě je to jedna z nejlépe fungujících wifi v linuxu. Hned po kartách s Prism 2.5 čipsetem .

[Libor Chocholaty]

To mi teda vysvetli s tema 50 tisicema.

[imro]

Taketo nazory ma vedia trosku rozculit. Linux vdaci za svoje rozsirenie a "kvalitu" a mnozstvo vyvojarov prave GPL. Ak sa vam to nepaci, ak sa vam nepaci takato filozofia, nikto vas nenuti pouzivat distribucie zalozene na linuxovom jadre. Mate na vyber bud win, alebo BSD systemy, opensolaris a podobne. Nazyvat taketo veci nejakym fantatizmom, to nie je namieste. Jednoducho je to cena za pouzivanie linuxu. To je ako keby ste oznacovali fantatizmom firmu Microsoft za to, ze pozaduje za svoj produkt peniaze a snazi sa potlacovat nelegalne sirenie svojho softwaru, ak si zan nezaplatite.

[Michal Kubeček]

Linux vdaci za svoje rozsirenie a "kvalitu" a mnozstvo vyvojarov prave GPL.

Máte toto tvrzení něčím podloženo? Proč konkrétně tvrdíte, že Linux za své rozšíření a vývojářskou základnu vděčí zrovna GPL? Osobně si myslím, že to bylo spíš tím, že se objevil v nejvhodnější možné době, která jeho modelu vývoje nahrávala.

[Robert Krátký]

objevil v nejvhodnější možné době, která jeho modelu vývoje nahrávala.

On ten "model vývoje" do značné míry vychází právě z použité licence, ne?

[Michal Kubeček]

Nemyslím si, že by při použití BSD nebo jiné open source licence byl vývojový model Linuxu nějak výrazně odlišný. Ostatně i Linus se později vyjádřil v tom smyslu, že GPL použil spíš proto, že mu jako první padla do oka, než proto, že by mu učarovala její infekčnost (tj. to, čím se především liší od ostatních open source licencí).

[Robert Krátký]

Těžko o tom polemizovat, když další projekt podobného rozsahu (a podobně úspěšný) asi není. Ale řekl bych, že v případě použití licence BSD typu by Linux neměl zdaleka tak širokou podporu (z hlediska kódu) velkých společností. Byl k dispozici produkt, který se jim velmi hodil. Jeho využití pro ně bylo a je výhodné i za předpokladu, že dávají (v případě distribuce) svá vylepšení zpět "upstream". Kdyby byla použita BSD licence, co by tlačilo IBM, Novell a další k tak vysoké míře participace (když by si ještě teď mohli hrát s BSD-Linuxem 2.0 na svém proprietárním písečku)?

[michich]

Linusovi GPL učarovala svou férovostí typu oko za oko, zub za zub. BSD licence tuto férovost nezaručuje, proto si ji nevybral. Viz třeba http://kerneltrap.org/node/7161

[Jardík]

Tak takhle GPL buzerace už mě taky pěkně se*e. Tak když nechci mít v jádře neGPL modul (nebo proprietární), tak ho sakra nenatahuju. Pokud je mojí volbou, že ho chci, tak ho natáhnu. Linuxové jádro začíná být pomalu tak chytré, jako dílo Billovo.

[Thunder.m]

Už se těším až budeme mít pod Linuxem WHQL ovladače, respektive GPL_ONLY, a pokud tam budu chtít nahrát jiný tak to buď nepujde a nebo to na mě bude pořádně řvát :)))

[eh]

Zcela souhlasim s lidmi, kteri prosadili tuto naprosto NEKONTROVERZNI zmenu. Uz selsky rozum mi rika, ze to je krok vpred, nikoli vzad, jak se tu asi nekteri domnivaji.

[Michal Kubeček]

A čo si, Kefalín, predstavujete pod takým slovom nekontroverzní? Očividně něco úplně jiného než já…

[trekker.dk]

big-endian (nejdůležitější bajt první)

Spíš by se hodilo nejvýznamnější.

Důkazem budiž skutečnost, že Evgeniy Polyakov přišel s novou verzí,...

V jaderných novinách z 31.5.2006 je jméno Evgenij Poljakov. Možná by bylo dobré to nějak sjednotit.

[Marek Bernát]

nechcem prilis rypat, ale slova 'vyznam' a 'dolezitost' su v tomto pripade synonyma, takze je to ok.

[Michal Kubeček]

Jazykově možná ano, ale pokud se jedná o zavedený termín, je nevhodné používat odlišnou formulaci, byť s přibližně stejným významem, protože to pouze mate čtenáře. V angličtině se se také v tomto případě používá zásadně most significant bit/byte a nevzpomínám si, že bych někdy viděl třeba most important bit/byte.

[Marek Bernát]

"Most important" sa používa tiež, hoci significant určite častejšie. Ale nesúhlasím, že to čitateľov mätie; ten kto vie, o čom je reč to chápe. A toho, kto nevie, zaujíma len jazykový význam, aby bol schopný to pochopiť. Preto si myslím, že je to v poriadku.

Oh my, zasa sa hádam o úplne zbytočnej veci. To je určite tým nedostatkom slnka

[Robert Krátký]

V jaderných novinách z 31.5.2006 je jméno Evgenij Poljakov.

Dík za upozornění.

[Hynek (Pichi) Vychodil]

Je tam ještě jeden výskyt Evgenye.

[trekker.dk]

Dva.

[Robert Krátký]

Do háje

A navíc si říkám, jestli by vlastně nebylo správné psát spíše "Evženyj".

[ams]

Pokud se jedná o výslovnost, pak "Jevgenij" :)

[camlost]

"dřívěji" :-O

[Robert Krátký]

No jo, už mi to asi moc nemyslelo... Opraveno.

[peterh]

Ja som za kazde efektivnejsie/rychlejsie/viac super riesenie, ale co sa tyka toho userspace network stacku, vie mi niekto vysvetlit, ako to moze byt az o tolko rychlejsie? Nie je to skor neefektivne v jadre?
Dalsia vec - ked je ten stack nejaka kniznica, ako sa da ochranit proti zneuzitiu?

[Jiří Benc]

Ja som za kazde efektivnejsie/rychlejsie/viac super riesenie, ale co sa tyka toho userspace network stacku, vie mi niekto vysvetlit, ako to moze byt az o tolko rychlejsie?

Dobrá otázka. Přesně tu samou si položili nejchytřejší linuxoví síťoví vývojáři taky a jejich odpověď je, že by nemělo. A pokud skutečně je, je možné upravit stack v kernelu tak, aby už nebylo. A nebo je tam zrada někde jinde (jako že se zdá, že je, viz dále). To je právě důvod, proč jsou síťové kanály (po počátečním nadšení) nyní přijímány už jen vlažně.

Konkrétně se zdá, že kernelová implementace není tak rychlá, jak by teoreticky mohla být, protože nefilter. Linux má totiž velmi chytré možnosti nastavení filtrování (někteří si myslí, že až příliš). Pokud je odbouráme, to to pofrčí! Vy chcete mít ale kernel bez podpory iptables?

Dalsia vec - ked je ten stack nejaka kniznica, ako sa da ochranit proti zneuzitiu?

Nijak. Máte prý používat SSL či obdobné technologie.

[peterh]

Ja som myslel zneuzitie nejakym zaskodnickym programom pod normalym userom (napr. spoofing). To sa da nejako vyriesit pomocou SSL?

[Jiří Benc]

To sa da nejako vyriesit pomocou SSL?

Ano. SSL mimo jiné zajišťuje ověření identity odesílatele.

[petr_p]

Ja som za kazde efektivnejsie/rychlejsie/viac super riesenie, ale co sa tyka toho userspace network stacku, vie mi niekto vysvetlit, ako to moze byt az o tolko rychlejsie?

Dobrá otázka. Přesně tu samou si položili nejchytřejší linuxoví síťoví vývojáři taky a jejich odpověď je, že by nemělo.

Jenze je tu jedna vec, ktera bude vzdy vadit: prepinani kontextu. To je tak osklive draha operace, ze se vyplati zustat v kernel space.