Jaderné noviny - 23. 4. 2008

13. 6. 2008 | Jirka Bourek | Jaderné noviny | 2937×

Citáty týdne: Keith Packard, Andrew Morton, Ingo Molnár. Otevírá se začleňovací okno 2.6.26. Výchozí 4k zásobníky? ELC: Andrew Morton a Deepak Saxena o práci s jadernou komunitou.

Obsah

• Citáty týdne: Keith Packard, Andrew Morton, Ingo Molnár
• Otevírá se začleňovací okno 2.6.26
• Výchozí 4k zásobníky?
• ELC: Andrew Morton a Deepak Saxena o práci s jadernou komunitou

Začleňovací okno pro 2.6.26 je otevřené, takže v současnosti není vydána žádná vývojová verze. V článku níže je shrnutí změn, které byly zatím do 2.6.26 začleněny.

Současná verze -mm stromu je 2.6.25-mm1. Nedávné změny v -mm zahrnují nějaké vylepšení přečti-zkopíruj-aktualizuj [read-copy-update] a kód podpory OLPC architektury, ale z větší části se -mm jenom připravuje na velký příliv patchů do hlavní řady. Andrewovy plány pro 2.6.26 vizte v dokumentu o začleňovacích plánech pro -mm.

Současné stabilní jádro je 2.6.25, vydané 16. dubna. Po téměř třech měsících vývoje a začlenění přes 12000 patchů od téměř 1200 vývojářů je toto jádro považováno za připravené k širšímu použití. Výrazné záležitosti této verze zahrnují ath5k (Atheros wireless) ovladač, spoustu práce na realtime včetně realtimového skupinového plánování, preemptivní RCU, podporu LatencyTop, mnoho nových vlastností souborového systému ext4, podporu pro protocol controller area network (CAN), další práci na síťovém jmenném prostoru, návrat systémového volání timerfd, patche mapy stránek (poskytuje lepší informace o používání paměti), bezpečnostní modul SMACK, lepší jadernou podporu pro grafické čipové sady od Intelu a ATI R500, řadič spotřeby paměti, podporu pro ACPI regulaci teploty, podporu architektury MN10300 a spoustu dalšího. Vizte stránku o 2.6.25 na KernelNewbies, kde najdete spoustu detailů, nebo kompletní changelog, kde najdete neuvěřitelné množství detailů.

18. dubna bylo vydáno 2.6.24.5 Obsahuje relativně dlouhý seznam oprav pro významné problémy 2.6.24.

Co se starších jader týče: 2.4.36.3 bylo vydáno 19.  dubna. Nic zajímavého, jenom jsem se rozhodl vydat čekající opravy. Ti, kdo už používají 2.4.36.2, nemají žádný zvláštní důvod k upgradu, pokud nemají problémy v oblastech, kde k opravám došlo.

Citáty týdne: Keith Packard, Andrew Morton, Ingo Molnár

V každém případě budeme dál využívat faktu, že mprotect je také rozbitý, abychom zprovoznili naše WC mapování (použitím mprotect PROT_NONE následovaným mprotect PROT_READ|PROT_WRITE, což způsobí, že bity CD a WT jsou vynulovány). V tomhle případě máme štěstí, že jsme našli chybu, kterou můžeme zneužít, aby nám poskytla požadované chování.

-- Keith Packard

Hezky vypadající kód - kgdb se opravdu hodně zlepšil. Jsem rád, že jsme ho konečně dostali dovnitř. Možná ho jednoho dne použiji zase.

-- Andrew Morton

/me si poctivě zaznamenává tuto žádost rozbít Andrewovy systémy ještě častěji ;-).

-- Ingo Molnár

Otevírá se začleňovací okno 2.6.26

Nablýskané nové jádro 2.6.25, které bylo vydáno 16. dubna, je teď dávnou minulostí; od té doby bylo do gitového repozitáře hlavní řady jádra začleněno kolem 3500 sad změn. Nejvýznamnější změny viditelné pro uživatele zahrnují:

• Nové ovladače pro
  • Korina (IDT rc32434) ethernetové MAC (Media Access Control),
  • SuperH MX-G a SH-MobileR2 CPU,
  • karty Solution Engine SH7721,
  • ARM YL9200,
  • Kwikbyte KB9260,
  • Olimex SAM9-L9260,
  • karty emQbit ECB_AT91,
  • procesory Digi ns921x,
  • šifrovací enginy Nias Digital SMX,
  • testovací desky AMCC PPC460EX,
  • karty Emerson KSI8560,
  • karty Wind River SBC8641D,
  • zařízení Rumblepad 2 force-feedback od Logitechu,
  • Renesas SH7760 I2C řadiče a
  • SuperH mobilní I2C řadiče.

• PCI subsystém nyní podporuje PCI Express správu napájení v aktivním stavu [Active State Power Management], který umožňuje významné šetření energií na odpovídajícím způsobem vybaveném hardwaru.

• Nový security= boot parametr, jenž umožňuje specifikovat, který bezpečnostní modul se má použít, pokud jich je k dispozici víc.

• Překlad síťových adres (NAT) je nyní podporován u protokolů SCTP, DCCP a UDP-Lite. Do DCCP bylo také přidáno sledování spojení [connection tracking].

• Síťový stack nyní umí vyjednat selektivní potvrzování a škálování okna, i když se používají syncookies.

• Byla začleněna další dlouhá série patchů pro síťové jmenné prostory, čímž se pokračuje v dlouhém procesu změnit veškerý síťovací kód tak, aby si byl vědom jmenných prostorů.

• Do vrstvy mac80211 byla přidána podpora pro mesh síťování. V současnosti je ale označena jako "rozbitá", dokud nebudou opraveny některé význačné problémy.

• Pro x86 architekturu jsou nyní výchozí 4k zásobníky. Tato změna je kontroverzní a než dojde k finálnímu vydání, mohla by být odstraněna.

• SELinux nyní podporuje "přípustné typy" [permissive types], které specifickým doménám umožňují běžet tak, jako by SELinux vůbec nebyl v systému přítomen.

• V realtimovém skupinovém plánovači bylo uděláno mnoho vylepšení, včetně víceúrovňových skupin, schopnosti míchat procesy a skupiny (a nechat je proti sobě soupeřit o procesorový čas), lepšího SMP vyvažování a dalších.

• Podpora pro spouštění binárních souborů pro SunOS a Solaris byla odstraněna; dlouho nebyla udržována a nefungovala dobře.

• Jádro má nyní podporu pro vázané připojení [bind mount] pouze pro čtení, které poskytuje read-only pohled na jinak zapisovatelný souborový systém. Zamýšlené využití této vlastnosti (jejíž implementace byla složitější, než by jeden čekal) je použití v kontejnerech a jiných situacích, kde by ani procesy běžící pod rootem neměly být schopné modifikovat určité souborové systémy.

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

• Do architektury x86 byla konečně přidána podpora pro interaktivní KGDB debugger. V adresáři Documentation je DocBook dokument, který poskytuje přehled o tom, jak tento nástroj použít.

• Pro architekturu x86 je také (opět - konečně) k dispozici tabulka atributů stránek (PAT [Page attribute table]). PAT umožňují jemnější kontrolu chování cachování paměti s větší flexibilitou, než měla MTRR. Více informací vizte v Documentation/x86/pat.txt.

• Byly přidány dvě nové funkce (inode_getsecid() a ipc_getsecid()), které podporují bezpečnostní moduly a kód auditu, poskytují obecný přístup k bezpečnostním ID spojeným s inody a IPC objekty. Mnoho zpětných volání [callbacků] LSM spojených se superbloky nyní bere jako parametr ukazatel na struct path místo na struct nameidata. Ve frameworku bezpečnostních modulů je také nová sada háčků, která poskytuje podporu pro obecný audit.

• Nyní nepoužívaná softwarová MAC vrstva ieee80211 byla odstraněna; všechny ovladače, které ji potřebovaly, byly konvertovány na mac80211. Také byl odstraněn síťový ovladač sk98lin (ve prospěch skge) a bcm43xx (nahrazen ovladači b43 a b43legacy).

• Byl začleněn patch obecných semaforů. Kód semaforů také má nové funkce down_killable() a down_timeout().

• Struktura ata_port_operations používaná libata ovladači nyní podporuje jednoduché dědění operací, čímž se zjednodušuje psaní ovladačů, které jsou s malými změnami "skoro stejné" jako existující kód.

• Nová funkce (ns_to_ktime()) konvertuje časovou hodnotu v nanosekundách na ktime_t.

• Poslední uživatelé struct class_device byli konvertováni, aby místo toho používali struct device. Jestliže všechno půjde dobře, struktura class_device bude odstraněna později v cyklu 2.6.26.

• Greg Kroah-Hartman již není správcem PCI subsystému, tuto odpovědnost za něj převzal Jesse Barnes.

• Kód seq_file nyní akceptuje návratovou hodnotu SEQ_SKIP ze zpětného volání show(); tato hodnota způsobí, že všechen nahromaděný výstup z tohoto volání bude zahozen.

Netřeba říkat, že tato vývojová řada je ještě mladá a v době psaní tohoto článku bude začleňovací okno trvat ještě týden. Do hlavní řady se tedy dostane mnohem více kódu, než se tvar 2.6.26 vyjasní.

Výchozí 4k zásobníky?

Jaderný zásobník je vcelku důležitý kousek paměti v každém linuxovém systému. Nepříjemné poškození jaderné paměti, které vznikne, když přeteče, je něco, čemu se chceme vyhnout za každou cenu. Zásobník je ale alokován pro každý proces a vlákno v systému, takže ti, kdo hledají způsob, jak zmenšit spotřebu paměti, se zaměřili na volbu 8k zásobník, která se ve výchozím nastavení používá na x86. Zásobník o velikosti 8 kB navíc vyžaduje dvě fyzicky souvislé stránky (alokace "prvního řádu"), což je požadavek, který může být na běžícím systému kvůli fragmentaci těžké uspokojit.

Linux má volitelnou podporu pro 4k zásobníky již téměř dva roky, Fedora a RHEL ji zapínají v jádrech, která distribuují, nicméně nedávný patch tuto volbu na x86 zapnul jako výchozí, což způsobilo pozdvižení. Andrew Morton to vidí jako vyhýbání se normálnímu procesu zasílání patchů:

Tenhle patch způsobí, že jádra budou padat.

Nemá žádný changelog, který by vysvětlil nebo ospravedlnil tuto změnu.

A z toho, co vím, nebyl zaslán do mailové konference a nebyl ani diskutován, ani přezkoumáván.

Není překvapení, že autor patche Ingo Molnár vidí věci trochu jinak:

Která jádra z hlavní řady padají a jak budou padat? Fedora i další distra mají povolené 4k zásobníky už roky. [...] Provedli jsme desítky tisíc bootovacích testů s povolenými všemi možnými ovladači a jadernými volbami a ještě jsme neviděli žádný pád, za který by mohly 4k zásobníky. Výchozí stav v jádře jednoduše následuje běžný výchozí stav v distrech. (Distra i uživatelé je mohou stále zakázat.)

Jak bylo popsáno ve starším článku na LWN, hlavní obavy z poskytování pouze 4k zásobníků jsou u komplikovaných konfigurací úložného prostoru (RAID apod.) a u lidí, kteří používají NDISwrapper. Zatímco druhý případ je přehlížen - protože se do jádra nahrávají proprietární ovladače pro Windows - ten první může vést k ošklivému selhání. Poškození dat se nepochybně zdá být možné, ale i kdyby ne, pád jádra není nic, s čím by se administrátor chtěl potýkat.

Arjan van de Ven shrnul současný stav a poznamenal, že NIDSwrapper ve skutečnosti potřebuje 12k zásobníky, takže 8k pouze snižují pravděpodobnost, že jádro zhavaruje. Zásobníky u ovladačů více ukládacích zařízení [multiple storage drivers] (síťové souborové systémy, device mapper, RAID, atd.) jsou větší problém:

Potřebujeme vědět, o které jde, a vyřešit to, protože dokonce i u x86-64 s 8k zásobníky se může objevit problém (jen protože rámce zásobníku jsou tam větší, i když ne zcela dvojnásobné).

Zastánci výchozích 4k zásobníků se zdají být výskytem námitek zmateni, protože v jádrech Red Hatu s nimi nebyly problémy. Andi Kleen ale poznamenává:

Jeden způsob, kterým to dělají, je označení některých částí jádra jako nepodporovaných. Nemyslím si, že v hlavní řadě tuhle možnost máme.

Souborový systém XFS, který v RHEL ani Fedoře není podporován, může potenciálně použít velký kus zásobníku. To vede některé jaderné vývojáře k obavám, že komplikovaná konfigurace, která XFS používá, konfigurace "nfs+xfs+md+scsi writeback", jak to podává Eric Sandeen, by mohla přetéci. Na omezení spotřeby zásobníku se pracuje, ale zjevně se jedná o problém, který byl vývojáři XFS pozorován. David Chinner odpovídá na otázku o přetečení zásobníku:

Na x86 je vídáváme dost pravidelně, takže víme, že když jde o jakýkoliv divný pád, první otázka je "Používáš 4k zásobníky?". Pro srovnání - nikdy jsem neslyšel o jediném přetečení zásobníku na x86_64...

Nastavení 4k zásobníků se zdá být předčasné. Je dobrý důvod věřit, že lidé používající XFS by se mohli dostat do problémů. Nicméně je tu ještě větší záležitost - ta, na kterou Morton upozornil ve své první zprávě a poté znovu zopakoval v diskuzi:

Mimo jiné - tenhle druh diskuze bychom měli vést předtím, než je patch začleněn, ne?

Úspory paměti mohou být významné, obzvlášť ve světě kapesních zařízení. Společně s eliminací alokací prvního řádu pokaždé, když se vytváří nový proces, je to dobrý důvod se dále propracovávat směrem k výchozím 4k zásobníkům. Během psaní tohoto článku zůstávají 4k zásobníky v Linusově stromě, ale to se může rychle změnit.

ELC: Andrew Morton a Deepak Saxena o práci s jadernou komunitou

Úvodní řeč Andrewa Mortona udala tón pro letošní Embedded Linux konference (ELC). Popisoval způsoby spolupráce společností vyrábějících embedded zařízení s jadernou komunitou, které by byly "vzájemně výhodné". Andrew poskytl důvody, proč z čistě ekonomického hlediska dává pro společnosti smysl dostat svůj kód do hlavní řady jádra. Také představil konkrétní návrhy, jak toho dosáhnout. Zdálo se, že tématem konference je "spolupráce s komunitou" a Andrewův projev nabídl skvělý příklad, jak a proč to dělat.

Organizátor konference Tim Bird označil tuto základní myšlenku za "hlavní událost" ELC s poznámkou, že Mortona na linux-kernel vždy považoval za dospělého v místnosti. Čtenáři této mailové konference mívají pocit, že Andrewů je víc kvůli tomu, co všechno dělá. Také poznamenal, že pro některé bylo překvapením, že Morton má zázemí co se týče Linuxu a embedded zařízení - ze své práce v Digeo.

Andrew věří, že vývoj pro embedded zařízení je na kernel.org nedostatečně reprezentován v porovnání se svým ekonomickým významem. To je způsobeno mnoha vlivy, v neposlední řadě například finančními omezeními, s jakými jsou embedded zařízení vyvíjena. Výjimečnými případy jsou výrobci desek a čipů, kteří mají velký zájem na tom, aby jejich hardware na Linuxu běhal dobře a oni mohli přilákat více zákazníků. Ale ani ti nepřispívají k vývoji jádra tolik, kolik by se mu líbilo.

Důsledkem tohoto nedostatečného zastoupení je riziko, že vývoj jádra se odkloní spíše k serverům a desktopům. Jaderný tým je již nyní obviňován ze serverocentričnosti a zčásti je to pravda, ale ne tolik, jak by si člověk myslel. Hackeři jádra se zajímají o desktopy i o embedded zařízení, ale bez zástupce výrobců embedded zařízení některé věci chybí.

Andrew by byl rád, kdyby existoval jeden "správce embedded zařízení" na plný úvazek. Tato osoba by sloužila jako zástupce výrobců a zajišťovala, že nebudou přehlíženi. Takový správce by mohl mít na vývoj pro embedded zařízení velký vliv.

Ne všechny příspěvky do jádra musí být kód, řekl. Potřebujeme slyšet o problémech, se kterými se komunita okolo embedded zařízení potýká, společně se seznamem věcí, které chybí. Potřebujeme, aby "zkušenější a problému znalí lidé" pomohli sestavit priority vlastností, o kterých se uvažuje. Andrew často na konferencích zjistí věci, o kterých nevěděl, věci, o kterých měl vědět mnohem dřív: To je špatně!

Andrew se snaží podnítit komunitu okolo embedded zařízení k větší interakci s jadernými vývojáři na linux-kernel. Řekl, že skvělý způsob, jak získat pozornost týmu, je přijít na mailovou konferenci a postarat se, aby tvůrci daného subsystému vypadali špatně - například pomocí nepříznivých srovnání s jinými systémy nebo se staršími jádry. Obzvlášť pokud jsou podpořena čísly, si jich někdo rychle všimne. Řekl, že ten, která dělá nejvíc hluku, přiláká nejvíce pozornosti.

Jednou ze situací, kde vidí největší problém, je zvyk "hromadění patchů" - držení změn jádra jako patchů a jejich nezasílání do upstreamu jaderným vývojářům. Doufejme, že je to jenom kvůli nedostatku zdrojů, ale Andrew slyšel, že někteří to dělají, aby získali konkurenční výhodu. O tom prohlásil, že je to jednoduše špatné a firmy mají morální, pokud ne rovnou zákonnou povinnost tyto patche zaslat.

Pro začlenění kódu do upstreamu je mnoho dobrých důvodů, které Andrew nastínil. Kód bude lepší, protože bude prohlédnut jadernými vývojáři; jakmile je začlenění dokončeno, náklady na údržbu klesají někam k nule. Také se pokusil lákat na konkurenční výhodu tím, že komu se podaří nechat kód začlenit, vyhrál - konkurenční návrhy se dovnitř nedostanou. Ten, kdo první začlení nějakou vlastnosti, si věci zjednoduší a konkurenci zesložití.

Začleňování kódu do upstreamu má také své nevýhody. Většina z nich pramení z toho, že kód není vydán zavčasu, aby mohl být revidován. Jaderní vývojáři mohou žádat významné změny v kódu, obzvlášť v oblasti rozhraní k uživatelskému prostoru. Pokud už má firma spoustu kódu, který novou vlastnost a/nebo rozhraní využívá, může to být velmi nepříjemné; sorry, pro tohle neexistuje žádná oprava kromě vydání kódu včas.

Další nevýhodou, na kterou mohou firmy narazit, je začlenění konkurence do procesu. Andrew a další jaderní vývojáři se pokusí najít další, kdo mohou mít na nové vlastnosti zájem, a přibrat je do vývojového procesu, aby byly do úvahy vzaty potřeby všech. Tohle může "vítězství" - začlenění vaší vlastnosti - otupit. Někteří mají také obavy, že konkurence se dostane ke kódu, jakmile je zaslán; "smůla", řekl Andrew, všechno v jádře je GPL.

Andrew nabídl konkrétní rady pro výběr verze jádra, kterou použít pro projekt embedded zařízení. Pro taková zařízení není 2.6.24 o moc lepší než 2.4.18, ale má jednu důležitou vlastnost: jaderný tým se bude zajímat o chyby v současném jádře. Navrhl začít současným jádrem, jeho upgradováním během vývojového procesu a zmražením až ve chvíli, kdy přijde čas začít produkt dodávat.

Také navrhl, aby firma vytvořila vnitřní jaderný tým s jedním nebo dvěma lidmi, kteří budou sloužit jako rozhraní k linux-kernel. Díky tomu bude v konferenci snazší rozpoznat jména, což se vrátí v podobě větší pozornosti k zaslaným patchům. Postupem času a revizemi cizího kódu získají lidé z tohoto rozhraní "body za snaživost", které jim umožní žádat o laskavost a nechat revidovat svůj kód nebo ulehčí cestu k začlenění.

Vypadá to, že vývojáři na kernel.org poskytují podporu zdarma, obecně velmi dobrou podporu, řekl Andrew, ale úplně zdarma není. Vývojáři jádra ji poskytují jako "vzájemně výhodnou transakci"; nedělají to, aby vaše firma vydělala víc peněz, dělají to, aby bylo jádro lepší. Toho je Andrew rozhodně velkou součástí, protože nabízí lidem, aby mu napsali e-mail, obzvlášť jestli pět minut mého času může ušetřit měsíce vašeho.

Rozhodnutí, kdy začlenit novou vlastnost, je pro některé obtížně pochopitelné. Mnoho lidí považuje Linux za diktátorský systém, což je nesprávné, místo toho je to demokracie, kde se nevolí. Rozhodnutí o začlenění má model "právní normy", kde vývojáři jádra hrají roli soudců. Bohužel psaných pravidel je málo.

Mezi faktory, které ovlivňují rozhodnutí o dané vlastnosti, patří udržovatelnost, jestli bude existovat tým správců a obecná užitečnost dané vlastnosti. V závislosti na velikosti dané vlastnosti může být trvalý tým správců rozhodujícím faktorem. Pro ovladače není tak podstatný, ale například nová architektura potřebuje tým správců, což mohou dělat jenom lidé, kteří mají znalosti o hardwaru a přístup k němu.

Jaderný vývojář MontaVista Deepak Saxena měl později během konference prezentaci nazvanou "Správné postupy v komunitě: sociální a technické rady", která zrcadlila několik bodů té Andrewovy. Ukázal pár příkladů výrobců hardwaru a jejich špatných rozhodnutí, která byla odstřelena vývojáři jádra, většinou protože "nepublikovali brzo a nepublikovali často." Přístup je to Linux, je to open source, můžu dělat, co se mi zachce, je pravdivý, ale v komunitě to daleko nedotáhnete.

Deepak si velmi váží výhod práce se systémem: jestliže je váš konkurent v komunitě aktivní, získává výhodu, kterou vy nemáte. Stejně jako Andrew věří, že někteří členové vývojového týmu by se měli začlenit do aktivit na kernel.org. Komunita rozšiřuje váš tým, váš tým rozšiřuje komunitu.

Také poskytl specifické rady výrobcům hardwaru: vyhněte se abstrakčním vrstvám, uznejte, že váš hardware není unikátní, a přemýšlejte dál, než je implementace referenční desky. Pokud zobecníte váš kód tak, aby ho mohli využít ostatní, bude mnohem akceptovatelnější. Podobně pomohou rozhovory s vývojáři, kteří jsou zodpovědní za subsystém, kterého se dotýkáte. Abstrakční vrstvy mohou být užitečné pro výrobce hardwaru, kteří se snaží podporovat více operačních systémů, ale jaderným vývojářům se kvůli nim ztíží pochopení a správa kódu. Lidi z kernel.org nemají zájem hledat a opravovat chyby v abstrakční vrstvě.

Také upozornil na další výhody začlenění kódu. Jakmile je v jádře, firemní tým se nemusí dále starat o to, aby drželi tempo s jádrem a aktualizovali patche podle nejnovějších změn. Stále bude potřebná údržba kódu, ale běžné změny zvládnou lidé z kernel.org. Další výhoda kódu začleněného v jádře je to, bude vylepšován různými nástroji pro automatické vyhledávání chyb, například pomocí lockdep.

Je zjevné, že vývojáři jádra se hodně snaží nejen o to získat kód od tvůrců embedded zařízení, ale také část jejich znalostí. Existují různé snahy o přizvání dalších lidí do vývojového procesu Linuxu; tyto dvě přednášky k nim jednoznačně patří. Když se dá jasně najevo, že obě strany mohou získat, doufají, že se tato argumentace dostane od techniků k managementu, což povede k lepšímu jádru pro všechny.

       

Komentáře

[alpha]

Při čtení té části o začleňování do jádra jsem si tak nějak vzpomněl na Reiser4, zvlášť v odstavci, ve kterém se píše o diktatuře.

[zde]

> How many are we up to now?
> 
> akpm:/usr/src/linux-2.6.25> grep -ri '"0123456789abcdef"' . | wc -l
> 40
> 
> lol.

[Martin Doucha]

Proboha to /me v citátu Ingo Molnára se nepřekládá! To je IRC příkaz.

[trekker.dk]

Pokud víš s určitostí, že to /me bylo myšleno jako IRC příkaz, pak máš pravdu...

[Martin Doucha]

/me duly notes...

Co jiného by to asi mohlo být, když je to sloveso ve 3. osobě?

[Luboš Doležel (Doli)]

Je to tam.

[Ondrej 'SanTiago' Zajicek]

Hmm, lide z openwrt maji zajimavy postup mergovani do upstreamu. Nejdriv zaclenili ethernet a ATA driver pro RB 532, ale podpora pro samotnou platformu chybi.

[Grunt]

Oni to cpou do upstreamu? No LOL zas.

[Ondrej 'SanTiago' Zajicek]

Proc 'LOL'? Ja jsem vdecny za to, ze ty patche posilaji do upstreamu, jen me prekvapilo poradi.

[Grunt]

Mě zas překvapilo kdo je tam posílá. Mám pocit, že se kvůli tomu i strhl flame na fóru RBček(a zrovna se do nich pouštěl někdo z OpenWRT).