abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 20:33 | Zajímavý projekt

Byly zveřejněny schémata, firmware a instrukce pro sestavení trackballu Ploopy. Ten používá Arduino, senzor PMW3360 a 1,75palcovou kouli. Zdrojové soubory jsou šířeny pod open-hardware licencí CERN a GNU GPLv3. Tvar je inspirovaný klasickým trackballem Microsoft Trackball Explorer, jehož výroba byla ukončena kolem roku 2005 bez náhrady; projekt Ploopy se k tomu ale z právních důvodů nehlásí. Již vyrobené díly je možno objednat za 200 kanadských dolarů. Další podrobnosti v příspěvcích uživatele crop_octagon na Redditu.

Fluttershy, yay! | Komentářů: 9
včera 20:22 | Nová verze

Vyšlo desktopové prostředí KDE Plasma 5.17. Novinkou je např. „noční režim“ (pro X11, nejen Wayland), skrytí upozornění při prezentacích (když je připojena obrazovka se stejným obrazem), lepší podpora HiDPI, optimalizace využití zdrojů a mnoho drobných zlepšení a oprav.

Fluttershy, yay! | Komentářů: 2
včera 12:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 169. brněnský sraz, který proběhne v pátek 18. října od 19:00 v restauraci Racek (Jungmanova 5). Před srazem proběhne v 18:00 komentovaná prohlídka nových prostor hackerspacu base48 (přístup je z Mojmírova náměstí).

Ladislav Hagara | Komentářů: 8
včera 05:55 | Bezpečnostní upozornění

V příkazu sudo byla nalezena a ve verzi 1.8.28 byla již opravena bezpečnostní chyba CVE-2019-14287. V souboru /etc/sudoers lze nastavit, aby daný uživatel mohl konkrétní příkaz spouštět s právy libovolného uživatele (ALL) nebo libovolného uživatele kromě uživatele root (ALL, !root). Spustí-li tento uživatel daný příkaz se sudo s volbou -u#-1 nebo -u#4294967295, tj. pod uživatelem -1 nebo 4294967295, nebude vyžadována autentizace a příkaz se spustí pod právy roota.

Ladislav Hagara | Komentářů: 1
včera 01:33 | Nová verze

Po více než roce a čtvrt od vydání verze 3.7.0 byla vydána nová verze 3.8.0 programovacího jazyka Python. Přehled novinek v aktualizované dokumentaci. Podrobný přehled změn v Changelogu.

Ladislav Hagara | Komentářů: 15
14.10. 16:11 | IT novinky

Ke zhlédnutí na Invidious a YouTube je videozáznam rozborky a sborky mobilního telefonu Librem 5.

Ladislav Hagara | Komentářů: 46
14.10. 13:33 | Komunita

Richard Stallman, zakladatel hnutí svobodného softwaru, se dnes v e-mailové konferenci guix-devel vyjádřil, že svobodný software je apolitický, resp. jedinou přípustnou politikou je politika svobodného softwaru. Reagoval na některé návrhy, že by se do svobodného softwaru měl zabudovat feminismus nebo jiný -ismus. Říká, že témata jako komunismus nebo sexuální orientace jsou „off-topic“. Je v pořádku mít politické názory, ale lidé

… více »
xkucf03 | Komentářů: 104
14.10. 05:55 | Nová verze

Po téměř dvou letech vývoje od vydání verze 2.0 byla vydána verze 2.1.0 svobodného softwaru ScummVM (Wikipedie) umožňujícího bezproblémový běh mnoha klasických adventur na zařízeních, pro které nebyly nikdy určeny. Podrobnosti v poznámkách k vydání.

Ladislav Hagara | Komentářů: 3
13.10. 10:55 | IT novinky

Josef Průša představil novou 3D tiskárnu Original Prusa MINI. Její cena je 9 990 Kč a tisknout lze na ní objekty do velikosti 18 × 18 × 18 cm.

Ladislav Hagara | Komentářů: 41
12.10. 13:11 | Nová verze

Byla vydána nová stabilní verze 3.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu. Projekt lze podpořit na Patreonu. Aktuálně má přislíbeno 5 697 dolarů měsíčně.

Ladislav Hagara | Komentářů: 2
Kdy jste naposledy viděli počítač s připojeným běžícím CRT monitorem?
 (19%)
 (4%)
 (11%)
 (39%)
 (24%)
 (2%)
Celkem 401 hlasů
 Komentářů: 22, poslední 23.9. 08:36
Rozcestník

www.AutoDoc.Cz

Jaderné noviny – 16. 12. 2009

18. 1. 2010 | Jirka Bourek | Jaderné noviny | 3860×

Aktuální verze jádra: 2.6.32.1. Citáty týdne: Dave Airlie, Zachary Amsden, Linus Torvalds. Chyby RCU. Omezování spotřeby. kmsg_dumper – informace o pádu systému. Nová sada operací specifických pro CPU. Začleňovací okno 2.6.33, část druhá. Změna návrhu asynchronního uspávání/probouzení. Náhlé začlenění Nouveau.

Obsah

Aktuální verze jádra: 2.6.32.1

link

Začleňovací okno 2.6.33 je stále otevřené, takže v době psaní tohoto článku nebylo vydáno žádné jádro. Vydání 2.6.33-rc1 uzavírající toto začleňovací okno lze očekávat každou chvíli.

Stabilní aktualizace jádra: 2.6.32.12.6.31.8 byly vydány 14. prosince. Obě obsahují dlouhý seznam oprav, mnoho z nich patří k souborovému systému ext4.

Citáty týdne: Dave Airlie, Zachary Amsden, Linus Torvalds

link

Ne mami, to jenom tvůrce Linuxu mi v pátek odpoledne naložil další práci. Táta o tom určitě najde nějaký článek.

-- Dave Airlie

K čertu, to jsou komplikované hovadiny. Analogická úloha by ve skutečném životě byla nutit tlupu vřešťanů, každého na vlastním stromě, zpívat unisono, zatímco hlavní zpěvák skáče ze stromu na strom, přičemž neviditelný dirigent neustále mění tempo, ve kterém se hraje. Naštěstí tu nejsou žádné změny tóniny, nicméně občas se objeví nový strom nebo starý padne k zemi.

-- Zachary Amsden (díky Markusu Armbrusterovi)

Přesložitělé návrhy jsou HŘÍCH. Je to archetypální příklad toho, čemu říkám „špatný vkus“. Opravdu mě naštve, když správce subsystému začne vymýšlet zbytečné složitosti.

-- Linus Torvalds

Chyby RCU

link

Thomas Gleixner se rozhodl, že zlikviduje ošklivý rwzámek [rwlock] tasklist_lock; v mnoha případech je řešením místo něj použít čtení-kopírování-zápis [read-copy-update, RCU]. Během toho nalezl několik problémů s tím, jak některý kód RCU používá. Tyto problémy si zasluhují krátkou zmínku, protože se mohou objevit i jinde a odrážet zastaralý náhled na to, jak RCU funguje.

Hlavní nápad RCU je zpozdit uvolnění neplatných globálně viditelných dat, dokud není jisté, že je již nikdo nepoužívá. Toho bylo tradičně dosahováno tak, že (1) veškeré přístupy k datům chráněným RCU byly v atomickém kódu a (2) stará data se uvolňovala až poté, co na všech procesorech proběhlo plánování alespoň jednou od doby, kdy byla data nahrazena aktuální kopií. Vzhledem k tomu, že atomický kód nelze přerušit plánováním, je tato sada pravidel dostatečná k tomu, aby bylo jisté, že již neexistují odkazy na stará data.

Není třeba říkat, že kód pracující s daty chráněnými RCU musí běžet se zakázanou preempcí – jinak by se na procesoru mohlo plánovat i v době, kdy na tato data existuje nějaký odkaz. Primitivum rcu_read_lock() proto tradičně preempci zakazovalo. Podle kódu, který Thomas našel, to vedlo k úsudku, že pro kód používající RCU je zakázání preempce dostatečné.

Problém je v tom, že novější formy RCU používají ke sledování chráněných dat sofistikovanější dávkovací mechanismus. Tato změna byla nutná, aby RCU lépe škálovalo obzvláště v situacích (například běh v reálném čase), kde je zákaz preempce nežádoucí. Při používání hierarchického (či „stromového“) RCU bude kód, který jednoduše před přístupem k chráněným datům zakáže preempci, obsahovat ošklivé souběhy. Je tedy důležité při práci s takovými daty použít rcu_read_lock(). Toto pravidlo je bohužel obtížné vynutit automaticky, takže si ho programátoři prostě budou muset zapamatovat.

Omezování spotřeby

link

Salman Qazi mluví o hypotetické situaci, ve které se možná nachází mnoho z nás:

Představte si, že jste v Údolí smrti s laptopem. Nudíte se a chcete si pustit film. Také ale chcete, aby baterie vydržela tak, abyste z filmu viděli co nejvíce.

Navrhované řešení shodou okolností funguje také pro jinou situaci. Představte si, že jste Google a chcete z každého datového centra dostat co nejvíce. Jedním způsobem, jak to udělat, je na dané místo navézt víc strojů, než může dostupné napájení zvládnout, a následně řídit spotřebu jednotlivých strojů tak, aby celková spotřeba zůstala pod limitem.

Konkrétně kód, který Google má, pracuje tak, že vynutí přepnutí procesoru do klidového stavu na určité procento času, přičemž dané procento je nastaveno dynamicky v závislosti na zátěži stroje a datovém centru jako celku. Pokud je zapotřebí, úloha běžící v reálném čase může procesor zabrat a na požadovanou dobu ho nechat v klidu, aby se celkový výpočetní čas vešel do limitu. Objevuje se zde zajímavá heuristika, která se snaží vnutit čekací cykly procesům o nízké prioritě a která zjišťuje, komu byly nečinné cykly naúčtovány.

Tato práce zní podobně jako ACPI ovladač pro zabrání procesoru, který byl přes námitky správce plánovače Petera Zijlstry začleněn do 2.6.32. Peter se k nyní navrhovanému patchi ještě nevyjádřil, ale podle popisu to vypadá jako něco, co se více blíží tomu, co pro tuto funkcionalitu požadoval. Je nicméně těžké to říct s jistotou; kód sám ještě zaslán nebyl. Doufejme, že bude brzy následovat a tuto změnu bude možné skutečně posoudit.

kmsg_dumper – informace o pádu systému

link

Bez ohledu na nové sledovací nástroje většinou jaderní vývojáři sahají po printk() (když se snaží vyřešit problémy). Člověk ale nemusí na jaderném kódu pracovat dlouho na to, aby narazil na nepříjemný fakt: Většina nejzajímavějších výpisů je často vypsána těsně před pádem, ale u mnoha druhů problémů může smrt systému zabránit vypsání těchto kriticky důležitých řádek. Není nijak zábavné zírat na zaseknutý systém a vědět, že informace potřebné pro dohledání problémů pravděpodobně uvízly v nějakém bufferu v paměti.

2.6.33 bude obsahovat nový mechanismus navržený k tomu, aby tyto poslední kousky informací vyrval ze spárů umírajícího systému. Vývojář musí pouze nastavit nový „vypisovač kmsg“ [kmsg dumper]:

#include <linux/kmsg_dump.h>

struct kmsg_dumper {
    void (*dump)(struct kmsg_dumper *dumper, enum kmsg_dump_reason reason,
                    const char *s1, unsigned long l1,
                    const char *s2, unsigned long l2);
    struct list_head list;
    int registered;
};

Funkce dump() bude zavolána v případě pádu; dva argumenty s1s2 budou obsahovat ukazatele na data ve výstupním bufferu jádra. Dva ukazatele jsou potřeba kvůli kruhové povaze tohoto bufferu; s1 bude ukazovat na starší sadu zpráv.

Registrace a odregistrování těchto funkcí je záležitostí volání:

int kmsg_dump_register(struct kmsg_dumper *dumper);
int kmsg_dump_unregister(struct kmsg_dumper *dumper);

V jádře 2.6.33 byl přepracován modul „mtdoops“ tak, že tento nový mechanismus používá k zapsání dat z pádu na flash zařízení.

Nová sada operací specifických pro CPU

link

Proměnné specifické pro CPU se používají jako technika vylepšující výkonnost. Umožňují procesorům pracovat s daty bez nutnosti zabývat se zamykáním nebo soupeřením o cache. Člověk by chtěl, aby tyto operace byly dobře optimalizovány, ale jak se ukazuje, lze je vylepšit; Tejun Heo a Christoph Lamerter to udělali v 2.6.33 a přitom změnili způsob, jakým mohou vývojáři s těmito proměnnými pracovat.

Je zde sada nových operací:

this_cpu_read(scalar);
this_cpu_write(scalar, value);
this_cpu_add(scalar, value);
this_cpu_sub(scalar, value);
this_cpu_inc(scalar);
this_cpu_dec(scalar);
this_cpu_and(scalar, value);
this_cpu_or(scalar, value);
this_cpu_xor(scalar, value);

Ve všech případech je scalar buď proměnná specifická pro CPU získaná od nového alokátoru, nebo statická proměnná specifická pro CPU získaná z per_cpu_var(). Všechny funkce jsou atomické v tom, že operace nebude na současném procesoru přerušena v půli. Po jejich použití není nutné volat put_cpu().

Příklad toho, jak se operace s proměnnými specifickými pro CPU v novém schématu mění, vizte například na konverzi statistik VM

Začleňovací okno 2.6.33, část druhá

link

Od shrnutí z minulého týdne bylo do vývojového cyklu 2.6.33 začleněno přes 4200 patchů. V době psaní tohoto článku je celkový součet 8152 patchů.

Mezi změny viditelné pro uživatele patří:

  • Jestli ještě někdo používá ReiserFS: tento souborový systém se dočkal významného přepracování interního zamykání kvůli eliminaci velkého jaderného zámku [Big Kernel Lock]

  • Architektura Super-H získala podporu pro události výkonnosti [perf events] pro mnoho typů systému.

  • Souborový systém exofs (pro zařízení ukládající objekty) nyní obsahuje podporu pro zrcadlení více zařízení.

  • Pro souborový systém ext4 je zde nová připojovací volba „discard“, která řídí, jestli ext4 pro nově uvolněný prostor vysílá příkazy TRIM. Vzhledem k obavám z toho, jak tato vlastnost bude fungovat, až ji hardware začne podporovat, je výchozí hodnota „vypnuto“.

  • Nyní je možné nakonfigurovat jádro bez podpory ext2 a ext3, ale i tak lze tyto souborové systémy připojit pomocí kódu pro ext4.

  • Ovladač Nouveau získaný reverzním inženýrstvím z ovladače NVIDIA byl začleněn, ale bez firmwaru, který k němu patří; více informací vizte v tomto článku.

  • Do stromu staging bylo začleněno zařízení „ramzswap“ dříve známé jako compcache.

  • Strom staging nyní obsahuje pro mesh síťový protokol „BATMAN“

  • Nástroj „perf“ má nyní režim „diff“, který vypočítá změnu výkonnosti mezi dvěma běhy a vygeneruje zprávu.

  • Sémantika příznaků při otevírání souboru O_SYNCO_DSYNC byla racionalizována tak, jak bylo popsáno v tomto článku.

  • MD vrstva nyní podporuje požadavky na bariéry pro všechny typy RAID. Podporu bariér vylepšil také device mapper.

  • Cíl slučování snímků device mapperu byl začleněn.

  • Do souborového systému XFS byla přidána rozsáhlá sada sledovacích bodů, která umožňuje jemný náhled na většinu jeho práce.

  • Stránky v paměti sdílené pomocí mechanismu jádrem sdílené paměti [Kernel Shared Memory, KSM] lze nyní odswapovat.

Změny viditelné pro vývojáře jádra:

  • Zpětné volání detect() ve struktuře struct i2c_driver ztratilo nepoužívaný parametr kind. struct i2c_client_address_data již není mezi námi; seznamy adres jsou místo toho reprezentovány jednoduchými poli unsigned short.

  • Patch přejmenovávající spinlocky byl začleněn. Vývojáři pracující blízko nízkoúrovňového kódu uvidí u nespících (a to ani v realtime stromě) zámků typ arch_spin_lock_t.

  • Video4Linux2 má nové API pro podzařízení nazvané media-bus [sběrnice médií], které má pomoci při vyjednávání o formátu obrazu mezi senzorem a řadičem.

Toto začleňovací okno by se mělo ve velmi blízké budoucnosti uzavřít, takže jádro 2.6.33 je nyní, co se vlastností týče, téměř kompletní. Poslední přírůstky z následujícího týdne budou zmíněny v příštích Jaderných novinách.

Změna návrhu asynchronního uspávání/probouzení

link

Kdyby někdo udělal v komunitě uživatelů Linuxu anketu, jenom málokdo by tvrdil, že se mu nelíbí myšlenka na to, že by se jeho systém uspával a probouzel rychleji. Rafael Wysocki na tom pracuje již nějakou dobu; jeho patche pro asynchronní uspávání/probouzení zde byly popsány v srpnu. Tento kód již nějakou dobu nenarazil na žádné turbulence, takže se dalo předpokládat, že Rafaelův požadavek na přetažení do 2.6.33 nebude kontroverzní. Takové předpoklady nicméně zapomněly vzít v potaz jev nazvaný „Linus na poslední chvíli“.

Zde hraje roli jeden důležitý fakt, že jako nikdo jiný ani Linus nemůže sledovat všechny projekty, na kterých se právě pracuje; z toho důvodu je klidně možné, že práce na nějakém projektu dojde ke svému závěru, aniž by si toho jedinkrát všiml. Tento stav nicméně nevyhnutelně končí s tím, že někdo zašle požadavek na přetažení této práce. Je jasné, že některé požadavky jsou zkoumány pečlivěji než jiné, ale na některé se hledí opravdu zblízka. Jak se ukázalo, mezi ty poslední patří i požadavky u správy napájení.

Přinejmenším lze říci, že se Linusovi nelíbilo to, co viděl.

Kód je podle něj zbytečně složitý a možná nebezpečný; odmítl ho přetáhnout. Konkrétně se mu zdálo, že bylo až příliš mnoho práce věnováno tomu namapovat topologii stromu zařízení a všech závislostí mezi nimi. V minulosti pokusy udělat něco asynchronně pouze podle zjevné topologie narazily na potíže; proč by to tentokrát mělo být jinak?

Linus dále navrhl alternativní řešení založené hlavně na stromu zařízení. Přitom chtěl, aby bylo možné, aby většina ovladačů mohla koncept asynchronního uspávání a probouzení úplně ignorovat. Pro většinu hardwaru v systému je čas potřebný pro tyto operace tak krátký, že opravdu nemá cenu dělat to paralelně. Jestliže je možné zařízení uspat během pár milisekund, klidně se to může udělat sériově a vyhnout se přitom složitostem.

Co se zbytku týče, Linus velmi stál o rozhodnutí, jestli se o tom, zda se bude uspávání/probouzení provádět asynchronně, bude rozhodovat na úrovni ovladačů. Jádro správy napájení ale i tak bude potřebovat vědět dost o asynchronním zpracování, aby čekalo na jeho dokončení; nelze uspat řadič, dokud se zařízení k němu připojená také neuspí. Po několika revizích se z Linusova plánu stalo něco takovéhoto:

  • S každým uzlem ve stromu zařízení je spojen semafor čtenář/zapisovatel (rwsem). Tyto semafory umožňují neomezené množství současných čtecích zámků, ale v daný okamžik může existovat pouze jeden zámek pro zapisovatele a zapisovatelé musí počkat, než čtenáři dokončí svou práci. Na začátku procesu uspávání není zabrán žádný zámek.

  • Proces uspávání zahájí všichni potomci daného uzlu. Pokud to dělají synchronně, udělá se to hned a není zapotřebí žádná další akce.

  • Pokud se ovladač rozhodne pro asynchronní uspávání, spustí vlákno, které tuto práci provede. Také zabere čtecí zámek rwsem rodiče.

  • Když se asynchronní uspání specifického zařízení dokončí, zámek je uvolněn.

  • Rodičovský uzel získá zámek pro zapisování na svém vlastním rwsem před uspáváním zařízení. Pokud se nějaký potomek uspává asynchronně, zámek bude blokovat kvůli aktivním čtecím zámkům. Teprve když jsou všechny zámky pro čtení uvolněny – tj. všichni potomci se uspali – získá rodič svůj zapisovací zámek a může se uspat.

Při probouzení je nejprve získán zámek pro zapisování a všichni potomci zabírají zámky pro čtení svého rodiče před probouzením hardwaru. Tím se zajistí, že se všechna zařízení probudí předtím, než se začnou probouzet jejich potomci.

Výhodou tohoto schématu je jednoduchost. Jeho implementace nicméně zabrala několik kol diskuzí, ve kterých Linus opakovaně žádal vývojáře, aby tuto jednoduchost zachovali a nepokoušeli se vymýšlet nová schémata pro zamykání. I tak se věci trochu změnily; v době psaní tohoto článku současná sada patchů pro uspávání/probouzení nepoužívá Linusův původní plán. Rafael, který implementoval řešení založené na rwsem, mezi jinými věcmi narazil na problémy s lockdep a s Linusem se shodli, že byly závažné.

Místo toho byla implementována varianta tohoto schématu založená na dokončeních [completions]. Každý uzel zařízení dostane strukturu dokončení, která je zpočátku nastavena do stavu „není dokončen“. Každý ovladač, který implementuje asynchronní uspávání/probouzení, musí zavolat device_enable_async_suspend(), kterou o tom informuje jádro správy napájení. Na tomto jádře nyní je, aby vytvořilo vlákna pro asynchronní operace uspání/probouzení a zavolalo zpětná volání [callback] ovladačů z těchto vláken. Před uspáním specifického uzlu zařízení se bude čekat na dokončení všech potomků, které mají asynchronní zpětná volání. To opět zajišťuje, že jsou všichni potomci uspáni, předtím než se rodičovský uzel uspí sám.

Linusovi se přístup založený na dokončeních nelíbí, ale naznačil, že bude ochoten ho přijmout. V době psaní tohoto článku se tak nicméně nestalo.

Z jedné strany to může být bráno jako nebraní ohledů na čas vývojáře, což je občas během vývojového procesu jádra k vidění. Není zcela neobvyklé, že kód, na kterém se hodně pracovalo, je nakonec zahozen nebo výrazně přepracován. Tento model se může zdát jako plýtvání a je nepochybné, že je pro dotčené vývojáře značně frustrující. Je to ale základní součástí toho, jak funguje řízení kvality v jádře. Tímto přepracováním v poslední minutě byl kód pro uspávání/probouzení zjevně vylepšen. Dalo by se říci, že by bylo lepší, kdyby se tak stalo před několika měsíci, ale pro uživatele Linuxu je nejdůležitější, že se tak vůbec stalo.

Náhlé začlenění Nouveau

link

Začleňovací okno je pro správce subsystémů běžně poměrně hektický čas. Mají dva týdny na to, aby dali dohromady dobře zformovaný strom obsahující všechny změny určené do příštího vývojového cyklu jádra. Příležitostně se ale mohou na poslední chvíli objevit háčky, kvůli kterým je začleňovací okno ještě rušnější než obvykle. Neočekávané začlenění ovladače Nouveau je výsledkem jednoho takového háčku – ale je to příběh se šťastným koncem pro všechny.

Dave Airlie si pravděpodobně myslel, že toho má na talíři už dost, když vygeneroval požadavek na přetažení DRM do 2.6.33. Tento strom obsahoval 203 commitů, které se dotýkaly 122 různých souborů a přidávaly přes 9 000 řádků kódu. Jednou z klíčových vlastností, které se mají dostat do tohoto jádra, je nové „ioctl() pro prohazování stránek“, které je užitečně popsáno ve zprávě u commitu tak, že toto ioctl() vezme ID fb a ID ctrc a prohodí ctrc do daného fb při příštím vblank. V češtině to znamená, že specifický video výstup lze rychle přepnout z jedné oblasti videopaměti do jiné, což umožňuje čisté změny obrazu bez „tearingu“, který je důsledkem zobrazování videobufferu, jež se právě mění.

Další změny DRM tentokrát zahrnují podporu pro GPU Intel „Ironlake“ a procesoru Atom „Pineview“ a spoustu práce podporující jaderné nastavování režimu GPU Radeon. Radeon podle všeho v tuto chvíli postrádá pouze dobrou správu napájení; pravděpodobně před koncem tohoto vývojového cyklu ztratí své označení „staging“.

Linus tímto faktem nebyl nijak ohromen. Místo toho měl připomínku: Fakt, že ovladač Nouveau – reverzním inženýrstvím získaný ovladač pro čipové sady NVIDIA – nebyl součástí požadavku na přetažení. Nouvaeu byl diskutován na Jaderném Summitu 2009 a obecně všichni souhlasili s tím, že by si tento kód měl co nejrychleji najít cestu do hlavní řady. 2.6.33 je první začleňovací okno od summitu a Linus zjevně očekával na této frontě nějakou akci. A když se jí nedočkal, své zklamání dal najevo.

Možná by se někdo mohl divit tomu, co je u Nouveau za problém. Svět je plný ovladačů pro Linux, které jsou mimo strom; nedávné snahy jejich počet významně snížily, ale stále existují a Linus si na ně normálně nestěžuje. Nouveau je rozhodně víc na očích než většina ostatních ovladačů mimo strom; pro velké procento dostupných strojů je to jediná naděje na svobodný ovladač. Skutečný problém je ale to, že Fedora (přinejmenším) tento ovladač dodává, aniž by (podle Linuse) dělala dost pro to, aby se dostal do upstreamu. Linusova slova:

Mám vztek na lidi od distribucí. Už léta distribuce mluví o „nejprve do upstreamu“ kvůli tomu, jaká pohroma byl kvůli fragmentaci Linux-2.4. A většina z nich to také tak dělá a dělá to poměrně dobře.

Ale nejenom že Fedora nedodržuje pravidla, ale vím, že lidé od Fedory si aktivně vymýšlejí výmluvy, proč nedodržují pravidla. Vím, že Red Hat zaměstnává (nemám tušení jestli na plný nebo částečný úvazek) vývojáře Nouveau, a z tohoto důvodu by se Red Hat měl pochlapit a říct, že „začlenění do upstreamu“ je pro ně priorita.

Zaznělo mnoho důvodů, proč Nouveau ještě nebylo začleněno, v rozsahu od „ještě není připraveno“ a „nestabilní API pro uživatelský prostor“ po „ještě jsme si nenašli čas“. Skutečná překážka však v nedávné době byl binární blob, který je ovladačem nahráván do některých GPU NVIDIA. Tento kus kódu známý jako „voodoo“ nebo „ctxprogs“ byl získán pozorováním proprietárních ovladačů při práci. Vzhledem k tomu, že nikdo od projektu Nouveau tento kód nenapsal, nikdo se pod něj také nechce podepsat; není jasné, jestli ho je možné legálně distribuovat. Linuse neobměkčil ani tento důvod, ale fakt jako takový zůstává: Vývojáři berou řádek Podepsáno kým: (Signed-off-by:) vážně a nehodlají ho připojit k něčemu, co by mohlo být právně napadnutelné.

Zjevné řešení, takové, které bylo aplikováno mnohokrát předtím, je vytáhnout firmware z ovladače a nahrát ho do jádra za běhu. A to se přesně u Nouveau stalo: Ben Skeggs věnoval spoustu práce tomu, že ctxprogs odstranil a použil API pro nahrávání firmwaru k nahrání firmware při zavádění ovladače. Dave poté sestavil strom s poníkem DRM Nouveau a požádal o jeho přetažení do 2.6.33. A Linus přesně to udělal.

Potenciální uživatelé budou muset i tak získat „ctxprogs“ odjinud. Z kdovíjakého důvodu jsou ukazatele na „odjinud“ těžko k nalezení, ale autor článku shodou okolností ví, že firmware lze nalézt v gitovém stromě Nouveau. Mělo by postačovat jednoduše popadnout správnou verzi a umístit ji do lokálního adresáře s firmwarem.

To vše naznačuje u Nouveau významný pokrok, ale závislost na firmwaru pochybného původu bude brzdit přijetí ovladače v dlouhodobém měřítku. Proto bylo dobré dozvědět se (z komentáře na LWN), že obsah blobu ctxprogs není tak neprůhledný, jak si mnoho z nás myslelo:

Dnes toho o ctxprogs víme hodně včetně toho, k čemu slouží [přepínání kontextu], co dělají [ukládání/nahrávání stavu PGRAPH] a většiny jejich operačních kódů. Stále je několik neznámých, které nám v současnosti brání sepsat ctxprogs od počátku, ale pracujeme na tom a bude to vyřešeno správně. Což znamená zahození progs od nvidie a sepsání našeho vlastního generátoru.

Zdá se, že se věci pohybují rychle i na této frontě; 15. prosince Ben oznámil dostupnost náhradního firmwaru pro hardware NVIDIA GeForce 6/7. Jde o první verzi tohoto kódu; hrdinní testeři určitě narazí na nějaké problémy. Ale zdá se, že alespoň pro tuto variantu hardwaru byly ty největší problémy překonány. Se štěstím nebude firmware od nvidie zanedlouho zapotřebí. V dlouhodobém měřítku by dokonce mohlo být možné naprogramovat do hardwaru zajímavé možnosti a tím překvapujícími způsoby rozšířit jeho schopnosti.

Bylo nebylo, uživatelé Linuxu si museli dávat velký pozor na to, jaký hardware si koupí. Během let většina těchto problémů vymizela; nyní je jednoduché najít systém, jehož hardware je plně podporován svobodným softwarem. Jedna z největších výjimek byla v oblasti grafik – výrobci jako Intel a ATI/AMD se rozhodli, že jejich hardware by měl být podporován svobodnými ovladači (většinou) a investovali zdroje do toho, aby se tak mohlo stát. NVIDIA spolupracuje mnohem méně a podpora pro její hardware tím odpovídajícím způsobem trpí. Zdá se, že problém s ovladači se blíží k vyřešení, ale nikdy bychom neměli zapomenout na snahu, která byla zapotřebí, aby se do tohoto stavu dospělo. NVIDIA by si v budoucnu naše peníze zasloužila mnohem více, kdyby tak velká snaha nebyla nutná.

       

Hodnocení: 100 %

        špatnédobré        

Nástroje: Tisk bez diskuse

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

18.1.2010 01:07 moo
Rozbalit Rozbalit vše Re: Jaderné noviny – 16. 12. 2009
chyba link na linusov vyrok :)
18.1.2010 08:16 Robert Krátký | skóre: 94 | blog: Robertův bloček
Rozbalit Rozbalit vše Re: Jaderné noviny – 16. 12. 2009
Už ne.
18.1.2010 08:27 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Jaderné noviny – 16. 12. 2009
On tam úplně chybí Linusův „podpis“.

V části o začleňovacím okně 2.6.33 pak tečka za textem „[Kernel Shared Memory, KSM] lze nyní odswapovat“ je mimo odstavec, takže třeba u mne se zalomí samotná tečka na nový řádek.
18.1.2010 08:48 Robert Krátký | skóre: 94 | blog: Robertův bloček
Rozbalit Rozbalit vše Re: Jaderné noviny – 16. 12. 2009
On tam úplně chybí Linusův „podpis“.
I na to platilo, když jsem výše psal, že už ne.
tečka za textem „[Kernel Shared Memory, KSM] lze nyní odswapovat“ je mimo odstavec
Už ne.
18.1.2010 09:08 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Jaderné noviny – 16. 12. 2009
I na to platilo, když jsem výše psal, že už ne.
Tvůj komentář jsem četl až po odeslání toho svého. Občas by se hodilo, kdyby Abíčko umělo upozornit na to, že na komentář, na který odpovídám, mezitím odpověděl někdo jiný…
MaSo avatar 18.1.2010 14:11 MaSo | skóre: 15 | blog: MaSo | Frýdek-Místek
Rozbalit Rozbalit vše Re: Jaderné noviny – 16. 12. 2009
+1
Webové síťové nástroje: http://nettools.mzettik.cz (pracuje se na tom - pomalu :-) )
18.1.2010 01:58 Jan Grmela | skóre: 45 | blog: Kilo šťávy z lachtana | Brno
Rozbalit Rozbalit vše Re: Jaderné noviny – 16. 12. 2009
Díky za náhled na situaci s Nouveau, moc jsem to teď nesledoval protože mi grafika už asi rok funguje bez problémů s proprietárními ovladači. A jelikož funguje docela dobře i akcelerace videa (a hry mimo Extreme Tuxracer a OpenTTD nehraju), tak jsem neměl ani důvod do toho šťourat.

Otevřené ovladače rozhodně vítám, už jen kvůli lepší dostupnosti řešení, které funguje out-of-box a nemusí se někde stahovat či kompilovat zvlášť, nepoužívám-li distribuční jádro.
Píšu pro Pivní recenze a protože mě to IT už fakt nebaví, tak jsme si s klukama postavili pivovar Lucky Bastard
Milan Lajtoš avatar 18.1.2010 02:18 Milan Lajtoš | skóre: 22 | blog: /blog/babraq
Rozbalit Rozbalit vše Re: Jaderné noviny – 16. 12. 2009
kmsg_dumper - áááá, BSOD prichádza aj do našich počítačových prímačov. ;)
“Every great achievement was once considered impossible.”
18.1.2010 21:22 radek
Rozbalit Rozbalit vše Re: Jaderné noviny – 16. 12. 2009
Onehda jsme se s kamosem hadali proc linux nema bsod a on ze nepada :) a hle, situace se zmenila, tak patrne v 2.6.33 bude neco kvuli cemu to "bsod" udelali :D btw, by me zajimalo kdy to dojde do toho stadia ze se bude ta chybova hlaska zobrazovat kazdych par hodin. Me dneska na oknech udelalo BSOD 2x, na tom by nebylo nic zvlastniho kdyby to nebylo behem 10 minut, pak jsem se nasral a sup na linux,
18.1.2010 11:40 Laco
Rozbalit Rozbalit vše Re: Jaderné noviny – 16. 12. 2009
Posrata nvidia by tiez mohla s noveau spolupracovat. Looseri... Preto mam grafiku intel..
Limoto avatar 18.1.2010 15:37 Limoto | skóre: 32 | blog: Limotův blog | Prostějov
Rozbalit Rozbalit vše Re: Jaderné noviny – 16. 12. 2009
A proto seš v roce 2010 bez podpory GLSL. Užij si to.
thingie avatar 18.1.2010 15:41 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Jaderné noviny – 16. 12. 2009
To by jednoho skoro naštvalo. Kdybych teda věděl co to je. :-)
Růžové lži.
18.1.2010 20:32 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
Rozbalit Rozbalit vše Re: Jaderné noviny – 16. 12. 2009
Asi OpenGL Shading Language, i když těžko říct, které linuxové aplikace to reálně využívají.
When your hammer is C++, everything begins to look like a thumb.
19.1.2010 11:47 Rivon
Rozbalit Rozbalit vše Re: Jaderné noviny – 16. 12. 2009
Např. Warsow ;)
q66 avatar 20.1.2010 15:11 q66 | skóre: 33 | blog: Q's CZ devblog
Rozbalit Rozbalit vše Re: Jaderné noviny – 16. 12. 2009
wine pro rendering direct3d
19.1.2010 12:21 xm | skóre: 36 | blog: Osvobozený blog | Praha
Rozbalit Rozbalit vše Re: Jaderné noviny – 16. 12. 2009
Nevim jak Intel, ale opensource radeon ovladače + nejnovější Mesa (budoucí verze 7.8) GLSL už podporují.
Svoboda je tím nejdůležitějším, co máme. Nenechte se o ní připravit, podporujte Pirátskou stranu!
18.1.2010 23:29 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Jaderné noviny – 16. 12. 2009
Nyní je možné nakonfigurovat jádro bez podpory ext2 a ext3, ale i tak tyto souborové systémy připojit pomocí kódu pro ext4.
Myslím, že z druhé věty se někam ztratil přísudek.

Jinak díky za další JN, jako obvykle hezké počtení...
thingie avatar 18.1.2010 23:36 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Jaderné noviny – 16. 12. 2009
Já si to umím představit i takto. Ne, že by to byla nějaká slohová velkolepost.
Růžové lži.
19.1.2010 11:17 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Jaderné noviny – 16. 12. 2009
Neztratil, jenom se trochu schoval :-) …je možné nakonfigurovat …, ale i tak [je možné] připojit…

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.