Jaderné noviny - 24 a 25/2008

17. 7. 2008 | Jirka Bourek | Jaderné noviny | 3261×

Podpora "falešného" zápisu. Integrita bloku dat. 2.6.26-rc6, "O trochu méně regresí". Představení nového stromu linux-staging. Výkonnost POHMELFS. Oops překladače. 2.6.26-rc7, "Hlavně aktualizace ovladačů a architektur". Prohlášení o postoji k linuxovým jaderným modulům.

Obsah

• Podpora "falešného" zápisu
• Integrita bloku dat
• 2.6.26-rc6, "O trochu méně regresí"
• Představení nového stromu linux-staging
• Výkonnost POHMELFS
• Oops překladače
• 2.6.26-rc7, "Hlavně aktualizace ovladačů a architektur"
• Prohlášení o postoji k linuxovým jaderným modulům

Následující obsah je © KernelTrap.

Citát: x86 je prostě dominantní

Je mi jedno, co říkají všichni ostatní - x86 je tak moc dominantní, že ostatní architektury musí žít s faktem, že 99.9 % ovladačů je psáno a testováno pro x86. Výsledkem je, že všechno ostatní je 'teorie'. Jsou některé ovladače dobré a opatrné? Ano. Je jich většina? Ne, a i kdyby byly, lidé, kteří dělají změny, je testují na x86. Architektury by se měly snažit chovat se co nejvíc jako x86, jak to jenom je možné, aby u nich nedocházelo k ošklivým překvapením.

Linus Torvalds, zpráva z 3. června 2008 na Linux Kernel mailing list.

 

Podpora "falešného" zápisu

10. června, originál

V sérii sedmi patchů navrhl Arnd Bergmann podporu zápisu do připojených souborových systémů cramfs v paměti. Záměrem je použít ji například na kořenovém souborovém systému pouze pro čtení, jako jsou CD-ROM nebo komprimované obrazy initrd. Ani v jednom případě nejsou data zapisována zpět na médium, ale zůstávají v cache stránek/inodů/dentry, jako to dělá ramfs. Reakce byly různé.

Když Arnd řekl, že je to alternativa ke komplexnějšímu unionfs, kde dočasný souborový systém překrývá souborový systém pouze pro čtení, a že podobnou podporu by bylo možné přidat do ostatních souborových systémů, bylo poukázáno na to, že by se více vyplatilo zaměřit se na jedno řešení, které by fungovalo pro všechny souborové systémy. David Newall zdůraznil: Mnohonásobné implementace jsou receptem na chyby a zmatek ve vlastnostech. Erez Zadok se přidal: Jsem pro obecnější přístup, takový, který by fungoval pro drtivou většinu souborových systémů, které lidé používají se sjednocováním [unioning], nejlépe pro všechny. Pak dodal, že modifikací cílového sjednoceného [union] souborového systému by se dalo získat víc než modifikací několika zdrojových souborových systémů. Arnd v principu souhlasil, ale poznamenal, že to by zvýšilo komplexitu. Naznačil, že se nad tímto nápadem ještě zamyslí, a pak dodal:

Můj nápad byl, aby to bylo nanejvýš v cramfs, squashfs a iso9660, souhlasím s tím, že udělat to i pro jeden zapisovatelný souborový systém by přidalo příliš mnoho komplexnosti. Neměl jsem v úmyslu začít nějakou stěžejní diskuzi o tom, jak to udělat správně, jenom jsem si všiml, že existuje půl tuctu implementací, které jsou několik let staré a nijak se neblíží začlenění do hlavní řady, přestože jednodušší přístup poskytuje podmnožině uživatelů rozumnou sémantiku.

 

Citát: to by vyžadovalo přepracování od základů

Neřekl bych, že chci mít svou vlastní sérii patchů, protože TuxOnIce neodstraňuje ani nepřepracovává swsusp či uswsusp, ale sedí vedle nich. Nesnažím se změnit swsusp na TuxOnIce, protože to by vyžadovalo kompletní přepracování swsusp od základů (TuxOnIce dělá všechno kromě atomického kopírování/obnovování a s tím spojené přípravy/úklidu odlišně).

Nigel Cunningham, zpráva z 11. června 2008 na Linux Kernel mailing list.

 

Integrita bloku dat

11. června, originál

Tyto patche umožňují připojovat v blokové vrstvě/vrstvě souborového systému k I/O informace o integritě dat (kontrolní součty a další) a přenést je přes celý I/O stack na fyzické úložné zařízení, psal Martin Petersen. Metadata integrity mohou být generována v těsné blízkosti původních dat. Hostitelské adaptéry, RAID pole a fyzické disky s příslušnou funkcí mohou integritu dat ověřovat a přerušit I/O v případě neshody. Martin poznamenal, že v současnosti tato podpora existuje pouze pro SCSI disky, ale pracuje se na přidání do SATA disků a SCSI pásek - S malými odchylkami kvůli omezením protokolu je navržený formát pro SATA identický s tím pro SCSI.

Martin dále vysvětlil, jak to funguje: SCSI disky mohou obvykle být přeformátovány tak, že sektory mají 520 B, čímž se v každém sektoru uvolní 8 bytů. Těchto 8 bytů bylo tradičně využíváno RAID řadiči k ukládání interních ochranných informací. DIF (Data Integrity Field, pole integrity dat) je rozšíření SCSI blokových příkazů, které standardizuje formát těchto 8 bytů a definuje způsoby interakce s obsahem na úrovni protokolu. [...]

Když HBA (Host Bus Adapter, adaptér hostitelské sběrnice) zapisuje, pomocí DMA přenese 512 bytů z paměti hostitele, vygeneruje odpovídající metadata a po drátech pošle 520 bytů. Disk ověří integritu dat předtím, než ji zapíše na stabilní úložiště. Když se čte, disk pošle 520 bytů ze sektoru, HBA ověří integritu dat a pak pomocí DMA zapíše 512bytový sektor do paměti hostitele.

 

Citát: Pořádné testování MM

- Tohle je verze, která opravuje chyby 2.6.26-rc5-mm2, která opravovala chyby 2.6.26-rc5-mm1. Do -mm3 nebyly znovustaženy žádné gitové stromy (nebyly znovustaženy ani do -mm2).

Cílem je odstranit z cesty všechny pitomé chyby, aby bylo možné to pořádně otestovat.

- Prosím, pořádně MM otestujte.

Andrew Morton, zpráva z 12. června 2008 na Linux Kernel mailing list.

 

2.6.26-rc6, "O trochu méně regresí"

12. června, originál

Rád bych řekl, že diffy se zmenšují a věci zklidňují, ale lhal bych, začal Linus Torvalds oznámení jádra 2.6.26-rc6. Další týden, další -rc, dalších 350 commitů. Ano, diff je menší oproti tomu z rc4 na rc5 (přestože commitů je v něm více), takže jsme na správné trajektorii, ale doufal jsem, že v tomto stádiu to bude méně vřít.

Jako obvykle je většina změn v ovladačích (druhé nejsilnější jsou aktualizace architektur). Největší podíl mají aktualizace DVB, ale jinak jsou změny vcelku rozprostřené. Jak bylo zmíněno, diffy jsou menší, commitů je více a ano, většina z nich jsou skutečně jenom malé a triviální opravy.

Vyzkoušejte ho, zase bychom jednou měli mít méně regresí.

 

Citát: Opravdu byste měli být vyděšení

Tohle je případ, kde byste měli skutečně být vyděšení, takže FUD je zcela na místě.

Nick Piggin, zpráva z 11. června 2008 na Linux Kernel mailing list.

 

Představení nového stromu linux-staging

14. června, originál

No skvěle, jen ne zase-další-jaderný-strom, to je přesně to, co svět potřebuje... začal Greg KH a pokračoval: ano, toto je oznámení nového jaderného stromu, linux-staging.

V dlouhé a klikatící se diskuzi s ostatními jadernými vývojáři přišla řeč na to, že pro firmy a vývojáře neexistuje místo, kam by mohli dávat svůj kód k testování v době, kdy je pročišťován kvůli začlenění do jaderného stromu. Všechny různé subsystémy mají stromy, ale ty obvykle chtějí jenom kód, který přijde do tohoto vydání, maximálně do toho příštího. Věci, které jsou začlenění více vzdáleny, nemají kam jít. Takže tady je pro ně strom.

V readme vytvořeném pro tento nový strom Greg dodává: Strom linux-staging byl vytvořen pro ovladače, souborové systémy a další napůl-zásadní přírůstky v linuxovém jádře, které ještě nejsou v daném okamžiku připraveny k začlenění. Také požadoval, aby byl nový strom začleňován do linux-next, což vedlo Theodora Ts'o k dotazu: Znamená to, že se povaha linux-next mění? Myslel jsem, že jediným důvodem pro linux-next bylo obsahovat to, co bude v blízké budoucnosti tlačeno k Linusovi, abychom mohli zkontrolovat problémy s kompatibilitou.

Greg odpověděl, že doufal, že jeho -staging strom dostane výjimku, protože začleňuje pouze nové ovladače a souborové systémy a nemění žádné existující vlastnosti. Jsou v něm věci, díky kterým mohou uživatelé zprovoznit hardware, který v současnosti není jádry z kernel.org vůbec podporován. Jako příklad uvedl: Jsou tam 2 velké síťové ovladače, které podporují velký rozsah zařízení, a někteří lidé by byli rádi, kdyby fungovaly :)

 

Citát: problémy často vyplavou na povrch časem

Vždycky se rád ujistím o tom, že uplyne nějaký čas mezi přijetím opravy do Linusova stromu a jeho protlačením do -stable, protože čas většinou umožní vyplavat na povrch posledním zbývajícím problémům zavedeným nějakou změnou bez ohledu na to, jak zdánlivě jednoduchý ten patch je.

David Miller, zpráva z 9. června 2008 na Linux Kernel mailing list.

 

Výkonnost POHMELFS

16. června, originál

Pravidelně spouštím různé benchmarky, kde porovnávám POHMELFS, NFS, XFS a Ext4 a posílám jejich výsledky. Hlavním cílem POHMELFS v tuto chvíli je být v podstatě tak rychlý, jako je lokální souborový systém pod ním. A to taky je... psal Jevgenij Poljakov a tvrdil, že síťový souborový systém POHMELFS se chová o 10 % až 300 % rychleji než NFS podle operace, která je prováděna. Konkrétně poznamenal, že jsou stále problémy s náhodným čtením, což je oblast, na kterou se v současnosti zaměřil a snaží se ji opravit. Pak shrnul nové vlastnosti v nejnovějším vydání:

• vyvažování čtecích požadavků (čtení dat, výpis adresáře, vyhledávací požadavky) mezi několik serverů
• zápisové operace se posílají několika serverům a jsou dokončeny jenom v případě, že všechny pošlou potvrzení
• schopnost přidat a/nebo odstranit servery z pracovní skupiny z uživatelského protoru za běhu
• dokumentace (základní přehled a příkazy protokolu)
• příkaz pro přejmenování
• několik nových připojovacích voleb k ovládání chování klienta místo natvrdo nastavených hodnot

V pohledu do budoucna Jevgenij řekl, že tohle je pravděpodobně poslední vydání implementace klientské strany v jádře, které není určeno k opravování chyb. Naznačil, že další vydání by se mělo zaměřit na přidávání vlastností na stranu serveru, které jsou potřeba pro distribuované paralelní zpracování dat (jako je schopnost přidávat nové servery pomocí příkazů ze sítě od jiného serveru), pročež většina práce bude věnována kódu serveru.

 

Citát: Uznej chybu

Malá rada: příště, až budu tvrdit, že nějaký tvůj kód je zabugovaný, buď prostě uznej chybu, nebo buď ticho. Budeš vypadat chytřeji.

Linus Torvalds, zpráva ze 17. června 2008 na Linux Kernel mailing list.

 

Oops překladače

19. června, originál

V žebříčku statistik na kerneloops.org rapidně postupuje nový oops, začal Arjan van de Ven a odkázal se na svou webovou stránku, která automaticky shromažďuje jaderné oopsy a varování z různých mailových konferencí, bugzill a od speciálního klienta. Ohledně nejnovějšího oopsu napsal: Ten oops je selhání stránky ve funkci 'do_slit' v ext3 a jeho první ohlášení bylo v 2.6.26-rc6-git3. Linus Torvalds se o problém rychle začal zajímat a všiml si, že všechny oopsy se zdají být z architektury i686, takže řekl, že by to možná mohla být indikace, že chyba je nějakým způsobem specifická pro i686 (např. záležitost překladače?).

Těsně předtím, než Linus zaslal své emaily, Dave Airlie potvrdil, že se skutečně jedná o známou chybu překladače, která postihuje GCC 4.3.1. Hlášení o chybě říká, že jakýkoliv ext* souborový systém, který povoluje vlastnost dir_index, je snadno postižitelný. Linus to reflektoval ve svém emailu a řekl: Gaah. Měl bych si přečíst všechny emaily místo toho, abych plýtval časem ve snaze porovnat kód s tím, co mohu reprodukovat... Důvodem, proč hlášení o chybě od Red Hatu nebylo webovou stránkou kerneloops automaticky zachyceno, spočíval v tom, že oops byl nahlášen v jpeg obrázku, takže Arjan zavtipkoval: Možná jednoho dne, až se budu opravdu nudit, implementuji [do kerneloops.org] OCR ;)

 

Citát: Lidé žijící na hraně

Předpokládal bych, že 64bitové jádro je pro lidi, kteří žijí na hraně, běžné, ale možná jsem mimo.

Linus Torvalds, zpráva ze 19. června 2008 na Linux Kernel mailing list.

 

2.6.26-rc7, "Hlavně aktualizace ovladačů a architektur"

21. června, originál

Další týden, další -rc, oznámil Linus Torvalds, jako vždycky je hlavně o ovladačích a aktualizacích architektur - přes 90 % změn je v jednom nebo v druhém.

Velká část (ve skutečnosti okolo dvou třetin aktualizací ovladačů) je pozdní začlenění AGP/DRM aktualizace, která přidává podporu pro některé nové grafické karty od Intelu a ATI. A velká část aktualizací architektur jsou samozřejmě nevyhnutelné změny v def_config. Nemám radost z načasování podpory pro ty nové karty, ale stejně tak nesnáším zdržování nových ovladačů. Samozřejmě doufám, že nemůže dojít k žádným regresím, protože přidaný kód je téměř zcela pro věci, které předtím nebyly podporovány vůbec.

Nakonec to Linus shrnul: Pokud budete ignorovat aktualizace ovladačů a architektur, zbytek je vcelku nevýznamný. Polovina z něj je v síťování, polovina zbytku jsou aktualizace souborových systémů (hlavně ocfs2). A pak různé povrchnosti jinde, jako například nějaké aktualizace plánovače.

 

Citát: Uzavřené moduly škodí

Tohle prohlášení nemá ničemu 'bránit', je to pouze oznámení faktu, že velmi velké množství vývojářů jádra Linuxu má pocit, že linuxové jaderné moduly s uzavřeným zdrojovým kódem škodí uživatelům, firmám a komunitě okolo jádra jako celku.

Greg KH, zpráva ze 23. června 2008 na Linux Kernel mailing list.

 

Prohlášení o postoji k linuxovým jaderným modulům

23. června, originál

Jako součást Technického výboru Linux Foundation se se záležitostmi okolo modulů s uzavřeným zdrojovým kódem setkáváme neustále, takže jsme chtěli udělat něco, co by se dalo považovat za obecné 'veřejné prohlášení' o těchto modulech, co bude snadno pochopitelné a bude možné na to ukázat, když budou mít lidé dotazy, začal Greg KH. Strávili jsme na tom nějaký čas, ptali jsme se některých dalších významných přispěvatelů a správců jádra a to, co vzniklo, najdete níže. FAQ na webových stránkách Linux Foundation uvádí o tomto prohlášení, které bylo podepsáno téměř 140 jadernými hackery, více informací. Prohlášení zní:

My, níže podepsaní vývojáři jádra Linuxu, považujeme všechny linuxové jaderné moduly či ovladače s uzavřeným zdrojovým kódem za škodlivé a nežádoucí. Opakovaně jsme zjistili, že jsou újmou pro uživatele Linuxu, obchody a větší linuxový ekosystém. Takové moduly anulují otevřenost, stabilitu, flexibilitu a udržovatelnost linuxového vývojového modelu a uzavírají svým uživatelům přístup k odborným znalostem linuxové komunity. Výrobci, kteří poskytují jaderné moduly s uzavřeným zdrojovým kódem, nutí své zákazníky vzdát se klíčových výhod Linuxu nebo zvolit nového výrobce. Takže, aby získali plné výhody úspory nákladů a sdílené podpory, které může open source nabídnout, naléháme na výrobce, aby přijali politiku podpory svých uživatelů v Linuxu otevřeným jaderným kódem.

       

Komentáře

[Filip Jirsák]

To se vždycky psal v JN bajt anglicky (byte), nebo je to v dnešní části Integrita bloku dat novinka? Ono to pak dělá i problémy se skloňováním, protože ve slovech bytů nebo 512bytové už není ani ten originální anglický tvar. Navíc se myslím bajt používá v tomto českém přepisu úplně běžně. Takže, nebylo by lepší (alespoň pro příště) psát bajt, bajtů, 512bajtové atd.?

[Luk]

To se vždycky psal v JN bajt anglicky (byte), nebo je to v dnešní části Integrita bloku dat novinka?

Záleží na tom, kdo to překládá. Robert psal, pokud vím, vždycky bajt. U ostatních lidí nevím.

[Robert Krátký]

Je to tak. Já psal bajt, Jirka píše byte. Nechávám to však záměrně, protože mi připadá, že je to dostatečně jasné v obou podobách. Takže to beru jako věc překladatelského stylu, do kterého se snažím zbytečně nezasahovat.

[Do existujicich terminu by bylo dobre nezasahovat]

"Bajt" ale neni prekladem slova "Byte", preklad by byl "slabika" a proto navrhuji misto foneticke anglictiny pouzivat to, co se jen tak mimochodem vyucuje na vsech skolach a jen tak mimochodem uziva na celem svete -> Byte, bez vyjimky. Nebo snad je planovano napr. misto BlockQuote psat "blokkvout" ?

[Filip Jirsák]

„Bajt“ je český termín, kterým se překládá anglické slovo „byte“. Není to fonetická angličtina, je to čeština. Převzetí fonetického tvaru slova z cizího jazyka je totiž v češtině jeden ze způsobů přejímání český slov. Nevšiml jsem si, že by se na celém světě mluvilo česky, takže co se používá v jiných jazycích je pro debatu o češtině poněkud mimo téma. Navíc pouhé projetí seznamu „v jiný jazycích“ u hesla bajt na Wikipedii naznačuje, že to s tím „na celém světě, bez výjimky“ nebude zas až tak slavné.

[alblaho]

Bajt je zažitý termín, sice to není tak česky jako "slabika", ale dá se hezky skloňovat a tak. Psát v češtině "byte" považuji za archaismus.

[quanti]

to je poznamka kapku mimo misu - driv se to prevadelo jako "bajt" a najdete to i ve spouste starych ucebnic, ta tendence zkratka byla, kdyz jeste anglictina nebyla vseobecne rozsirena, aby to lidi umeli cist a necetli to "byte". Ted je situace jina, ale nevidim duvod, proc by se nemohl (ale ani musel) pouzivat bajt jako termin, ktery tu fungoval...

[geebranz]

Educational blog

cryotherapylaredo.com

[hwsoft]

No tvrdit ze x86 ma 99.9 % procet je od Linuise dost velky ulet. On uz asi nechape, ze Linux je nejrozsirenejsi v embeded zarizenich, kde se prakticky x86 nepouziva, nebo jen okrajove.

No nekteri lide to nechapou, ale je to tak, ze nikde jinde se Linux tak masove nerozsiril, jak v ruznych hrackach, WIFi AP , NAS, STB a dalsich zarizenich spotrebni elektroniky.

[Luk]

kde se prakticky x86 nepouziva, nebo jen okrajove

To bych v žádném případě netvrdil. Používá se poměrně vydatně (cca 21 % embedded trhu, druhá nejpoužívanější architektura), i když je samozřejmě pravda, že nemá převahu (vede ARM se cca 30 %).

[rollfree]

Muzete prosim uvest zdroj ? Snazil jsem se to najit, ale nedari se.

Zajimavy mne pripada tak vysoky podil ARMu oproti treba MIPSu. Kam se dneska podivam, tam jede neco na MISPu (multimedia: PowerPC, SH nebo MIPS, ADSL modemy: vetsinou MIPS, WiFi routery: taky vetsinou MIPS). Zajima me, kde je tolik tech ARMu. PDA (kde je vetsinou ARM) jedou vetsinove na Winech, navigace GPS myslim taky, na smartphonech taky asi moc ARMu na Linuxu nejede.

Diky. rolfree

[Robert Krátký]

jedou vetsinove na Winech, navigace GPS myslim taky

Např. TomTom, který má velký podíl, v Evropě nad 50 procent, má v navigacích, pokud vím, Linux.

[Luk]

Pokud vím, tak TomTom používá Linux jen v některých navigacích a v poslední době preferuje spíš Windows.

[kmarty]

Mohl bych vedet v kterych? Co ja vim, tak vsechny jeho PNA bez vyjimky jedou na Linuxu coz znamena minimalne vsechny s NavCore6, NavCore7 i nejnovejsi NavCore8. Vzhledem k tomu ze se to tyka i nejnovejsich Go730 a Go930, tak bych nerekl ze preferuje spis Windows

Jedine o cem vim ze neni "linuxovite" je staricky Tomtom Navigator6 coz je aplikace pro PDA, behajici na Windows Mobile nebo Symbian. A naopak to uz par let skomira na mrtvem bode.

[tvfun]

https://a.tvfun.me/index

[Luk]

Muzete prosim uvest zdroj?

Tady. Musím se ale přiznat, že to není úplně korektní. Nejde o přesná data o trhu, nýbrž o výsledku průzkumu prováděného serverem LinuxDevices.

[rollfree]

Diky.

[Ondrej 'SanTiago' Zajicek]

Pokud chapu ty vysledky spravne, tak ta vysledky nerikaji, jak casto se pouzivaji ktere platformy, ale kolik spolecnosti/vyvojaru pouziva ktere platformy. Nebere vubec potaz v to, ze nektereho zarizeni se prodaji miliony, zatimco jineho tisice.

[Luk]

Ano, je to tak.