Portál AbcLinuxu, 24. dubna 2024 09:04
Aktuální verze jádra: 2.6.22-rc5. Citáty týdne: Con Kolivas, Bartlomiej Zolnierkiewicz. Další citáty týdne - obrazy z války (slov). btrfs a NILFS. Jak získat zprávy z jádra.
Aktuální předverze je 2.6.22-rc5, vydaná 16. června. Obsahuje hodně oprav - takže si Linus trochu postěžoval, že je i takto pozdě ve vývojovém cyklu začleňováno tolik věcí. Vizte podrobnosti v dlouhém changelogu.
Od vydání -rc5 bylo do hlavního git repozitáře přidáno jen několik patchů.
Během minulého týdne nevyšla žádná nová verze stromu -mm ani starších jader. Všichni měli zjevně plné ruce práce s "diskuzí" o GPLv3.
Takže mám dost. Končím tady provždycky. Chci odsud vypadnout dřív, než mě to natolik otráví, že bych nakonec začal používat Windows. Občas si možná trochu pohraju s kódem v uživatelském prostoru, ale jádro je pro mě černá díra, do jejíhož horizontu událostí už nechci nikdy vstoupit.
-- Con Kolivas
Z toho příběhu plyne poučení, že se v současné době prostě nevyplatí kontrolovat cizí kód [code review]. Z osobního hlediska je výhodnější počkat, až se do jádra dostane patch plný chyb, a pak ty problémy opravit (aspoň si vás někdo všimne). Aby se to změnilo, měli bychom klást větší důraz na důležitost kontroly kódu tím, že budeme "odměňovat" lidi, kteří tomu věnují svůj čas, a "odměňovat" vývojáře/správce, kteří budou brát kontroly kódu vážně.
Jak je vidět, v nedávném GPLv3 flamewaru o 1000 zprávách je jen málo věcí, které by ospravedlnily tak velké plýtvání bity. Tady je pár ukázek.
Myslím, že Open Source komunita (a FSF také) by udělala mnohem lépe, kdyby se *nezaměřovala* na "právní pravidla" ohledně toho, co se smí a nesmí dělat, a raději vynaložila větší úsilí na ukazování lidem, že celá ta "Open Source" věc vlastně funguje. A já jsem přesvědčen, že právě to Linux posledních deset let dělá!
Ale pokud tou otázkou myslíš "řekl bys, že je GPLv3 v pohodě bez toho nového povídání v sekci 6 o 'spotřebitelských zařízeních'?", pak by odpověď byla ano, myslím, že současný návrh GPLv3 vypadá, až na tu drobnost, dobře.
Nerozumím tomu, jak můžeš tvrdit, že výrobce omezuje tvoje svobody. _Ty_ jsi se rozhodl, že půjdeš a produkt si koupíš, i když jsi věděl, že se výrobce nepřetrhne, aby ti usnadnil zařízení hacknout. V mnoha případech ani výrobce nemá na vybranou (napadají mě třeba kanály a certifikace 802.11b, GSM atd.), jestli věci uživatelům otevřít. A změna licence s tím nic nevykouzlí.
-- Paul Mundt
V tom, co dělá TiVo, vidím daleko více zákazů než svobod. Je důležitější umožnit jediné firmě kvůli jejímu obchodnímu modelu vydávat zákazy, nebo zachovat ducha hackování a sdílení, díky kterému se daří svobodnému softwaru a Linuxu? Copak myslíš, že by byl Linux úspěšný, kdyby měly počítače zámky, které by lidem bránily, aby na nich Linux upravovali?
Takže místo abych TiVo považoval za "zlo", beru ho jako včelu dělnici, která sice nikdy nikomu své geny nepředá, ale stejně pomůže lidem, kteří ty geny předají: jádru (do jisté míry - ani ne kvůli samotným patchům, ale kvůli rozšíření obzorů v oblasti PVR) a projektům jako MythTV (opět ne kvůli patchům, ale protože lidem pomohl lépe chápat dané problémy).
Myslím, že RMS by měl akceptovat skutečnost, že většina kódu byla napsána, aniž by lidé souhlasili s jeho ideologií. A měl by přijmout _zodpovědnost_, kterou svým géniem nebo náhodou (vyberte si) získal, a pokusit se _pochopit_, jak ti lidé uvažují - místo aby se snažil prosadit vlastní plány.
-- Ingo Molnar
Dovolím si nesouhlasit. Přijetím _jeho_ licence jsi přijal i jeho postoj. Pokud se ti to nelíbí, vyber si jinou licenci (což samozřejmě můžeš).
GPLv2 neříká, že se máš stát otrokem RMS a ve všem jej následovat a se vším souhlasit. Fakt. Musel jsi číst nějakou jinou verzi (třeba nějaký počáteční nevydaný návrh?).
Co je tady, kruci? Konference linux-kernel nebo Nikajský koncil?
-- Al Viro
Skoro přesně před rokem, zatímco vývojáři diskutovali o změnách souborového systému ext3, napsal Andrew Morton:
Přesto je pravda, že linuxové souborové systémy začínají být trošku rozvrzané a blížíme se k okamžiku, kdy bychom mohli těžit z nového, který začne na zelené louce. Mohl by být založen třeba na reiser4 - nedíval se na něj někdo? Už tu leží pár let.
Reiser4 asi ještě bude nějakou dobu ležet bude. Ale to neznamená, že by nebyl zájem o vytváření zajímavých nových souborových systémů. V květnu jsme mluvili o LogFS, ale není to jediný nováček na scéně.
Asi nejzajímavější účastník je btrfs, který Chris Mason oznámil 12. června. Jde o úplně nový souborový systém určený pro standardní rotační ukládání s několika zajímavými funkcemi:
Rychlá kontrola souborového systému je pro btrfs důležitým designovým cílem. Data a metadata jsou uspořádána způsobem, který offline checkeru [kontrolnímu programu] umožňuje číst disk téměř sekvenčním způsobem. To by mělo proces výrazně urychlit; kontrola souborového systému obvykle znamená velké množství vyhledávacích operací. V plánu je i online kontrola, která však zatím nebyla implementována; jakmile bude fungovat, mohlo by se úplně zrušit kontrolování při připojování.
Tento souborový systém je zatím v rané fázi vývoje - nedoporučuje se pro data, která byste si chtěli ponechat. Zatím nebylo provedeno moc výkonnostních testů a je pravděpodobné, že ještě dojde k mnoha optimalizacím. Celý souborový systém je například v tuto chvíli chráněn jediným mutexem, což je řešení, které by si pravděpodobně na moderních systémech se 4096 procesory moc dobře nevedlo. Také je potřeba se postarat o několik detailů - třeba by neměl "oopsovat", když dojde místo, je potřeba přidat podporu přímého I/O, zápisu přes mmap(), rozšířených atributů atd. Ale btrfs se podařilo upoutat pozornost, takže pokud dostojí nadějím, které jsou do něj vkládány, mohli bychom v budoucnu používat btrfs systémy.
(Další informace na stránce projektu btrfs.)
Druhý nedávno představený souborový systém je NILFS, který je teď ve druhé verzi. NILFS (New Implementation of a Log-structured Filesystem) je souborový systém strukturovaný jako log - úložné médium je bráno jako kruhový buffer a nové bloky jsou vždy zapisovány na konec. Tyto souborové systémy obvykle dosahují dobrých výsledků v testech, které měří výkon při zápisu, protože všechny zápisy jsou prováděny na souvislé bloky; výkon při čtení už tak dobrý není. Souborové systémy strukturované jako log se často používají na flash zařízeních, protože přirozeně zajišťují rovnoměrné opotřebení. Vypadá to však, že NILFS není určen pro flash.
Místo toho klade NILFS důraz na snímky. Přístup, který využívá strukturu jako log, je specifickou formou copy-on-write, takže se nabízí vytváření snímků. Vývojáři NILFS mluví o vytváření "souvislých snímků", které lze použít pro záchranu při problémech způsobených uživatelem - typu "rm -r". NILFS je prý škálovatelný díky 64bitovým datovým strukturám, ale podpora architektury x86_64 je kupodivu na seznamu zatím nesplněných úkolů. Zatím také nepodporuje rozsahy.
(Další informace na nilfs.org.)
Obecně platí, že uživatelé Linuxu o jádře spíše nechtějí vědět. Pokud je všechno v pořádku, tak fungují připojená zařízení, běží programy a jádro to všechno potichu zařídí. Když se však vyskytne problém, bývá nutné pročítat zprávy, které jádro posílá. Tyto zprávy dávají smysl vývojářům, kteří je napsali, ale pro zbytek světa už tak zřejmé nebývají. Neal Stephenson ve svém příběhu Na počátku byla příkazová řádka říká, že jaderné zprávy jsou stejně "zlověstně nečitelné jako graffiti tagy". Pro vývojáře jádra je nejčastěji hodnota jaderné zprávy v tom, že může určit, která část kódu si stěžuje - a z toho lze odvodit samotný problém.
Pro běžné uživatele je však těžší jaderné zprávy takto používat - a ti, kteří nemluví anglicky, to mají ještě horší. Není tedy překvapivé, že se čas od času objeví diskuze na téma vylepšení zpráv.
Reformátoři zpráv mají většinou dva cíle:
Potíž je samozřejmě v tom, že přiřazení identifikátorů ke zprávám je pořádný kus práce. V jádře jsou desítky tisíc volání printk(); každému z nich je potřeba přiřadit identifikátor a změnit kód. S každou novou verzí jádra přibývají - ve velkých počtech - nové zprávy. Snadno si lze představit, jak rychle by vývojáře začalo otravovat přiřazování identifikátorů. Z těchto důvodů Linus dříve návrhy na vylepšení zpráv odmítal.
Ale je to stejně zpátky. Japonští uživatelé, kteří mají potíže s podporou Linuxu, navrhli nový přístup. Každá jaderná zpráva by měla přiřazeno jméno komponenty a číslo. Komponenta by byla určena definicí v souboru:
#define KMSG_COMPONENT "railgun"
Volání printk by pak byla upravena tak, aby obsahovala číslo zprávy:
printk(KMSG_ERR(100) "Railgun omylem vystřelila - pardón\n")
Výsledkem by byla zpráva, které by předcházel řetězec railgun.100:, což by umožnilo přeložení zprávy a také vyhledání v manuálu. Aby se zaručilo, že bude nějaká dokumentace opravdu k dispozici, vyžaduje návrh dokumentaci přímo ve zdrojovém kódu; asi takto:
/**
* message
* @100:
*
* Popis:
* Railgun omylem vystřelila, protože uživatel
* nespecifikoval žádnou akci.
*
* Uživatelská reakce:
* Obsluha by si měla dávat pozor, aby stála bokem.
*/
Skripty kerneldoc by byly aktualizovány, aby posbíraly všechny tyto zprávy a vyrobily z nich tisknutelnou příručku. Další nástroj by kontroloval zdrojové soubory a upozorňoval na zprávy, u kterých by chyběl popis.
Podobná schémata byla již v minulosti kritizována a totéž se stalo i tentokrát. Přidaná práce, která vyplývá z takového dokumentování zpráv, je pro některé vývojáře příliš; David Miller to vyjádřil trefně:
Řekl bych, že moje reakce na něco takového, pokud by se to do jádra dostalo, by byla asi taková, že bych přestal psát kód, který podává užitečné zprávy, protože muset ho ještě takto dokumentovat je příliš práce, takže by mi to ani nestálo za to.
Obtížné by bylo také aktualizování zpráv - kód se často mění, aniž by byly změněny i okolní komentáře; není důvod se domnívat, že by jaderné zprávy byly výjimkou.
Andrew Morton místo toho navrhl řešení, které by vývojáři mohli spíše akceptovat. Přidala by se nová podoba printk(), která by pracovala s ID zpráv (v zatím neurčeném formátu). ID by bylo vypsáno společně se zprávou, ale všechno ostatní - překlady, popisy, upřímné soustrasti atp. - by bylo v databázi mimo jádro.
Klíčové je, že by se od vývojářů neočekávala jakákoliv práce s touto databází - dokonce ani s jadernými zprávami. Místo toho by byl "tým pro jaderné zprávy", který by měl za úkol tyto informace udržovat. Čas od času by se někdo z týmu podíval na nový kód, přidal potřebná ID a poslal správci patch. Pokud by o to sami neměli zájem, nemuseli by se tohoto procesu vývojáři vůbec účastnit.
I tento návrh má své nedostatky; jedním z nich je to, jak by byl tým starající se o zprávy financován (nebo jinak motivován). Dopad by však mohl být tak malý, že by to komunita mohla přijmout. Jednoho dne si možná i uživatelé Linuxu budou muset na poličkách vyhradit místo na pořádné manuály o zprávách.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.