Jaderné noviny - 20. 12. 2006

19. 1. 2007 | Robert Krátký | Jaderné noviny | 4254×

Aktuální verze jádra: 2.6.20-rc1. Citát týdne: Dave Jones. Proč nebyly zakázány proprietární moduly. 2.6.19: zákeřná chyba poškozující soubory. Přepracování NAPI.

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

Aktuální předverze řady 2.6 je 2.6.20-rc1, vydaná 13. prosince. V krátkém changelogu najdete dlouhý seznam patchů začleněných pro 2.6.20.

Od vydání -rc1 bylo do hlavního git repozitáře zařazeno několik desítek patchů (to je poměrně málo).

Aktuální verze -mm stromu je 2.6.20-rc1-mm1. Mezi nedávné změny patří nová verze systému pro ovladače v uživatelském prostředí, funkce pro oznamování nečinnosti na x86-64, mechanismus pro uvolňování stránek po kusech [lumpy reclaim mechanism] a nová verze dynamického času [dynamic tick].

18. prosince byla vydána verze 2.6.18.6; obsahuje slušnou řádku patchů (včetně jednoho týkajícího se bezpečnosti).

Adrian Bunk vydal verzi 2.6.16.36, ve které je trocha patchů a 2.6.16.37-rc1 s několika desítkami dalších.

Willy Tarreau nelenil a vydal 2.4.33.5 (dva bezpečnostní patche), 2.4.33.6 (jeden další) a 2.4.34-rc3 (asi poslední před konečným vydáním 2.4.34).

Citát týdne: Dave Jones

Přestože zdravotní pojištění od Red Hatu zahrnuje i problémy s "duševním zdravím", raději bych se této cestě vyhnul. Nedokážeme pořádně podporovat *jedno* jádro. Na které planetě by tedy dávalo smysl přihodit do hry ještě další varianty?

-- Dave Jones

Proč nebyly zakázány proprietární moduly

Chvilku se zdálo, že všechno půjde docela rychle. Martin Bligh podotkl, že místo pokusů o uždibování binárních modulů k smrti by bylo férovější je rovnou zakázat. Andrew Morton se o nápadu vyjádřil kladně pod podmínkou, že bude poskytnuto varování rok dopředu. Greg Kroah-Hartman spíchl patch, který by varování zařídil. A Linus se zpočátku omezil na komentování Gregovy poezie.

Obrat však nastal stejně rychle. Linus se vyslovil proti takové změně (CZ) a Greg patch stáhl (CZ). Vypadá to, že i v dohledné budoucnosti bude možné binární moduly bez zdrojových kódů do jádra natahovat - i když jejich distributory mohou čekat jiné potíže.

Natahování proprietárních modulů nebylo zakázáno z několika důvodů. Prvním z nich je fakt, že na tom není nic špatného. GPL poměrně jasně říká, že pokud má někdo kód licencovaný GPL, může si s ním dělat, co chce. Pokud chce dát své pěkné a svobodné jádro dohromady s velkým proprietárním balíkem, má na to právo. Takže zakazování proprietárních modulů problém napadá na špatném místě a pokouší se zakázat činnost, kterou licence povoluje.

I kdyby se GPL dala interpretovat tak, že zakazuje natahování binárních modulů, pořád je tu ještě otázka spravedlivého užívání [fair use]. Jako komunita se obecně kloníme spíše k širokému výkladu práva na spravedlivé užití. Ale spravedlivost je oboustranná. Několik lidí v diskuzi varovalo před přejímáním taktik, které si osvojil zábavní průmysl, a přehnaně benevolentním výkladem toho, co copyrightový zákon autorům umožňuje. Ben Collins to řekl takto:

Postupné změny namířené k uvázání jaderných modulů na konkrétní licenci(e) se podobají pomalému uzavírání obsahu (hudba/filmy), na které si lidé tak hlasitě stěžují. Stává se z toho DRM pro kód.

Skutečnost, že jsou někteří lidé ochotni uvažovat o využití DMCA k zajištění, aby nikdo neodstranil z kódu zákaz proprietárních modulů, dává tomuto pohledu za pravdu. Alan Cox poznamenal, že se z lidí stává to, proti čemu bojují. Většina lidí v komunitě by se pravděpodobně shodla na tom, že nechtějí být jako zábavní průmysl; to se zjevně dost podepsalo na nahlodání podpory pro zakazování proprietárních modulů.

GPL však mluví o distribuci; distribuuje-li někdo něco založeného na kódu licencovaném GPL, musí to dělat v souladu s podmínkami GPL. Takže na právně nejasnou půdu se dostává distribuování proprietárních modulů. Ale, jak připomíná Linus, samotný fakt, že lze modul natáhnout do jádra, z něj nemusí dělat odvozenou práci. Rozlišování toho, jestli něco odvozené je, nebo není, je komplikovaný proces. A často je nutné, aby měl poslední slovo soud. Ale zakázání všech proprietárních modulů na základě tvrzení, že jsou to všechno neoprávněně odvozené práce, by šlo obhájit těžko.

Výsledkem je, že v blízké budoucnosti nebudou do jádra přidána žádná technická opatření pro blokování binárních modulů. Nespokojenost s těmito moduly však přetrvává, jak je vidět z Gregovy zprávy, která doprovázela stažení patche:

Já už mám té celé záležitosti prostě plné zuby. Mám plné zuby lidí, kteří si myslí, že mají právo pořád porušovat můj copyright. Mám plné zuby lidí a společností, které naši licenci okatě překrucují, ale přijde jim to OK. Protože jsme volné společenství jednotlivců a ne firma nebo právnická osoba, mají společnosti tu drzost si myslet, že jim porušování licence projde.

Zdá se být jasné, že problém sám nezmizí, i když byl tento konkrétní přístup zamítnut. Nespokojeným vývojářům se nabízí právní řešení: pokud se ukáže, že je distribucí některého z binárních modulů porušován copyright, mají držitelé copyrightu právo jít k soudu a zarazit to. Snahy o prosazení dodržování GPL byly doposud většinou úspěšné. Nebylo by tedy překvapující, kdyby se někdy v průběhu roku jeden nebo více vývojářů rozhodlo podat žalobu na distributora binárního modulu. Ta nespokojenost jen tak neodezní.

2.6.19: zákeřná chyba poškozující soubory

Když Linus vydával verzi 2.6.19, vyjádřil se o ní s jistou dávkou sebevědomí:

Je to jedno z těch vzácných "dokonalých" jader. Takže pokud se vám ho náhodou s vaší konfigurací nepodaří zkompilovat (nebo se zkompiluje, ale pak začne provádět nehorázné perverzity s vaším jezevčíkem), buďte klidní, neb si můžete být jisti, že je to všechno vaše chyba, a měli byste se nad sebou zamyslet.

Ačkoliv toto jádro možná dostálo očekávání v mnoha oblastech, vypadá to, že se nad sebou někdo zapomněl zamyslet, a věci nedopadly dobře - a jezevčíci by raději neměli vystrkovat nos. Toto jádro totiž dokáže poškozovat ext3 souborové systémy - což původně nebylo v plánu.

Dobrá zpráva (pro uživatele) je to, že chybu je těžké vyvolat a většina přístupových způsobů funguje úplně bez problému. Zdá se, že hlavní problém se projevuje s určitým klientem pro BitTorrent, který má, mírně řečeno, nezvyklý způsob přístupu. Čas od času se části stránky zapíší jako nuly - až do konce stránky. Nečekejte, že bych vám vysvětlil, proč se to děje; vypadá to, že tomu zatím nerozumí nikdo. Řešení však může zahrnovat poměrně závažné říznutí do nízkoúrovňové správy paměti.

Zjevným původem problému je změna ve způsobu, jakým jsou v jádře sledovány nečisté stránky. Před 2.6.19 byly tyto informace v tabulkách stránek; jádro 2.6.19 však něco z toho přesunuje do struktury page. Tato změna umožňuje lepší sledování nečistých stránek v systému, což je dobře. Mohla by však také vynášet na světlo některé staré chyby.

Ne všechny tyto chyby musí být v jádře; v jednu chvíli Linus napsal demonstrační program, který ukazuje, jak může chybný program fungovat se staršími jádry, ale dočkat se překvapivých výsledků s 2.6.19. Podstatou je, že pokud program namapuje soubor do paměti, nemůže do té paměti dát více dat, než jaká je velikost souboru, a očekávat, že by nakonec data dorazila na disk. Byla to pěkná ukázka, ale nevypadá to, že by tato změna chování byla za popisovanými problémy.

Zmatky kolem přenášení a správy nečistých bitů stránek jsou v tuto chvíli první na seznamu podezřelých. Nevypadá to však, že by někdo dokázal ukázat na něco konkrétního - kromě skutečnosti, že ten kód vypadá dost ošklivě. Pravil Linus:

Hodně z toho je starý a ošklivý kód. Něco možná dokonce kód, který ani neměl fungovat, ale protože jsme v PTE udržovali _jiné_ nečisté bity, kterých se nikdo předtím nedotkl, nikdy jsme si neuvědomili, že kód, který si hraje s PG_dirty, je totálně šílený.

Takže Linus na to jde tak, že kód udržující přehled o nečistých stránkách bude přepracován na něco trochu rozumnějšího. Kvůli tomu už není test_clear_page_dirty(), protože ji prohlásil za "šílenou". Nový kód se místo toho snaží o lepší rozpoznání stavu, kdy už může být nečistý bit ze stránky odstraněn. Výsledkem jsou dvě možnosti: 1) stránka je ukládána do zálohy nebo 2) stránka už není relevantní (například při zkrácení souboru). Jako obvykle opravil Linus jen tolik, aby to s jeho konfigurací fungovalo, a zbytek nechal jako cvičení pro čtenáře.

Netvrdil však, že to problém vyřeší - jen už ten kód bude rozumnější. Doposud se neozval nikdo z těch, kdo problém dokázali reprodukovat. Pokud tím problém zmizí - a vývojáři uvěří, že nebyl jen zakamuflován - pak si nějaká verze této opravy patrně najde cestu do aktualizace 2.6.19. Pak by možná jezevčíci mohli vylézt z úkrytů.

Přepracování NAPI

NAPI ("nové API," i když už tak moc nové není) je mechanismus pro zmírnění počtu přerušení používaný u síťových zařízení. Když je síť hodně vytížená, může jádro bezpečně odhadnout, že příchozí pakety budou k dispozici, kdykoliv bude mít čas se na ně podívat. Takže není nutné, aby adaptér k oznamování těchto paketů používal přerušení (teoreticky i tisíce za vteřinu). Ovladač podporující NAPI tedy vypne přerušení o příjmu paketů [packet receive interrupt] a jádru poskytne metodu poll(). Když je jádro připraveno zpracovávat další pakety, zavolá se poll() s maximálním počtem paketů, který bude mít povoleno předat jádru; měla by zpracovat právě tolik paketů a skončit.

S NAPI může jádro zpracovávat výrazně vyšší množství paketů. Pomáhá snížení počtu přerušení, ale i pár dalších věcí. Způsob, jakým NAPI funguje, zmenšuje pravděpodobnost přeřazování paketů v jádře. A pokud dosáhne jádro bodu, odkdy už musí pakety zahazovat, budou takové pakety odhozeny ještě před předáním do síťového stacku. Více informací o NAPI získáte buď z tohoto starého článku na LWN nebo ze stránky na OSDL, která je novější a kompletnější.

I tato stránka bude možná brzy potřebovat aktualizaci, protože Stephen Hemminger navrhl novější NAPI (NNAPI?), které poněkud mění API pro ovladače. V současné implementaci jsou ve struktuře net_device dvě pole týkající se NAPI: poll(), což je funkce volaná pro odběr paketů z adaptéru, a weight, která v podstatě představuje nejlepší odhad autora ovladače ohledně toho, jak důležité je dané rozhraní ve srovnání s ostatními v systému. Stephenův patch tyto parametry přesouvá do samostatné struktury (struct napi_struct), čímž jsou dány dohromady s několika dalšími NAPI strukturami.

Struktura napi_struct je pak přesunuta zpět do struct net_device, ale tu ovladače používat nemusí. Účelem patche je pravděpodobně oddělení NAPI informací od konkrétních síťových zařízení. Existují adaptéry, které poskytují více portů, z nichž každý má samostatné přerušení pro příjem. Oddělené informace o NAPI umožňují, aby všechny tyto porty sdílely jediný NAPI stav a jedinou funkci poll(); taková organizace lépe odpovídá skutečnému hardwaru.

Tento patch se v hlavním jádře neobjeví před 2.6.21, takže autoři ovladačů mají trochu času zareagovat. Potřebné změny jsou relativně jednoduché. První věc je najít pro zařízení strukturu napi_struct; pokud neexistuje důvod to udělat jinak, bude nejlepším řešením použít nové pole napi ve struktuře net_device. Takže pokud se současný kód inicializuje nějak takto

    dev->weight = MY_WEIGHT;
    dev->poll = my_poll;

vypadala by nová verze asi takhle:

    dev->napi.weight = MY_WEIGHT;
    dev->napi.poll = my_poll;

Prototyp funkce poll() se však trochu změnil; teď vypadá takto:

    int (*poll)(struct napi_struct *napi, int budget);

Ukazatel na strukturu net_device byl nahrazen ukazatelem na strukturu napi_struct. Ve většině případů lze ukazatel net_device získat voláním podobným tomuto:

    struct net_device *dev = container_of(napi, struct net_device, napi);

Význam parametru budget se také trochu změnil; jde teď o jediný indikátor počtu paketů, které smí funkce poll() předat jádru. Už není nutné zvlášť kontrolovat pole quota. A konečně - návratová hodnota by měla být počet paketů, které byly skutečně zpracovány.

Funkce týkající se NAPI v síťovém systému byly upraveny celkem předvídatelně. NAPI je spouštěno jedním z těchto způsobů:

    void napi_schedule(struct napi_struct *napi);
    /* nebo */
    int napi_schedule_prep(struct napi_struct *napi);
    void __napi_schedule(struct napi_struct *napi);

A vypínáno takto:

    void napi_complete(struct napi_struct *napi);

Aktuální patch je v raném stádiu, takže by se rozhraní během následujících měsíců mohlo ještě změnit. Nikdo se však proti tomu nepostavil, takže je velká šance, že nějak začleněno bude.

       

Komentáře

[Josef Kufner]

Takže kdy už to bude konečně stable?

[Pavel Píša]

Chyba je v 2.6.19.2 opravena. Pokud se tedy nevyskytne další podvraťák, tak mohou mít jezevčící klid.

Odkazy:

Původní diskuze

http://thread.gmane.org/gmane.linux.kernel.mm/12931/focus=479227

Zařazení patche do 2.6.19.2

http://thread.gmane.org/gmane.linux.kernel/481127/focus=481168

Pokud čtete Jaderné Novinky na ABC Linuxu, je nutné počítat s tím, že mají kvůli pravidlům svého zdroje dost velké zpoždění.

Přesto jsou zajímavé a užitečné, protože rekapitulují co se dělo nejdůležitějšího a mnoho věcí přibližují svojím populárnějším přístupem i širšímu okruhu zájemců.

Sám je čtu především proto, že mě upozorní na to, kdy byl originální článek uvolněn a projdu si to, co jsem přehlédl.

K textu v češtině mám ale ze svého pohledu výhradu, že se snaží anglické termíny překládat a činí je těžko vyhledatelnými a nesrozumitelnými. Na kombinaci češtiny s anglickými termíny by se mi naopak líbilo, že je jasně vidět, co je text článku a co jsou specifické termíny. (Termíny by mohly být při prvím výskytu česky vysvětleny v závorkách.) Zároveň by to těmto termínům učilo případné zájemce o programování jádra, kteří ještě mají s komunikací pouze v angličtině problémy. Pokud se do jádra zaboří více, tak jim stejně nezbyde než tu angličtinu nějak zvládnout. LKML, ALKML, atd opravdu překladateli na češtinu vybavit, na rozdíl od EP, nikdo nedokáže.

[Filip Jirsák]

Já naopak za ten kompletní český překlad děkuju. Vývoj jádra sleduju pouze jako zajímavost a pouze tady v Jaderných novinách – a to právě díky tomu, že jsou Jaderné noviny „komplet“ česky, kdybych se měl zabývat ještě anglickými termíny specifickými pro nízkoúrovňové programování a vývoj jádra, už by mi ta „zajímavost“ nestála za tu námahu. Je to pro mne takový kvalitní manažerský souhrn Pokud bych se chtěl dozvědět něco víc, přečtu si nejdřív příslušnou pasáž v originále, a pak nebudu mít problém s dohledatelností termínů.

[Prcek]

Nejaky chybicky:
"mají držitelé copyrightu právu jít k soudu a zarazit to"
"Zdá se, že hlavní problém se projevuje s určitým klientem pro BitTorrent, která má, mírně řečeno, nezvyklý způsob přístupu"

A jeste bych mozna zmenil "lidi" na "lidé":
"na které si lidi tak hlasitě stěžují"
"Skutečnost, že jsou někteří lidi ochotni uvažovat"

Sorry za hnidopisstvi .

[Robert Krátký]

Díky, opraveno.

[andree]

kludne podajte zalobu na nvidiu a ati prestanu vyrabat drivere uplne a dobacujeme tiez uplne..

[Robert Krátký]

Jenže o těchto ovladačích se právě nemluví. U těch je naprosto jasné, že odvozené od jádra nejsou.

[Petr (DotaZ) Jakubec]

je treba si tu problematiku nastudovat lepe priteli. To co zminujes neni vubec pripad, ktery vyvojari resi (chteji resit). Navic ti zrejme unikl dalsi fakt, a to ze tyto firmy to nedelaji jako milost, ale jako komercni tah. jde jim o zisk z prodeje svych g.karet linuxakum (a neni na tom preci nic spatneho!). A uz z toho duvodu tvuj scenar proste nenastane.

Zaroven jsem velmi potesen, ze nakonec k zakazu nedojde. i mne zakaz prisel proti idei gpl. navic si myslim ze vic zmuze klidna sila, nez stekani vzteklych psu.

PS: s temi jezevciky je to na povazenou - nastesti mam krizeneho vlcaka - ale buhvi muze se to sirit ...

[Marián Kyral]

V krátkém changelogu najdete dlouhý seznam

Že jádro má krátký a dlouhý changelog vím, ale i tak jsem se na chvíli zarazil a uvažoval, co to vlastně znamená

[Robert Krátký]

Pun intended.

[Robert Krátký]

Do blogu jsem vložil překlad celé odpovědi, ve které Linus argumentuje, proč natahování proprietárních modulů nezakazovat.

[Robert Krátký]

A teď jsem přidal ještě reakci Grega KH.

[Milan Hejpetr]

Co se tyce binarnich modulu, jsem rad, ze alespon prozatim zvitezil zdravy rozum nad zaslepenym fanatismem. Neni to vubec legrace a bude to "velky den" pro Linux, az se s fanatismem rozloucime uplne. Ano - zbozne prani.

[Robert Krátký]

Nemyslím, že by to bylo tak jednoznačné. Ačkoliv určitě existují vývojáři, kteří by se dali označit za fanatiky, byla celá tahle věc motivována snahou o zamezení porušování licence, ke kterému v mnoha případech dochází. Pod pojmem proprietární modul si každý představí ovladače od nVIDIA nebo ATI. Jenže to jsou právě ty skvělé příklady modulů, které odvozené nejsou. Proti nim to namířeno nebylo.

Ale jinak pochopitelně souhlasím s tím, že je dobře, když tento pokus neprošel, protože by hlavnímu problému nezabránil a jen by ztížil život obyčejným uživatelům. Nehledě na to, že by šel těžko ospravedlnit, jelikož by vlastně sám o sobě představoval porušení GPL.

[Milan Hejpetr]

To jako, ze by firmy ATI a Nvidia mely vyjimku ? To urcite ne. Vysledkem by byl konec ovladacu pro tyto videoadaptery (zmineni vyrobci je pravdepodobne nehodlaji z mnoha duvodu otevrit), cekani na otevreny ovladac, vznikly reverznim inzenyrstvim (zpocatku plno chyb a i pozdeji pochopitelna neschopnost rychle reagovat na novinky na trhu) a z toho plynouci razantni pokles atraktivnosti Linuxu na desktopu. Prace vyvojaru grafickych prostredi by do jiste miry prisla vnivec...
Totez treba v pripade nekterych zvukovych karet - kuprikladu ani po roce a pul neexistuje otevreny ovladac pro Soundblaster X-Fi (ja vim, ze zde ted vyskoci jako certik z krabicky jeden nejmenovany a zacne s prednaskou, jak Soundblastery stoji za ho... - jenze to nic neresi a vetsine uzivatelu Soundblastery s prehledem postacuji) a spousta uzivatelu ceka jak na smilovani na proprietarni, ktery ma byt snad k dispozici ve 2. ctvrtine tohoto roku.
Idea, ze by vse kolem ovladacu melo byt otevrene je sice krasna, ale naprosto mimo realitu. Svet kolem nas je uplne jiny a domnenka, ze lze vyrobce hw donutit, aby vydavali vsechny ovladace otevrene, pripadne aby zverejnovali vsechny detaily vsech zarizeni je hluboce, hluboce naivni a muze vest k tomu, ze z Linuxu by byl jakysi obskurni OS, provozovatelny pouze na starem hardwaru, zcela na okraji zajmu.

[Robert Krátký]

Tak nějak netuším, kde jsi tyhle všechny věci v mé reakci vyčetl. Copak jsem například někde zmiňoval, že by některé ovladače měly dostat výjimku?

Já jsem napsal, že pod pojmem "proprietární ovladač" si většina lidí představí jen ovladače grafických karet od nVIDIA a ATI. A na základě toho pak říkají: co je na proprietárních modulech špatného? Neuvědomují si, že celá tahle akce nebyla namířena proti ovladačům grafických karet. Ty nikomu nevadí. Ani vývojářům, kteří ten zákaz prosazovali. Problém jsou moduly, které GPL skutečně porušují. A proti těm to bylo namířeno.

Byl to chybný postup a je dobře, že neprošel. Ale to, že neprošel, neznamená, že by najednou bylo v pořádku, když proprietární moduly (a nejedná se o ovladače gr. karet) porušují copyright vývojářů jádra. Neboli - sice je dobře, že nebyl takový nesmyslný zákaz zaveden, ale tím nebylo posvěceno porušování GPL, ke kterému dochází. Tím bylo jen řečeno, že tento konkrétní způsob řešení problému byl blbý.

[Milan Hejpetr]

Vyvojarum, kteri prosazovali zakaz sice mozna nevadi ovladace od ATI a Nvidie, ale na vysledny znicujici efekt by to nemelo naprosto zadny vliv. S poslednim odstavcem souhlasim. Jinak jsem psal do urcite miry obecneji - ne jen jako reakci na tvuj prispevek (asi jsem to mel dat najevo).

[Robert Krátký]

Myslím, že Greg KH to ve svém mailu popisuje poměrně jasně: co je problém, co není, a kde se stala chyba.

[Roman]

Mohl byste mi prosím vysvětlit, jak by bylo možno zakázat proprietární ovladače bez toho, že by se to nedotklo ati a nvidie a tyto nedostaly vyjimku?

[Robert Krátký]

Copak jsem něco takového řekl?

[..... Izak .....]

A k tem Sound Blasterum .... ano kdyz jsem si karty vybiral, tak podle ALSA .... a to ze nema X-Fi je promlem pouze Creative, ktera vyrabi nic moc zvukovky a dela hogo fogo .... radsi jsem si koupil M-Audio.

Jinak ale k situm bednam ala Creative, Logitech, Genius, Redstar etc to asi staci .... jenze ja mam k PC pripojeny pasivni 2pasmove monitory na skoro HI-FI zesilovaci .... a tam to poznat je.