Jaderné noviny - 14. 1. 2009

17. 2. 2009 | Jirka Bourek | Jaderné noviny | 3663×

Aktuální verze jádra: 2.6.29-rc1. Citáty týdne: Daniel Phillips, Linus Torvalds, Andrew Morton, Nick Piggin. Citáty týdne II: speciál o revizi patchů. Open source firmware pro bezdrátové adaptéry Broadcom. Začleňovací okno 2.6.29, část 2. Infrastruktura pro asynchronní volání funkcí. Kdo je nejlepší ze všech inlinerů?

Obsah

• Aktuální verze jádra: 2.6.29-rc1
• Citáty týdne: Daniel Phillips, Linus Torvalds, Andrew Morton, Nick Piggin
• Citáty týdne II: speciál o revizi patchů
• Open source firmware pro bezdrátové adaptéry Broadcom
• Začleňovací okno 2.6.29, část 2.
• Infrastruktura pro asynchronní volání funkcí
• Kdo je nejlepší ze všech inlinerů?

Aktuální verze jádra: 2.6.29-rc1

Současné vývojové jádro 2.6 je 2.6.29-rc1 vydané Linusem 10. ledna. Od té doby byl proud patchů do repozitáře hlavní řady relativně pomalý.

Současné stabilní jádro 2.6 je 2.6.28; pro toto stabilní jádro nebyly ještě vydány žádné stabilní aktualizace. Pro uživatele 2.6.27 bylo 14. ledna vydáno 2.6.27.11 se slušnou řádkou oprav.

Citáty týdne: Daniel Phillips, Linus Torvalds, Andrew Morton, Nick Piggin

Konkrétně duplikování bloků je pro jádro nová a nevyzkoušená technika a je mnohem obtížnější než v uživatelském prostoru, protože několik bloků v různých asynchronně se měnících stavech sdílí stejnou datovou stránku. My tuto datovou stránku musíme vytrhnout zpod hromady bufferů a podstrčit jim jinou, aniž by si toho kterýkoliv z nich všiml. Je to jako ten trik, kde strhnete ze stolu ubrus tak rychle, že žádný talíř nespadne na zem. S tím rozdílem, že také musíme ubrus zkopírovat a podstrčit ho pod nádobí předtím, než se usadí na stole.

-- Daniel Phillips - souborové systémy jsou skutečně záludný kód.

Jako obvykle je git ve skutečnosti chytřejší a udělá věci korektněji, než si lidé uvědomují. Co považuješ za "překvapující" je ve skutečnosti "známá pravda." Git je jako indický mudrc. Hledí za závoj triviálního, aby našel skutečná spojení v životě.

Nebo aspoň ve zdrojovém kódu.

-- Linus Torvalds (Díky Nicolasu Pitrovi)

Co se mě týče, digitální fotoaparáty jsou zatím pro ladění jádra užitečnější než jaderné výpisy.

-- Linus Torvalds

Už dlouho potřebujeme souborový systém pojmenovaný po zelenině.

-- Andrew Morton

Linus chce přijmout celou tu konverzi mutexů na adaptivní mutexy? Vyměkl. Takže jsem si bral své azbestové spodní prádlo zbytečně.

-- Nick Piggin

Citáty týdne II: speciál o revizi patchů

Škrábu se na čele a podivuji se nad tou 'data_ptr' věcí. Je to offset disku? Je to skutečně ukazatel na jadernou paměť? Podle tohoto kódu je to vskutku jaderný ukazatel, ale ten je potom nacpán do unsinged long (wtf?) a potom předán do záhadné read_extent_buffer().

<revidovatel hází ohledně tohoto kódu ručník do ringu>

...

<podivuje se nad tím, co dělá -1>

<přechází k místu, kde je definováno btrfs_lookup_xattr()>

<letí další ručník>

...

<zaujme ho btrfs_path.reada>

<chvíli grepuje>

Tady sněží ručníky!

-- Andrew Morton

Zdál se mi takový podivný sen, ve kterém google airlines bombardovaly můj dům ručníky....

-- Chris Mason

Open source firmware pro bezdrátové adaptéry Broadcom

Mnoho lidí si stěžuje na problém binárních blobů s firmwarem; lidé z projektu OpenFWWF s tím něco dělají. Právě vydali ranou implementaci svobodného firmwaru pro desky Broadcom 802.11b a 802.11g. Ačkoliv základní firmware nevyhovuje 802.11, tzn. nepodporuje RTS/CTS proceduru ani QoS, věříme, že někdo by mohl mít zájem ho testovat. Firmware nevyžaduje modifikaci jádra a používá stejné rozvržení sdílené paměti a globální registry jako originál od Broadcomu, aby se usnadnilo jeho nahrávání ovladačem b43 (a aby se nám zjednodušilo programování...) (Díky Luisovi Rodriguezovi)

Začleňovací okno 2.6.29, část 2.

10. ledna Linus Torvalds vydal 2.6.29-rc1 a uzavřel začleňovací okno 2.6.29. Od sepsání shrnutí začleňovacího okna z minulého týdne bylo začleněno něco přes 2000 sad změn; tento článek dokončuje shrnutí tohoto vývojového cyklu.

Předtím, než se budeme zabývat detaily, je vhodné upozornit na to, že jádro 2.6.29-rc1 obsahuje pár neobvyklých pastí na vývojáře a testery. Jestliže si s tímto jádrem hrajete, měli byste si být vědomi tohoto:

• Začlenění Btrfs s sebou přivedlo celou historii vývoje tohoto projektu. Jedním zajímavým výsledkem je to, že když někdo použije git, aby stáhl strom v této vývojové historii, výsledkem bude strom obsahující pouze Btrfs. Konkrétně se toto může stát během procesu dělení půlením [bisect], kde vyjde strom, který nelze přeložit či testovat - což je téměř určitě nechtěný výsledek. Řešení je jednoduché, jednoduše spusťte:

  git bisect good

  a pokračujte v procesu dělení půlením.

• Je zde část vývojové historie jádra, která obsahuje značně poškozenou verzi reiserfs. Tímto problémem jsou opět zasaženi jenom vývojáři provozující konkrétně vybraná jádra; nicméně jestliže provozujete reiserfs, přečtěte si shrnutí a dávejte pozor.

Tak co ještě bylo začleněno do 2.6.29? Změny viditelné pro uživatele zahrnují:

• Na čele seznamu je samozřejmě začlenění souborového systému Btrfs. Není nicméně možné to přehnat s opakováním toho, že Btrfs je stále vývojový souborový systém. Věci se mění rychle a systém stále zpanikaří, když vám dojde místo na disku. Pro lidi, kteří si chtějí s Btrfs hrát - obzvláště ti, kteří chtějí hlásit chyby či zasílat vylepšení - nyní je pro to skvělý čas. Nepřišel nicméně ještě čas svěřit tomuto souborovému systému své Cenné Intelektuální Vlastnictví.

• Také byl začleněn Squashfs, komprimovaný souborový systém pouze pro čtení. Squashfs byl distributory balíčkován léta; jeho začlenění do hlavní řady mělo rozhodně zpoždění.

• Jádro má nyní podporu pro WiMAX síťování. Současný kód podporuje zařízení Wireless Wimax Connection 2400m, ale v budoucnosti se očekávají další. Nějaké informace o WiMAX stacku vizte v v tomto dokumentačním souboru.

• Jsou zde nové ovladače pro

  • desky Hammerhead založené na Atmel AVR32,
  • I2C rozhraní hot swap řadiče s vícenásobným napájením Linear Technology LTC4245,
  • řadiče USB hostitele/OTG/zařízení Oxford OXU210HP,
  • USB řadiče MIPS CI13412,
  • USB periferní řadiče Freescale IMX,
  • USB transceivery TI TWL4030,
  • zařízení pro podsvícení a rfkill specifické pro laptopy Dell,
  • řadiče LED sérií ALIX.2 a ALIX.3,
  • watchdog zařízení PIKA FPGA,
  • watchdog časovače GE Fanus a
  • multifunkční čipy NXP PCF50633 (k vidění v zařízeních OpenMoko)

• Architektura Blackfin získala podporu pro symetrický multiprocesing. Také byla přidána podpora pro rodinu procesorů BF51x.

• Paměťový řadič byl rozšířen tak, aby řídil i využívání swapu. Dříve bylo možné, aby pamětí řízená skupina [memory-controlled group] vyčerpala odkládací prostor.

• Nový virtuální souborový systém "xenfs" umožňují sdílení informací a řízení mezi Xen doménami, hypervisorem a hostitelským systémem.

• Nyní je možné vytvořit a provozovat souborový systém ext4 bez žurnálu. Zjevně se ztratí výhoda, kterou poskytuje žurnálování, ale výkon významně vzroste.

• Byla začleněna vlastnost zmrazení souborového systému, které umožňuje uživateli s dostatečným oprávněním pozastavit změny v souborovém systému (například za účelem zálohování.)

Změny viditelné pro jaderné vývojáře zahrnují:

• Byly začleněny funkce pro exkluzivní alokace I/O paměti.

• Exporty mnoha SUNRPC funkcí byly změněny na pouze GPL.

• Interní API MTD (memory technology device, zařízení paměťové technologie) spatřilo významné změny zaměřené na podporu větších zařízení (těch, které vyžadují 64bitové velikosti.)

• Byla začleněna infrastruktura pro asynchronní volání funkcí. Tento kód je nicméně stále ve vývoji a co se 2.6.29 týče, nebude aktivován při absenci parametru příkazové řádky jádra fastboot.

A tímto končí vyjmenování významných změn přidaných do 2.6.29 - s jednou možnou výjimkou. Linus naznačil, že by mohl být ochoten prostrčit aktualizovanou verzi kódu točícího se mutexu (jak byl popsán v tomto článku o Btrfs), pokud v blízké budoucnosti projde revizí.

Infrastruktura pro asynchronní volání funkcí

Projekt rychlého bootu Arjana van de Vena bude většině čtenářů Jaderných novin pravděpodobně znám. Moc Arjanovy práce však ještě nenašlo cestu do hlavní řady, takže většina z nás musí stále čekat na to, až naše počítače nabootují pomalým způsobem. Jádro 2.6.29 bude obsahovat jeden díl práce na rychlém bootování, a to infrastruktu asynchronního volání funkcí. Uživatelé nicméně budou muset vědět, kde tuto infrastrukturu najít, než ji budou moci použít.

Práce na tom, aby systém bootoval rychle, má mnoho aspektů. Nejníže visící ovoce lze nalézt v oblasti prohledávání zařízení. Zjistit, jaký hardware v systému existuje, bývá přinejlepším pomalé; jestliže to zahrnuje mechanické záležitosti (jako je roztočení disku), ještě se to zhoršuje. Jaderní vývojáři již dlouho chápou, že by mohli získat spoustu času, kdyby prohledávání těchto zařízení šlo provést přinejmenším paralelním způsobem: zatímco jádro čeká na to, až mu jedno zařízení odpoví, může mluvit k jinému. Pokusy paralelizovat tuto práci nicméně během let ztroskotaly, problémy s řazením zařízení, souběžným přístupem a další negativně ovlivnily stabilitu systému, takže paralelizační kód byl nevyhnutelně zase vyjmut. Časná inicializace tedy zůstává téměř zcela sekvenční.

Arjan doufá, že uspěje tam, kde ostatní selhali, (1) opatrně řízeným přístupem k paralelizaci, který se nepokouší paralelizovat všechno naráz a (2) API, které se pokouší zakrýt efekty paralelizace (jiné než zrychlení) před zbytkem systému. Co se (1) týče, Arjan se omezil na změnu subsystému SCSI a libata na asynchronní variantu, aniž by se věnoval zbytku systému. Práce na API zajišťuje, že registrace zařízení probíhá ve stejném pořadí, jako ve striktně sekvenčním systému. To eliminuje otravné problémy s tím, že se člověku mění jméno hardwaru mezi jednotlivými booty.

API je relativně jednoduché. Kód musí vložit <async.h> a vytvořit asynchronní pracovní funkci, která odpovídá tomuto prototypu:

typedef void (async_func_ptr) (void *data, async_cookie_t cookie);

data je v tomto případě typický privátní ukazatel na data a cookie je krycí synchronizační hodnota předaná jádrem. Asynchronní volání funkce se provede takto:

async_cookie_t async_schedule(async_func_ptr *ptr, void *data);

Volání funkce identifikované ptr proběhne během nebo po volání async_schedule(); za některých okolností může proběhnout synchronně. Návratová hodnota je cookie identifikující konkrétní asynchronní volání.

Kód, který volá asynchronní funkce, se nakonec bude chtít ujistit, že byly tyto funkce dokončeny. To je možné provést voláním:

void async_synchronize_cookie(async_cookie_t cookie);

Když toto volání doběhne, je garantováno, že byly všechny asynchronní funkce volané před tou, která je identifikována cookie, dokončeny. Kód, který dělá globálně viditelné změny (například registraci zařízení) by měl tímto způsobem synchronizovat první. Tím zajistí, že všechny globální změny, které by ve striktně sekvenčním systému proběhly první, proběhnou první i v asynchronním režimu.

Kód, které chce vyčkat na dokončení všech asynchronní funkcí, může zavolat:

void async_synchronize_full(void);

Tato funkce se vrátí, když v systému nejsou žádné asynchronně volané funkce. Samozřejmě je možné, že okamžitě poté může být zadána nějaká další.

Interně je implementace asynchronních funkcí rozumně jednoduchá. Je zde pár spojových seznamů - async_pending a async_running - které obsahují čekající a běžící volání funkcí v uvedeném pořadí. Volání async_schedule přidá volání do seznamu čekajících a možná spustí jaderné vlákno, které udělá danou práci. Obecně bude tolik vláken, kolik je platných asynchronních volání funkcí, s napevno zadaným omezením (v současnosti 256). Když vlákno dokončí volání funkce a zjistí, že je seznam čekajících prázdný, ukončí se.

Existuje varianta tohoto API se zvláštním účelem:

async_cookie_t async_schedule_special(async_func_ptr *ptr, void *data, 
                                      struct list_head *running);
void async_synchronize_cookie_special(async_cookie_t cookie, 
                                      struct list_head *running);
void async_synchronize_full_special(struct list_head *list);

Tyto funkce volajícímu umožní předat oddělený seznam, který se má použít místo seznamu async_running. To následně umožní synchronizaci nezávislou na kterékoliv jiné asynchronní funkci běžící v systému. V 2.6.29-rc1 je jeden předpokládaný uživatel tohoto API, který ve skutečnosti ani není součástí procesu bootování: kód mazání inodů ve vrstvě virtuálního souborového systému. Asynchronní mazání urychluje proces výmazu velkého množství souborů. Stojí za to poznamenat, že v 2.6.29 toto API také nefunguje tak, jak je oznamováno - nedostatek, který bude pravděpodobně brzy opraven.

Ve skutečnosti asynchronní volání funkcí obecně nefunguje tak dobře, jak by si jeden v danou chvíli přál. Kód byl začleněn do 2.6.29-rc1, ale uživatelé okamžitě začali hlásit problémy. Jeden z nich (na který narazil autor tohoto článku) spočívá v tom, že proces vyhledávání SATA disků může být "synchronizován", zatímco proces vyhledávání oddílů ještě běží, což vede k systémům, které nenabootují. Výsledkem tohoto problému a dalších obav je to, že Arjan požádal Linuse, aby většinu kódu zakázal, aby se mohl stabilizovat do 2.6.30. Nakonec tedy kód zůstává na místě, ale není aktivován, pokud chybí jaderný parametr fastboot. Vývojáři dobrodruhové tedy mohou asynchronní volání funkcí vyzkoušet; my ostatní můžeme počkat, až se tato vlastnost ještě trochu dovaří.

Kdo je nejlepší ze všech inlinerů?

Klíčové slovo inline poskytované GCC bylo pro jaderné programátory vždy poněkud nebezpečným pokušením. V mnoha případech může vkládání kódu [inline] funkce vylepšit výkonnost. V některých je povinné; to platí obzvláště pro funkce, které obalují specifické instrukce CPU. V jiných případech je ale vkládání kódu klasickým příkladem předčasné optimalizace; přinejlepším nepomůže, přinejhorším zvětšuje jádro a výkonnost poškodí. Vzhledem k tomu, že jaderným vývojářům na výkonu záleží, správný způsob vkládání kódu funkcí byl vždy předmětem diskuzí. Nejnovější debata o tomto tématu nicméně jasně ukázala, že o tomto problému neexistuje žádný jasný konsenzus.

Diskuze začala jako výhonek u tématu točících se mutexů, kde si v zaslaném jaderném výpisu oopsu Linus všiml toho, že funkce __cmpxchg() nebyla vložena. Tato funkce poskytuje přístup k x86 instrukcím cmpxchg*; měla by se rozbalit na jedinou instrukci. Vložit kód funkce, která obsahuje jedinou instrukci, má zjevně smysl, ale GCC se z nějakého důvodu rozhodlo to neudělat.

Linus rychle došel k závěru, že chyba je v konfigurační volbě CONFIG_OPTIMIZE_INLINING (není výchozí). Když je tato volba zapnuta, GCC inline považuje za návrh, který může ignorovat. V takové situaci se GCC rozhoduje samostatně podle zabudované heuristiky. V tomto případě se rozhodlo, že __cmpxchg() je pro vkládání kódu příliš komplexní, takže z ní udělalo samostatnou funkci. Znechucený Linus požádal Inga Molnára, aby CONFIG_OPTIMIZE_INLINING odstranil a donutil překladač řídit se podle klíčového slova inline.

Někteří další vývojáři s tímto požadavkem souhlasili - ale ne všichni. GCC bude určitě dělat chyby, ale také roste pocit, že čím novější verze, tím častěji překladač dojde ke správnému rozhodnutí. Jestliže je GCC umožněno vkládat kód funkcí, které tak nebyly vývojářem výslovně označeny, výsledky mohou být ještě lepší. Na druhou stranu je tu riziko, když je GCC dána příliš volná ruka: přehnané vkládání kódu může vést k problémům s užíváním zásobníku a ztěžovat ladění. To jsou ale problémy, které jsou vývojáři ochotni přijmout, jestliže bude zisk dostatečně velký.

Ingo provedl dlouhou sérii testů, ve které se snažil zjistit, co se stane, když je GCC dána volná vláda nad vkládáním funkcí. Jeho výsledky byly poměrně jasné: nejnovější GCC, když je mu umožněno samostatně se rozhodovat o vkládání funkcí, vytváří jádro, které je o 1-7% menší než jádro, které vznikne při striktním dodržování klíčového slova inline. Z těchto dat Ingo vyvozuje, že nejlepším řešením je použít vkládání zabudované do překladače.

Dnes máme v jádře více než třicet tisíc použití klíčového slova 'inline' a více než sto tisíc jaderných funkcí. Máme za sebou desítky let a stovky patchů pro ladění vkládání funkcí, které zapínají či vypínají atribut inline s cílem dělat to lépe než překladač.

Takže i špatnému překladači, který nikdy nečelil tak velké úrovni složitosti vkládání kódu (až do doby před několika málo měsíci, kdy jsme vydali první jádro s volbou CONFIG_OPTIMIZE_INLINING bez označení CONFIG_BROKEN), se daří o vkládání rozhodovat lépe, než se podařilo lidem po deseti letech ručních optimalizací. (Tedy pokud souhlasíme s tím, že je zmenšení v důležitých oblastech jádra o 1 - 3 - 7,5 % zlepšení)

Linus nicméně nebyl nadšen. Z jeho úhlu pohledu redukce velikosti poskytovaná automatickým vkládáním kódu nepřevažuje nad nevýhodami:

Vůbec tu nejde o velikost - a ani nemusí jít o výkonnost. Je to o abstrakci a o způsobu, jak psát kód.

A je zde ta věc, že dokud gcc dělá to, o co ho žádáme, pak si můžeme všimnout, kde jsme my udělali chybu. Můžeme říct "ok, měli bychom prostě odstranit to inline" atd. Když si ale gcc v podstatě hodí korunou a vloží kód funkce, u kterých to nechceme, snižuje tím užitečnost vkládání funkcí - protože nyní gcc dělá věci tak, že nám to škodí.

Dostáváme oopsy, které mají hezký symbolický výpis a hlásí chyby v NAPROSTO ŠPATNÉ FUNKCI, protože gcc "užitečně" vkládalo kód do té míry, že jenom expert může přijít na to, že "oh, ta chyba je ve skutečnosti o pět set řádek výše v jiné funkci, která se volá jenom jednou a proto ji gcc vložilo, přestože je obrovská."

Chápeš? TOHLE je problém s heuristikou gcc. Není to o kvalitě kódu, ale o SPOLEHLIVOSTI kódu.

Důvod, proč lidé používají C pro systémové programování, je to, že tento jazyk představuje rozumně portovatelný způsob, jak získat očekávané konečné výsledky BEZ TOHO, aby překladač dělal spoustu sémantických změn za vašimi zády.

Linus by byl radši, kdyby klíčové slovo inline bylo pro překladač povinné. Pak, jestliže je v jádře příliš mnoho inline funkcí (a 30 000 zní jako docela velké číslo), by měly být odstraněna zbytečná klíčová slova inline. Trochu se mluvilo o přidání nějakého klíčového slova inline_hint (inline_rada) pro případy, kde je vložení funkce pouze navrhováno, ale tento přístup si mnoho sympatií nezískal.

Problém se zcela manuálním přístupem - i když budeme předpokládat, že může poskytnout nejlepší výsledky - pravděpodobně nejlépe vystihl Ingo:

Jenom v tomto cyklu - v posledních ~2 týdnech jsme přidali do jádra dalších 1300 inline. Opravdu chceme opakované zasílání:

[PATCH 0/135] pročištění odstraněním inline

...v následujících deseti letech? Okolo 20 % funkcí v jádře je označeno 'inline'. Je to velmi silný zvyk. Má cenu bojovat proti němu?

Řešení nadměrného používání inline funkcí oslabením významu klíčového slova inline může vypadat jako řešení špatným směrem. Alternativou by ale bylo mnohem pozornější revidování jaderných patchů před začleněním do hlavní řady. Historie ukazuje, že snaha dosáhnout takové úrovně revidování je přinejlepším předem prohraná bitva. Také ukazuje, že překladače bývají, co se týče tohoto druhu rozhodování, lepší než programátoři, obzvláště když jde o chování celého kódu dohromady (a ne jednotlivých funkcí). Může nicméně chvíli trvat, než bude komunita vývojářů jako celek ochotna věnovat těmto nástrojům tolik důvěry.

       

Komentáře

[Jardík]

Předpokládám, že ten open broadcom firmware neumí enko? Ještě, že výrobce dodává kvalitní ovladač. Nevidím jediný důvod, proč se tím zabývat, ztráta času, který můžou věnovat např. vývoji intel ovladače, který je nepoužitelný (pomalé composite/RGBA, nefunkční HDMI).

[Zdenek]

Vyborne, muzete zasednout a napsat ten Intel ovladac. Nebo jim zaplatit at Vam ho napisou. Nebo blbe kecat. Mate svobodnou volbu, akorat jste zapomel ze oni take.

[Jardík]

By stačilo, kdyby ho napsal intel, třeba i uzavřený. Pro Windows ho také píšou, proč né pro Linux a musejí si to psát sami "Linuxáci"? Je sice hezké, že dají specifikace, ale to je k ničemu. Umožní to sice vznik "něčeho" ale to "něco" tak úplně nefunguje. To samé je i s AMD/ATI, vydala specifikace a dodnes není nic použitelného. Ještě že vydávají uzavřené ovladače, které jsou mnohem lepší a funkčnější.

[Mordae]

Mno, ja narozdil od vas pouzival fglrx od ATI/AMD, radeonhd od Novellu a radeon od X.org a musim vam rict, za zatim si vede nejlepe ten "nejopensourceovejsi", posledni jmenovany. Ta sracka od ATI (a ne, nvidia neni o nic lepsi) absolutne nema sanci konkurovat.

[Jardík]

Ano, jak plynule vám s použitím radeonhd běží Quake4? Jak hezky vám radeonhd renderuje jiné 3d aplikace (tím nemyslím hry), jak rychle vám běží s radeonhd composite, jak hezky vám radeonhd akceleruje video? Mě nvidia akceleruje video jak o závod, fullhd, které mi procesor nestíhá (Athlon X2 5200+ EE), zřejmě i kvůli nutnosti škálovat 1080p na 720p, mi s akcelerací běží naprosto plynule. 3d aplikace plynule, composite plynule (až na debilní implementaci v kwinu, s kterým je to slideshow).

[kozzi]

no tak vše co tu píšeš mi na catalyst(fglrx) nefunguje . Takže to že AMD/ATI vydává ovladače je sice hezké. Jen by mohli vyrábět funkční ovladače, to by potom bylo hezčí.

[rastos]

Mě nvidia akceleruje video jak o závod, fullhd, které mi procesor nestíhá

V tej súvislosti ma napadá otázka: Ako rozoznať či je bottleneck-om jadro, ovládač grafiky, CPU alebo GPU?

[petr_p]

Ti lidi nedělali firmware pro vaše nebo moje potěšení a už vůbec ne kvůli tomu, aby byl otevřený. Oni ho napsali, protože se věnují vývoji 802.11, o kterém si myslí, že v určitých situacích je prostě špatný a že dokážou vyvinout efektivnější protokol.

[Tom.š Ze.le.in]

Dobře, jdu si obléct své azbestové spodní prádlo, jen tak bez důvodu.

Nechápu přesně co se tím chce říct, protože ani po následování linku mi kontext není úplně jasný - ale nebyl by adekvátnější překlad "To jsem si bral své azbestové prádlo zbytečně"?

[Vojtěch Trefný]

Já bych si tipnul, že to bude hláška z nějakého filmu nebo něco takového...

[trekker.dk]

Podle mě tím chce naznačit, že očekává hořlavou diskuzi.

[Robert Krátký]

Je to odkaz na Linusův mail z roku 2003:

Subj.: Flame Linus to a crisp!

Ok, 
 there's no way to do this gracefully, so I won't even try. I'm going to 
just hunker down for some really impressive extended flaming, and my 
asbestos underwear is firmly in place, and extremely uncomfortable.

  I want to make it clear that DRM is perfectly ok with Linux!

[snip]

[Martin Doucha]

Jo, byl. Pisatel podle všeho očekával pořádný flame o mutexech a žádný se nekonal.

Další nesmysl v překladu hlášek je to "indiánské tajemství". Podle mě by to mělo být spíš "indický mudrc," ale v angličtině je občas problém poznat indiána od inda a naopak, takže za toho inda ruku do ohně nedám.

[Robert Krátký]

Dík, máš pravdu v obou případech - nepodíval jsem se na originál.

[stativ]

To zmrazení souborového systému vypadá jako sympatická fičura…

Jinak k tomu SUNRPC – nějaké změny na GPL only exporty jsou už i v 2.6.28.1, ale je to na houby. Abych zprovoznil OpenAFS tak jsem musel porušit GPL i licenci samotného OpenAFS, protože jsem musel nahradit všechny informace o licenci OpenAFS na GPL.

[Hynek (Pichi) Vychodil]

Vtip je v tom,  že ty jsi žádnou licenci neporušil pokud jsi ten modifikovaný kód někomu nedistribuoval. Prostě to co si ty děláš na svém počítači a jestli si tam provozuješ jádro třeba s vypnutými GPL only exporty je čistě tvoje věc. Dokonce si nejsem jistý jestli by vůbec něco nadělali jaderní vývojáři s tím, když by jsi pravidelně vydával zdrojáky jádra bez těchto omezení. Bylo by to morálně pochybné, ale právně naprosto v pořádku. Vzal by jsi GPL kód, zmodifikoval a vydal zase pod GPL. GPL by jsi nijak neporušil. Jen by jsi to myslím nemohl vydávat za Linux (ochranná známka spravovaná nadací založenou Linusem). Dokonce by jsi mohl vydávat i takovou binárku jádra. Opět GPL by nebyla nijak porušena. Jen by se na tebe sesypaly sprosté nadávky, vyzývali by k tvému bojkotu, pokoušeli by se tě zažalovat (zbytečně) a je otázka kdo by tomu tvému jádru věřil a používal ho. Ta ochrana je tam víceméně jako upozornění pro dodavatele binárních ne GPL ovladačů ve smyslu: "Když potřebujete tenhle symbol a vydáte binárku pod jinou licencí než GPL, tak jste s GPL s největší pravděpodobností porušili."

[Filip Jirsák]

Vtip je v tom, že ty jsi žádnou licenci neporušil pokud jsi ten modifikovaný kód někomu nedistribuoval.

To by platilo pouze v případě, kdy ta licence připouští jakýkoli způsob "osobního" použití programu a řeší jen distribuci (taková je např. GPL). Ale jinak i k úpravě autorského díla je třeba mít licenci, i když upravené dílo nebudete distribuovat. Kdyby tomu tak nebylo, je třeba možné beztrestně provádět jakékoli reverzní inženýrství -- tak tomu ale není, v (českém) AZ jsou na to přísné podmínky.

[Fluttershy, yay!]

Aha a když to nikomu nijak nedistribuuji, nikdo neví, že to mám upravené. ^_^

[Pavel]

GEM uz v jadre je od minule verze, ale nevite, jak to vypada s kernel mode setting? Melo se dostat do 2.6.29.

[trekker.dk]

Dostalo se v -rc1, viz minulé JN.

[Jardík]

GEM stejně nebude funguvat, dokud distribuce neaktualizujou intel ovladače, půlka z nich je má 100 let starý, např ArchLinux, který má snad všechno aktuální má pořád 2.4, stejně jako ostatní. Snad jen vývojová verze Ubuntu 9.04 má 2.6 a ten stejně funguje jako když nefunguje a je ještě pomalejší než 2.4. A nejhorší na tom je, že si ten ovladač uživatel nemůže jednoduchým způsobem aktualizovat - pro instalaci musíte kompilovat drm, intelý ovladač, jádro a jánevímco. Dokonce i v několik let starém Windows XP se dá nainstalovat nejnovější ovladač na grafiku bez kompilace a aktualizace 30 věcí a spočívá v 5 kliknutí. Fakt demence, že vyjde distribuce s ovladačem xx a i když vyjde zz, tak ho tam nedají a musí tam být pořád xx. Ať tam xx nechají, ale ať umožní nainstalovat zz. Ale to se nikdy nezmění, protože jsou linuxový vývojáři natvrdlí a nepochopí, že by to někomu mohlo vyhovovat. Stejně tak výměnná média. Když nechci používat KDE ani GNOME, tak prostě musím jak dement lézt do konzole a růčo to všechno připojovat. A dneska to musím dělat ručně i v KDE, protože zasranej policykit v archlinuxu je totálně zkurvenej a i když se naserete do skupin kam máte, tak to nejde. Pak je super práce s sítí, která spočívá ve spuštění nm-appletu a hlášky, že se nelze připojit kvůli oprávnění, i když v požadované skupině jste. A když dáte dotaz do fóra, tak se na vás každej vysere, protože oni networkmanager nepotřebují, oni si totiž pustí v konzoli příkaz tenaten a pak támhletenatámhleten, upraví routovací tabulku, napevno si ve wifi accesspointu nastaví ip, aby jim to jelo, vypnou wpa2, aby nemuseli spouštět příkaz tenaten. Prostě čím víc linux používám, tím víc věcí mi tam přijde nahovno. A dneska mi přijde nahovno i ta Vista, protože mi dneska nebyla schopná na 4GB flashku s FATkou nakopírovat 1,5GB soubor - nejdřív se zeptala, jestli ho chci zkopírovat bez práv (měl nastavené ACL) a když jsem dal ano, tak se to celý zaseklo a hovno. Dnešní OS jsou prostě nahovno, jediný OS, který se mi ještě nezhnusil je MacOS, ale s tím musíte koupit HW a platit za každou dementní aplikaci, protože ty zdarma jsou nahovno (koukněte např. na nabídku vypalovacích programů, které je tedy dementní i na Linuxu, k3b se muselo zkurvit kvůli KDE4 a debilní brasero nic neumí a kurví CéDéčka a neumí smazat DVD-RW).

[michich]

Fakt demence, že vyjde distribuce s ovladačem xx a i když vyjde zz, tak ho tam nedají a musí tam být pořád xx.

Minimálně pro Fedoru tohle neplatí. Např. xorg-x11-drv-ati, který používám, vyšel ve Fedoře 10 ve verzi 6.9.0 a v updatech pak vyšel 6.10.0.

Dál už jsem nečetl, vypadalo to už moc jako zbytečné stěžování si.

[petr_p]

Stejně tak výměnná média. Když nechci používat KDE ani GNOME, tak prostě musím jak dement lézt do konzole a růčo to všechno připojovat.

To je fakt hrozné. Raději použijeme sadu skriptů, které nejprve budou půl minuty médium ošahávat, aby zjistili, že cédéčko je prázné, a pak automagicky uhádnou, který uživatel si ho tam strčil, a podle toho nastaví přístupová práva k zařízení, takže síťový uživatel, co ho tam dal, protože nemá ve své stanici vypalovačku, se k němu nedostane.

[Roger]

No trolleni je to vydarene... Debian ma 1.6 RC, 2.6.1, 7.4 uz celkem dlouho (=od te doby, co vysly).

A musim rict, ze to funguje skvele :)

[alkoholik]

Musim bohuzel potvrdit, ze intel driver z experimental debian baliku s 2.6.29-pre jadry nefunguje a stary (balik z unstable) nema podporu pro KMS.

[Roger]

Byla rec o GEMu, ne KMS. 2.6.29 jeste neni ani vydane, takze bych to neresil. Ovladac z experimentalu mi s 2.6.28 snapshoty funguje skvele, vcetne UXA - takhle rychla KDEcka jsem nemel uz dlouho :)

On ma teda Intel 2.6.1 dost vlastnich problemu i s GEMem, ale o tom puvodni trolleni nebylo.

[to jsem prece ja]

k tomu ArchLinuxu: v AUR je xf86-video-intel 2.6.1 ... networkmanager + nm-applet mi funguje na trech instalacich bez problemu ... pouzivat FATku (FAT16 ?) je debilita ... a ano, policykit je fakt "totalne zkurvenej"

[Jardík]

networkmanager a nm-applet mám z repozitáŕe (extra, community či co), funguje jen pod rootem kvůli policykitu. intel ovladač kompilovat nebudu, protože to má minimálně 5 dalších věcí jako závislosti a akorát se rozprasí systém.

[to jsem zase ja]

networkmanager mam taky z extra a funguje naprosto bezne a bez problemu i bez roota. xf-86-video-intel-newest 2.6.1-2 z AUR ma vsechny zavislosti v extra a pokud pouzivate xf86-video-intel 2.4, mate je uz beztak vsechny nainstalovane (krome automake). Pokud je v PKGBUILDu v AUR spravne popsany konflikt s puvodnim balikem xf86-video-intel, rozhodne se nic "nerozprasi".

[Jardík]

Tak tos asi ještě neaktualizoval, protože packagekit to zničí. A jestli ano, tak je ArchLinux zvláštní distribuce, když to napůl nefunguje. Mi řekni, co mám kde nastavit. Jsem ve skupině network a nejde to.

A co intel-dri a mesa, to přece také musím překompilovat(?).

[Jardík]

A co mám použít na flashku s 4GB? soubory větší jak 2GB tam nenahrávám, důležitá je pro mě přenositelnost Windows-Mac-Linux a to splňuje FATka naprosto dokonale.

[Fluttershy, yay!]

Pro lidi, kteří si chtějí s Btrfs hrát - obzvláště ti, kteří chtějí hlásit chyby či zasílat vylepšení - nyní je pro to skvělý čas.

Ta věta je nějaká divná.

A to s ručníky: ROFL!

[Jardík]

typedef void (async_func_ptr) (void *data, async_cookie_t cookie);

Nechybí tam hvězdička?

typedef void (*async_func_ptr) (void *data, async_cookie_t cookie);