Jaderné noviny – 1. 3. 2012: K čemu jsou řídící skupiny a co s nimi

12. 3. 2012 | Luboš Doležel | Jaderné noviny | 3533×

Aktuální verze jádra: 3.3-rc5. Citáty týdne: Rusty Russell, Ian Jackson, Greg Kroah-Hartman, Ingo Molnar. very_unlikely(), které se moc nelíbilo. Opravování řídících skupin.

Obsah

• Aktuální verze jádra: 3.3-rc5
• Citáty týdne: Rusty Russell, Ian Jackson, Greg Kroah-Hartman, Ingo Molnar
• very_unlikely(), které se moc nelíbilo
• Opravování řídících skupin

Aktuální verze jádra: 3.3-rc5

Aktuální vývojová verze jádra je 3.3-rc5 vydaná 25. února. Vida, tenhle týden bez zpoždění. A ani se neděje nic divného. Možná se to konečně uklidňuje. Do tohoto vydání šlo 164 neslučovacích změn; krátký seznam změn je jako obvykle v oznámení.

Stabilní aktualizace: verze 3.2.8 vyšla 27. února. Toto je „zajímavá“ aktualizace, a to v tom, že je tu opravována „jen“ jediná chyba, jde o ošetření problému s plovoucími čísly na nových procesorech x86 v 32bitovém režimu. Ale opravovány jsou v této oblasti i problémy na x86-64, takže upgrade se doporučuje všem uživatelům. Pokud někdo narazíte na problémy, tak nám dejte hned vědět.

Aktualizace 3.0.23 a 3.2.9 vyšly 29. února; obě obsahují něco přes 70 důležitých oprav.

Citáty týdne: Rusty Russell, Ian Jackson, Greg Kroah-Hartman, Ingo Molnar

Ve starých dobách jsme snadno mohli odhalit kód, který potřebuje audit, podle stylu psaní kódu (nebo spíše chybějícího stylu). Ale pak někdo rozhodl, že nejdůležitější vlastností dobrého kódu je způsob používání bílých znaků. A napsal se na to nástroj.

Nějakou dobu bylo pro nás, správce, těžké určovat, kterými patchi se máme zabývat! Bojovníci postavení proti bílým znakům pak naštěstí navrátili původní stav: teď můžeme začátečníky odhalit podle toho, že dají na checkpatch.pl.

-- Rusty Russell

Projekt linuxového jádra má závažné a přetrvávající strukturální problémy a myslím si, že je pro nás jako pro projekt [Debian] důležité nechat si zadní vrátka.

-- Ian Jackson

UIO poskytuje framework, který doopravdy funguje (na rozdíl od toho, o co se snažily všechny ty výzkumné práce) a je používán na skutečných systémech (roboti svařující laserem!) každý den, vyrábějí věci, které používáte a jste na nich závislí.

Tím, že odstraníte UIO, riskujete, že ty roboty naštvete, je to na vás, ale já s jistotou vím, že to neudělám...

-- Greg Kroah-Hartman

Zalamování řádků po 80 znacích téměř nikdy není známkou pokulhávající hardwarové výbavy, ale spíše symptomem nedostatečného uvažování.

-- Ingo Molnar

very_unlikely(), které se moc nelíbilo

Nástroj, který byl dříve znám jako návěští pro skoky [jump labels], je navrhnut pro minimalizaci režie spojené s výjimečně užívanými funkcemi v jádře. Klasickým příkladem jsou body sledování [tracepoints], které jsou po většinu času vypnuté. V ideálním stavu by režie zakázaného bodu sledování byla nulová, nebo by to tomu bylo velice blízko. Návěští pro skoky (nyní „statické klíče“) používají úpravy kódu za běhu, aby z kódu kompletně odstranily nepoužívané funkce, dokud je někdo nezapne.

Za podpory Inga Molnara nedávno Jason Baron zaslal sadu patchů, která upravuje mechanismus návěští pro skoky tak, že vypadají následovně:

if (very_unlikely(&jump_label_key)) {
	/* Zde má místo výjimečně používaný kód */
}

Řada lidí si stěžovala, že very_unlikely() vypadá jen jako posílená obdoba makra unlikely(), které funguje poněkud odlišně. Ingo odpověděl, že podoba není náhodná a dává smysl, ale moc lidí nepřesvědčil. Po chvíli dalšího dohadování to Ingo vzdal a přestal název very_unlikely() protlačovat.

Namísto toho máme zase další podobu návěští pro skoky, popis najdete v tomto dokumentu. Návěští pro skoky statický klíč je definován jako jeden z těchto řádků:

struct static_key key = STATIC_KEY_INIT_FALSE;
struct static_key key = STATIC_KEY_INIT_TRUE;

Počáteční hodnota by měla odpovídat nastavení pro běžné užití – tedy té rychlejší možnosti. Používání statických klíčů vypadá takto:

if (static_key_false(&key)) {
	/* Zde se nachází kód pro nepravděpodobné situace */
}

Je třeba věnovat pozornost tomu, že static_key_false() lze používat pouze s klíčem inicializovaným pomocí STATIC_KEY_INIT_FALSE; u klíčů, které jsou ve výchozím stavu nastaveny na true, se musí používat static_key_true. Pro nastavení klíče na true jej stačí předat do static_key_slow_inc(); odstranění reference na klíč (a tedy pravděpodobně i nastavení na false) se dělá pomocí static_key_slow_dec().

Tato podoba změny už nebyla tak kontroverzní a dá se tedy odhadovat, že se probojuje do začleňovacího okna verze 3.4. Poté se dá očekávat, že se tento mechanismus nebude po alespoň jeden nebo dva vývojové cykly přepracovávat.

Opravování řídících skupin

Řídící skupiny [control groups] jsou jednou z funkcí, které jaderní vývojáři mají v oblibě nenávidět. Není těžké dohledat případy, kdy si na ně vývojáři stěžují a dokonce vyhrožují, že je jedné temné noci, až se nikdo nebude dívat, zlikvidují. Je ale méně obvyklé být svědkem diskuzí kolem konkrétních aspektů řídících skupin, které se vývojářům nelíbí, resp. jak by se to mohlo zlepšit. Nedávná diskuze na linux-kernel byla ale trochu výjimkou.

Mechanismus řídících skupin je zjednodušeně řečeno způsob, jakým může administrátor systému rozdělovat procesy do jedné nebo více hierarchických skupin. Hierarchií může existovat vícero a jeden proces je možné umístit do několika z nich. S řídícími skupinami souvisí koncept „řadičů“ [controllers], které konkrétní hierarchii řídících skupin nastavují určitá pravidla. Řadič skupinového plánovače [group scheduling controller] umožňuje řídícím skupinám přetahovat se mezi sebou o čas procesoru, konkrétně tedy omezovat to, jak hodně může jedna skupina procesů upírat procesorový čas jiné. Řadič paměti omezuje to, kolik paměti a swapu může spotřebovávat určitá skupina. Řadič síťové priority, který byl začleněn do verze 3.3, umožňuje administrátorovi dávat skupinám lepší nebo horší přístup k síťovým rozhraním. A tak dále.

Diskuzi zahájil Tejun Heo, a to dlouhou zprávou, ve které shrnul své stížnosti na mechanismus řídících skupin a jak si myslí, že by bylo možné to napravit. Podle Tejuna bylo chybou umožnit existenci vícero hierarchií procesů. Myšlenkou vícero hierarchií bylo umožnit nastavovat různá pravidla podle různých kritérií. Dokumentace k řídícím skupinám uvádí příklad se dvěma odlišnými hierarchiemi, které by se mohly objevit na univerzitním systému:

• Jedna hierarchie kategorizuje procesy na základě role jejich vlastníka; mohla by existovat skupina pro studenty, další pro fakultu a další pro správce. Dostupný čas procesoru by pak byl přidělován mezi různé typy uživatelů na základě systémových pravidel, profesoři by byli do určité míry izolováni od aktivit studentů, ale na správce by samozřejmě zbylo nejvíc.
• Druhá hierarchie je založená na tom, jaký program je v daném procesu spouštěn. Webové prohlížeče by mohly jít do jedné skupiny, BitTorrent klienti řekněme zase do druhé. Dostupná šířka pásma by byla přidělována podle toho, jak by ji administrátor dané třídě aplikací nastavil.

Na první pohled poskytují různé hierarchie administrátorům užitečnou ohebnost pro to, aby mohli nastavovat rozličná pravidla. V realitě nicméně komplikují kód a vytvářejí zajímavé problémy. Jak Tejun poukazuje, řadiče mohou být přiřazeny jen k jedné hierarchii. U řadičů, které nějakým způsobem řídí přidělování prostředků, toho omezení dává trochu smysl; jinak by se procesy mohly stát předmětem protichůdných pravidel, jakmile by se dostaly do několika hierarchií. Jenže pak tu jsou řadiče, které mají jiný význam; řadič „freezer“ (mrazák) jednoduše zastavuje procesy, které najde v dané řídící skupině, což umožňuje vytvoření checkpointu nebo další operace. Neexistuje žádný důvod, proč by tato funkce nemohla být dostupná v libovolné hierarchii, jenže pokud by to bylo možné, značně by to zkomplikovalo implementaci řídících skupin.

Největší stížností je ale to, že jen málo vývojářů považuje tuto funkci za skutečně užitečnou na reálných systémech. Není jasné, zda se to doopravdy používá. Tejun navrhuje postupné vyřazení této funkce, pravděpodobně po nějakém dosti dlouhém přechodovém období. Nakonec by podle Tejunových slov mohla hierarchie řídících skupin v podobě nezávislé struktury zmizet a řídící skupiny by mohly být postaveny nad existující hierarchií procesů. Někteří s tím nesouhlasí, Peter Zijlstra řekl: Raději budu přiřazovat procesy do řídících skupin, které jsem stvořil, než abych jejich podobu musel kopírovat v hierarchii procesů. Takže možnost mít hierarchii řídících skupin, která se liší od hierarchii procesů, asi nezmizí, a to i kdyby se podpora vícero hierarchií časem stala zastaralou.

S tím souvisí jiný problém, na který Tejun upozornil, a to že různé řadiče s hierarchií řídících skupin zacházejí odlišně. Zejména jde o to, že několik řadičů prošlo určitou evolucí, kdy počáteční implementace nerozpoznávala vnořené řídící skupiny a místo toho hierarchii zploštila. Pozdější aktualizace plnou podporu hierarchií případně doplnily. Takový řadič blokového I/O se plné podpory dočkal až minulý rok, ostatní se toho třeba ještě ani nedočkaly. Aby se systém choval správně, tak podle Tejuna musí všechny řadiče vnímat hierarchii stejně.

Obecně byly řadiče za poslední roky zdrojem spousty zlé krve. Obvykle jsou implementovány tak, aby byl jejich vliv na systém, kde nejsou používány, co nejmenší – a to z dobrého důvodu – jenže to má za následek dosti slabou integraci. Řadič paměti například vytvářel svůj vlastní sledovací systém stínových stránek, což vedlo k nepořádku a značnému využívání prostředků, přičemž toto bylo napraveno až ve verzi 3.3. Řadič hugetlb není integrován s řadičem paměti a ve verzi 3.3 máme zase dva nezávislé řadiče sítě. A jak se množství malých řadičů zvyšuje (dokonce byl navržen řadič pro polevování časovačů), může v tom být ještě větší nepořádek.

K nápravě řadičů je hlavně zapotřebí, aby někdo začal pracovat jako hlavní správce řídících skupin. Tuto funkci mají podle souboru MAINTAINERS Teun a Li Zefan, ale pravdou je, že nikdo nevykonává dozor za celý systém, takže se změny dějí v rámci různých subsystémů. Je to ale administrativní problém; mělo by proto být možné to vyřešit.

Náprava řídících skupin bude obtížnější, zejména pak pokud se dostane na odstranění funkce vícero hierarchií. To je pochopitelně změnou ABI pro uživatelský prostor; než by k tomu došlo, tak by mohly uběhnout roky, pokud by to vůbec bylo možné. Tejun navrhuje nahnat lidi k tomu, aby používali jednotnou hierarchii spolu s tím, že by se u všech řadičů správně ošetřilo vnořování. Od určité verze by jádro začalo varovat, jakmile by se používalo vícero hierarchií. Nakonec, pokud by si nikdo nestěžoval, by funkce mohla konečně zmizet.

Pokud se zjistí, že vícero hierarchií nikdo nepoužívá, tak by se to pochopitelně mohlo stát rychleji. Nikdo se za tuto funkci nepostavil, ale samozřejmě šlo o debatu mezi vývojáři, nikoliv mezi uživateli. Pokud je tu někdo, kdo tuto funkci používá, tak by se měl ozvat. Informace o tom, jak funkci používají, by mohly ovlivnit budoucí podobu řídících skupin; pokud nikdo s takovými informacemi nepřijde, tak by tato budoucnost mohla býti dosti odlišná.

.        

Komentáře

[Honz]

To vyjádření Debianu o problémech a zadních vrátkách zní dost silně... Opravdu je to tak špatné? A co ti roboti s lasery?

[Heron]

Tak vždy je dobré si nechat zadní vrátka. Když se Linuxu něco stane, tak Debian pojede dál na kFreeBSD. Nebo třeba na Hurdu, až bude .

[avzgag]

ty jo, anebo forknout linuxovy kernel.

[Lol Phirae]

Když se Linuxu něco stane, tak Debian pojede dál na kFreeBSD.

To by bylo pro uživatele opravdu "terno", viz úžasná "podpora" WiFi, například.

[Heron]

Jasně, taky by tam nebylo KVM (což je důvod proč mám Linux), ale zase by tam bylo ZFS. Tak je to vždy.

[avzgag]

ZFS by mohlo bys kFreeBDS, ale ne s GNU/Hurd

[kai.101]

Co je špatného na zalamování po 80ti znacích?

[Salamek]

Co je dobreho na zalamovani ?

[samo]

Napriklad to, ze kratky riadok je citatelnejsi? Schvalne si skus spocitat pocet znakov na riadku lubovolnej knihy. Vo vacsine pripadov to tych 80 velmi nepresiahne. Clovek lahsie udrzi zrak na kratsom riadku ako na dlhom.

[ukos]

Jenže natvrdo zalamovaný kód není čitelnější - je to naopak docela zmatečné. Pokud chci mít zalomený text kvůli čitelnosti, tak si linewrap nastavím v editoru. Odlamovat řádky v kódu je hnus.

[Sten]

+1

Můj preferovaný styl je zalamovat kontextově, nikoliv na 80. sloupci. Třeba parametry v deklaracích a definicích funkcí zalamuju pod sebe, protože je pak snadné se orientovat v tom, jaké a kolik parametrů tam vlastně je. Stejně tak inicializátory proměnných nebo definice dědičností. Jednotlivé příkazy pak nezalamuju staticky, ale jenom pokud je to potřeba kvůli čitelnosti vnořených volání. Na druhou stranu kombinuju tabulátory a mezery (tabulátor určuje blok, mezery zarovnávají v rámci jednoho bloku např. ty parametry pod sebe), protože je mi jasné, že někdo chce tabulátory na osmi znacích, jiný na dvou, a já používám čtyři, takže i když změníte délku tabulátoru, věci zarovnané pod sebou zůstanou pod sebou.

[Salamek]

Presne tak jsem to myslel, od toho je okraj v editoru, zalomene radky v kodu si zaslouzi useknuti obou rukou.

[tom]

Vite treba o tom, ze u spousty prumyslovych aplikaci se musi kod vytisknout a archivovat? Pokud to nezalamete rucne, tak si vytisknete peknej hnus.

[vvv]

A to se vubec neda udelat tesne pred tiskem, ze?

[100% Lenin]

Soudruhu, proč?

[radix]

Jo. 80 je ale proste malo (obzvlaste treba v Jave), videl bych to na 120.

[ivan]

Vzhledem k tomu, ze se v minulych JN nekdo zminoval, ze v kernelu je pres 10 promennych jejichz jmeno ma pres 100 znaku tak se to bude dost blbe zalamovat na 80. Preci jenom 20. stoleti uz je par let za nami a dnesni HW o kus dal.

[Milan Jurik]

Dvě poznámky:

1) proměnná se jménem přes 100 znaků je hodně podezřelá a při větším nasazení si koleduje o průšvih (jméno musí být hodně dobře strukturováno, protože jinak nemalá část lidí si ho nejen nebude schopna správně zapamatovat, ale i přímo ho nesnášet)

2) dnešní HW je o kus dál sice, ale lidé jsou stále stejní. A ne nadarmo 80 znaků při obvyklé velikosti znaku je dost výrazně prověřená zlatá střední cesta pro týmovou spolupráci více jedinců na sdíleném kódu.

[Luboš Doležel (Doli)]

To není zlatá střední cesta, to je spíš takové zoufalé minimum. Je to jako předpokládat v dnešní době rozlišení 640x480.

[Michal Kubeček]

Není to zoufalé minimum. Já mám třeba většinu terminálů nastavených na šířku 80 znaků i na monitoru s rozlišením 1600x1200 a až jednou budu mít 2560x1600, budu je tak mít také (jen asi vedle sebe budou tři místo dvou). Stejně tak kate. Jenom když dělám něco speciálního, na co potřebuji větší šířku, roztáhnu se terminál nebo editor přes celou obrazovku.

[Bilbo]

V závislosti na prostředí, IDE ve kterém pracuju a na velikosti monitoru mám pro práci tak 100 až 180 znaků na řádek.

Ovšem ve chvíli kdy je potřeba dělat třeba code review a zobrazit něco ve dvou sloupcích vedle sebe (starý a nový kód) tak pak člověk ocení, že existuje nějaký limit (někdy 80, ale někdy 100 nebo 120 dle firmy a programovacího jazyku) na maximální délku řádku.

Jedna věc je prostor na monitoru (ten se s technickým vývojem zlepšuje), druhá je schopnost člověka soustředit se a pohledem pochopit nějak velký kus kódu. Moc dlouhé řádky je pak už hůře čtou (při čtení je nutno těkat očima pořád zprava doleva) a jelikož je zde omezením lidský mozek, tak tam bych velký vývoj nečekal.

[Milan Jurik]

Bingo

[Milan Jurik]

Sorry, ale to není o rozlišení, ale o schopnosti lidí pohledem bez výrazného šibování s očima, nedejbože s hlavou, obsáhnout viditelnou plochu a vnímat její obsah. A vzhledem k tomu, že valná část programátorů jsou dnes muži, kteří zrovna neoplývají periferním viděním, tak s tím nic bez bioinženýrství nenaděláte.

Proto jsou dnešní širokoúhlé monitory třeba pro mne totálně nevhodné na práci v terminálu nebo jednoduchých textových editorech.

[Michal Kubeček]

Někdo to řeší otočením na výšku, někdo tím, že má terminálů víc vedle sebe.

[Milan Jurik]

Souhlas, že otočení na výšku může pomoci (ale nesmí se to přehánět, nebo se člověk ukývá). Případně volný prostor zkonzumují různé toolboxy grafických klikátek. Terminály vedle sebe pro změnu vyřeší jen práci v terminálech.

Viděl jsem, jak to někdo užívá jako dva monitory v jednom, jenže pak řeší, že www browser má bílé pozadí, kdežto terminál má černý a oči se můžou "zcvoknout". Pak to řeší úpravou toho browseru atd.

Prostě, workaroundy jsou a každému sedí něco jiného. Ale stále to nic nemění na tom, že to v mnohých případech není ideální konfigurace a rozhodně to není dobrý argument pro dlouhé řádky.

[Luboš Doležel (Doli)]

Jak už tu někdo psal, nejde jen o to mít tolik obsahu na jednom řádku, ale spíš nemít kvůli whitespace jeden řádek rozdělený na více řádků.

Tak zblízka, abych potřeboval periferní vidění, do monitoru opravdu nekoukám. Co je to za blábol?

Ale nejpodstatnější je NENUTIT ostatním těch 80 znaků a řešit to na úrovni zobrazovače, nikoliv na úrovni souboru.

[Milan Jurik]

Jenže tu nejde o whitespace na jednom řádku, ale o celý kontext zdrojáku na obrazovce. Nevím, jak často procházíš cizí kód a opravuješ ho, já to dělám dost dlouho denně.

Ano, ty to periférně možná nepotřebuješ, ale třeba já ano. Prostě minimalizovat pohyb při sledování toku kódu.

A to nenutit - právě naopak. Pokud je to týmová práce na 10 let, tak nutit, nutit do úplně stejné štábní kultury. Protože když si k ní přivykneš, pomáhá to urychlovat právě review. Aspoň tohle mi říká moje osobní zkušenost. A protože každý užívá jiný "zobrazovač", tak nechat volné pole působnosti vede k chaosu (ne každý má to štěstí, že pracuje s kódem v neustále tom samém prostředí té konkrektní pracovní stanice, kterou má vyladěnu).

Také nadávám, že odsazení v kombinaci s 80 znaky dělá uzounké nudle. Ale v naprosté většině případů to jen poukazuje na naprosto špatně strukturovaný kód.

[Josef Kufner]

Já používám 120 znaků místo 80 a na nudle netrpím. Myslím, že v současné době je už celkem těžké narazit na tak malý displej, který by 120 znaků dlouhý řádek nepojmul. Při tabu na 8 znaků a dvou tabech všude pro odsazení třídy a metody to je tak akorát.

[Michal Kubeček]

Myslím, že v současné době je už celkem těžké narazit na tak malý displej, který by 120 znaků dlouhý řádek nepojmul.

Ne všichni automaticky roztahují všechna okna na celou šířku obrazovky.

[Josef Kufner]

Hm, mě všechny ty panýlky a toolbárky děsně ruší, takže když něco píšu, tak mám jen editor a nic jinýho. Ale i na malém 14" displeji 1024x768 je 120 znaků zhruba 2/3 šířky, takže na nějaký ten panýlek je ještě místo (12px Terminus, cca 5mm výška řádku).

[Michal Kubeček]

V konsoli žádné panýlky a toolbary po stranách nemám a i tak se se dvěma 80znakovými terminály tak tak vejdu na monitor s rozlišením 1280x1024 (pokud má být písmo ještě rozumně čitelné). Pro některé činnosti jsou dva terminály vedle sebe de facto nutností (třeba v jednom crash s disassemblovanou funkcí, ve druhém její zdroják (a to by to ještě chtělo mít ve třetím backtrace)).

[vencas]

Zalamování je záležitost editoru a hloupý editor se zalámaným textem neudělá. Zdrojový kód je text a každé otevření na obrazovce odpovídá novému výtisku knihy: je jinak široká, jinak vysoká atd. Text by měl být napsán tak, aby ho editor mohl čitelně zalomit, ne v sobě mít zlomy natvrdo.

[radix]

Pokud by IDE dokazovaly rozumne zalamovat, tak by to nebyl problem. Co jsem zatim videl, tak ti to proste zalomi mezi slovy a vylije na zacatek dalsiho radku. Toto neni citelne.

Je to sice zvlastni, ale nektere IDE (Eclipse) vubec zalamovat text neumi.

[CZTomi]

?? Nezalamuje Eclipse, ale parametrech v CodeStyle si můžu nastavit svých 130 znaků a postará se o to až profil podle konkrétního jazyka....

[stativ]

Až na to, že to je 80 znaků textu, ne zanořený kód, ve kterém je prvních 48 znaků odsazení.

[Michal Kubeček]

Což je do značné míry problém nešťastného odsazování osmiznakovým tabulátorem.

[Heron]

Někde Linus vysvětloval, že je to tak schválně jako zabránění příliš mnoha vnoření. Tedy není problém v délce řádku, ani v 8 znakovém tab., ale v kódu.

[Michal Kubeček]

No, idea taková asi byla. Ale nemůžu se ubránit dojmu, že se to moc nepovedlo…

[pavlix]

Až na to, že to je 80 znaků textu, ne zanořený kód, ve kterém je prvních 48 znaků odsazení.

Jo... 48 znaků odsazení naznačuje nešťastně mnoho vnoření, nešťastně zvolenou šířku odsazení, či obojí dohromady. Vždyť je to 6*8, 8*6, 12*4 nebo nedej bože 24*2. Používání osmiznakového tabu na odsazení je zvěrstvo.

Škoda, že se něco takového kdy začalo používat, 12 a více odsazení už mi taky přijde jako zvěrstvo, pokud nejde o výpočty na hodně hluboko strukturovaných polích, ale tam mi zase přijde rozumnější kašlat na pravidla vymyšlená pro normální kód.

[Ash]

Spíš co je špatného na zbytečném zalamování po 80ti znacích :)

[Marián Kyral]

teď můžeme začátečníky odhalit podle toho, že dávají na checkpatch.pl

Tohle mi nějak nedává smysl. Dle originálu bych řekl, že tam bude něco jako "dávají pozor" nebo že jej vůbec spustí.

[Michal Kubeček]

Co si tak vzpomínám na tu diskusi, šlo spíš o to, že vystrašení začátečníci dodržují požadavky doslova, což pak vede k extrémům typu, že třeba delší podmínka cyklu ve vyšší úrovni vnoření se rozseká na čtyři kraťoučké řádky, což je ve výsledku daleko hůře čitelné, než kdyby se těch 80 znaků prostě překročilo. Jestli používají checkpatch.pl, to už v tom IMHO nehraje moc roli.

[Marián Kyral]

Díky. V každém případě, ta věta potřebuje drobnou opravičku

[tom]

"dat na nekoho/neco" = prijmout jeho rady

[Marián Kyral]

Aha, tak takhle. No já tam na první pohled četl "nadávají" a pak už jsem to nedostal z hlavy.

[Michal Kubeček]

Mně zase chvíli trvalo, než jsem pochopil to "postavení". :-)

[Bedňa]

Kam se hrabe Bittner,to se nedá srovnat

[Marián Kyral]

Copak Bittner, ale jmelí. Víte kolik se letos urodilo jmelí?

[Bedňa]

Copak jmelí, lišek se přátelé urodilo tolik, že v tlustých pásek pokrývaly celé stráně a nad obcí Kušlov se jeden takový pás utrhl a zcela zavalil usedlost rolníka Mrázka.

[cronin]

Vy všichni, jak ste tady, tomu rozumíte?

[Ash]

Také jsem to "dávají" nemohl pochopit (co dávají, kam dávají, nebo nadávají??). Po přečtení originálu se to vyjasnilo.

[Marián Kyral]

Ono asi nejméně matoucí by bylo "dávají na rady checkpatch.pl"