Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu

19. 5. 2014 | Luboš Doležel | Jaderné noviny | 5013×

Aktuální verze jádra: 3.15-rc3. Počáteční podoba kGraftu.

Obsah

• Aktuální verze jádra: 3.15-rc3
• Počáteční podoba kGraftu

Aktuální verze jádra: 3.15-rc3

Aktuální vývojová verze jádra je 3.15-rc3 vydaná 27. dubna. Máme za sebou další týden a další rc. Zatím nic hrozivého a rc3 je odpovídajícím způsobem menší než rc2, takže se to odvíjí správně.

Stabilní aktualizace: verze 3.14.2, 3.10.38 a 3.4.88 vyšly 26. dubna.

Počáteční podoba kGraftu

Nutnost restartovat systém kvůli instalaci opravy jádra je otravné. V mnoha případech je to dokonce ještě horší: systém(y), o které jde, mohou mít omezení týkající se dostupnosti, která znemožňují restartování dle potřeby. Uživatelé, kteří takovým nesnázím čelí, by často rádi měli způsob, jak dostat do jádra kritický patch bez nutnosti systém vypnout. Jako odpověď na toto se už v roce 2008 objevila první verze sady patchů Ksplice. Ksplice se nikdy ale nedostalo do hlavní řady jádra a po odkoupení Oraclem pravděpodobně z linuxového světa zmizelo. V poslední době bylo oznámeno několik alternativních patchů nabízejících podobnou funkčnost; jeden z nich – kGraft – byl nyní zaslán ke zvážení.

KGraft je prací Jiřího Kosiny a Jiřího Slabého ze SUSE. Přístup, který použili, je snazší než v případdě Ksplice a scházejí mu některé schopnosti, které Ksplice nabízí. Na druhou stranu má základní patch s kódem kGrafu jen 600 řádek a proces aplikace patchů je o dost jednodušší a s menším dopadem na systém.

KGraft funguje tak, že v jádře nahrazuje celé funkce. Za použití nástrojů dodaných s kGraftem může na základě patche jádra vytvořit seznam změněných funkcí; nové verze těchto funkcí jsou pak zkompilovány do odděleného jaderného modulu. Jakmile je tento modul nahrán do jádra, kGraft se postará o nahrazení stávajících porouchaných funkcí jejich novými opravenými verzemi.

Toto nahrazování je poněkud zrádná věc; operování jádra za živa skýtá spousty nebezpečí. Dobrou zprávou pro vývojáře kGraftu je to, že tento problém už byl za ně z větší části vyřešen. Subsystém trasování funkcí (ftrace) potřebuje dělat právě tento typ patchování za běhu, takže se vývojáři ftrace už postarali o napsání kódu, který to zajistí, odladili všechny podivné vady a také to náležitě odnesli, když něco nefungovalo tak, jak by mělo. Vývojáři kGraftu zkrátka jen musí použít nástroje ftrace – které už umí zachytit volání funkcí v běžícím jádře – a použít je k nahrazení volání vadných funkcí za volání nového kódu.

Jsou tu samozřejmě ještě nějaká rizika. Tím největším z nich je: co se stane, když proces běží při aplikování patche zrovna v jaderném prostoru? Tento proces může jednou zavolat starou verzi funkce a krátce na to zavolat novou verzi; v závislosti na tom, co se mezitím změnilo, by to mohlo vést ke zmatení a k výpadkům, kterým se právě takto snažíme předejít. Při pohledu na tento problém dospěli vývojáři kGraftu k tomu závěru, že se dá problémům předejít, pokud žádný proces neuvidí dvě verze té samé funkce při jediném průchodu do jaderného prostoru a zpátky.

Proto patch přidává do struktury thread_info v každém procesu příznak, zda tento proces opustil nebo se vrátil do uživatelského prostoru od začátku aplikování patche. Jakmile je zachyceno volání staré funkce, „pomalý pahýl“ zkontroluje zmiňovaný příznak pro běžící proces; pokud proces vstoupil do prostoru jádra nebo jej opustil, tak se má za to, že běží ve „starém světě“ a dostane starou verzi této funkce. Jinak se řízení předává nové verzi. Jakmile každý proces v systému přešel do nového světa, pak může být pomalý pahýl odstraněn a nová funkce může být volána nepodmínečně.

A co s procesy, které tento přechod neprovedou v rozumném čase? Například proces zaseklý při čekání na I/O na síťovém socketu by mohl v jádře zůstat velmi dlouho a bránil by tak pročištění po operaci graft. Když Vojtěch Pavlík hovořil o této práci na březnovém Linux Foundation Collaboration Summitu, zmínil mechanismus, který by pomalým procesům poslal signál, aby byl přechod vynucen. Tento mechanismus ale není v zaslaném patchi přítomen. Na druhou stranu je pod /proc k dispozici příznak umožňující administrátorům identifikovat procesy, které brání dokončení operace.

Další otázka: co s jadernými vlákny, která nejsou spuštěna z uživatelského prostoru? Většina jaderných vláken, jakmile doběhnou do vhodného místa, zavolá kthread_should_stop(), aby zjistila, jestli se mají ukončit. Kód kgraft upravuje kthread_should_stop() tak, aby resetovalo příznak „starého světa“. Pro vlákna, která taková volání nedělají, vložili vývojáři kGraftu volání kgr_task_safe(), která na vhodných místech značí přechod do nového světa.

Nakonec tu máme otázku přerušení. Kód kgraftu může blokovat přerušení na lokálním CPU, zatímco provádí změny, ale nemůže je zablokovat globálně. Aby si kGraft byl jistý, že při běhu obsluhy přerušení nedojde k žádným překvapením, tak přidává pole specifické pro každé CPU, aby bylo možné sledovat, zda každý procesor běžel v kontextu procesu (mimo přerušení). Tento příznak je ze začátku nastavený na false a následně je zavoláno schedule_on_each_cpu(), aby došlo ke spuštění funkce kGraftu v kontextu procesu na každém z procesorů. Tato funkce, která nemůže být spuštěna, dokud jsou obsluhována přerušení na daném CPU, nastaví pro dané CPU příznak. Pahýl umístěný při nahrazování funkce mezitím vynutí to, aby kód z obsluhy přerušení používal kód ze starého světa, dokud nemá dané CPU nastavení příznak pro „nový svět“.

Tento článek byl napsán jen krátce po zaslání patche kGraft, proto doposud není moc co psát o reakcích, jaké vyvolal. Zatím se ale neobjevily žádné námitky k tomu, jak vývojáři celou věc pojali. Tato funkčnost má zjevný přínos, takže můžeme očekávat, že něco někdy bude začleněno. Nejistotu do rovnice vnáší další soupěřící patche, jež čekají na svou příležitost. V jádře není místo pro dva nebo více mechanismů pro patchování za běhu, takže tyto patche buď budou muset být sjednoceny, nebo bude někdo muset učinit rozhodnutí.

       

Komentáře

[Honz]

Překlep: operování jádra za živa

[1john2]

Muze nekdo prosim vysvetlit ten "pomaly pahyl"?

[Petr Tomášek]

Stačí se podívat na průměrný pornoserver a pochopíš...

[Milan Vančura]

Ten termín znamená: "Pokaždé se dobře rozmysli, jestli česká lokalizace je krok ke zlepšení porozumění počítači nebo spíš naopak." - a o článcích o SW to platí taky :)

Abychom si rozuměli: já nehaním překladatele, já poukazuji na to, že všichni trpíme neustálenou terminologií. Překladatelé v prvé řadě. Myslím, že to jsou zkušenosti, které člověku připomenou, že máme obdivovat lidi jako byl Presl.

[Radek Hladik]

Ono je to těžké, dneska se všecko tak rychle vyvíjí, že neni moc čas tu termitologii ustalovat Vzpomínám si, jak jsme ve škole (FI MUNI) měli předmět o češtině a stylu, kde jsme měli psát všecko česky. Asi už to nenajdu, ale opravdu to občas byly perly, kterým nikdo nerozuměl. V hlavě mi zůstalo snad jen "ochranný štít"...

[petr_p]

Pahýl je znám z české Wikipedie. Pomalý je běžný překlad běžného přívlastku. Navíc autor sousloví změkčil uvozovkami, jak pravidla žádají. Jinak řečeno tohle byl záměr a já jsem se dobře pobavil.

[Michal Kubeček]

Já si zase myslím, že je-li v odborném článku jedinou možností, jak termín pochopit, otrocký překlad zpět do angličtiny, je něco špatně. Ale já jsem obecně toho názoru, že národní obrození sice bylo nutnou a významnou kapitolou našich dějin, ale že už sto let nemáme důvod v něm pokračovat…

[Milan Vančura]

Naprosto s tebou souhlasím ohledně tohoto článku: nemá asi smysl zavádět českou terminologii pro funkce linuxového kernelu, že. Ale je potřeba nahlas říct proč: protože komunita kolem linuxového kernelu je mezinárodní a neexistuje významná česká sub-komunita, která by potřebovala vlastní terminologii. Proto měl být v článku uvedený v závorkách původní výraz.

Oproti tomu pro termíny jako "directory", "mail folder" atp. je závěr přesně opačný, protože je přesně opačná i situace lidí, kteří je používají: jsou to už dnes laici žijící normálně v ČR, mluvící česky a používající tyto termíny v běžné mluvě i psané formě - naprosto mimo IT sféru. A přesně pro takové termíny je potřeba mít jednotný český překlad, s českými možnostmi skloňování či časování atp. aby se dal nešroubovaně použít v běžných větách typu "Do Prčic, do kterého 'mail folder' `sem si mrskla ten recept na bábovku od Boženky?!".

Proto naopak považuji myšlenku národního obrození, samozřejmě moderně chápanou (bez nacionalistických extrémů), za nejen stále živou, ale zrovna v naší branži extrémně potřebnou.

[Michal Kubeček]

Oproti tomu pro termíny jako "directory", "mail folder" atp. je závěr přesně opačný, protože je přesně opačná i situace lidí, kteří je používají: jsou to už dnes laici žijící normálně v ČR, mluvící česky a používající tyto termíny v běžné mluvě i psané formě … Proto naopak považuji myšlenku národního obrození, samozřejmě moderně chápanou (bez nacionalistických extrémů), za nejen stále živou, ale zrovna v naší branži extrémně potřebnou.

Vytváření vlastních překladů (nebo někdy jen přepisů) termínů používaných v běžném životě je ale proces, který se děje v každé době a v každé zemi - a děje se i u národů, které byly vždy natolik svébytné, že hnutí odpovídající našemu národnímu obrození nikdy nepotřebovaly. Tím (ne)pokračováním v národním obrození jsem myslel právě to, že dnes už nejsme v situaci, kdy by bylo potřeba povzbuzovat umírajícího národního ducha tím, že bychom za každou cenu počešťovali úplně všechno.

[Milan Vančura]

Ale je potřeba organizovaná snaha o to sjednocení terminologie. Jinak skončíme tak, že nám vnutí Microsoft to z Windows, byť to budou občas nesmysly. A to je ještě ten lepší případ, jak vidíš v roztříštěnosti počeštění aplikací na Linuxu. Každý si nazývá i úplně obyčejné věci jinými termíny a výsledek je, že lokalizace má opačný efekt než by měla mít: zabraňuje porozumění.

A tu organizovanou snahu vedenou vzdělanými lidmi bych nazýval právě tím moderním národním obrozením. I když je to zavádějící termín. Spíš by se nemělo pro to hledat žádná "vznešená" pojmenování, ale brát to jako běžnou údržbu jazyka, běžnou práci Ústavu pro jazyk český.

[CZTomi]

Ano, tak jest. Nejhorší jsou pseudo české překlady made in Microsoft. Zrovna včera mi volal BFU brácha, že potřebuje cosi nastavit ve WIN7 (kooperaci se SAMBOU). On samozřejmě má české WIN a zaboha se mi nepovedlo ho po telefonu navést, co tam má nastavit. A úplně nejhorší na tom je, že u zrovna ne nevýznamné části populace se ta hatmatilka bere jako oficiální česká IT terminologie. Nebo termitologie?

[Michal Kubeček]

To ale tak úplně nesouvisí s otázkou překladu termínů, protože Microsoft si dost často své vlastní termíny rozdílné od zavedených zavádí i v angličtině.

[Filip Jirsák]

Rychlá cesta / pomalá cesta se v jádru používá pro označení variant kódu při optimalizaci. Rychlá cesta je rychlejší kód, který se použije ve velkém množství případů, nebo v případech, které nejsou nějakou změnou ovlivněny. Pomalá cesta je pomalejší kód, často je tam různé zamykání, a používá se ve speciálních případech. Pahýl je tady použit z toho důvodu, že to není celá ta funkce s nějakou logikou, ale je to jenom krátký kód, který má rozhodnout o tom, která varianta funkce se má použít. Pomalý pahýl je to tedy z toho důvodu, že je to pomalejší kód (je tam nějaký zámek) a není to ten skutečný výkonný kód funkce. Když z běhového prostředí zmizí všechny případy, kdy by bylo nutné volat tu starou verzi funkce, nahradí se tahle pomalá cesta kódu rychlou cestou – přímým voláním té nové funkce.

[smazáno]

Vypada skvele. No napada me, ze jednodusse nahradit funkci je ok v erlangu nebo v haskellu.

Ale to prece nemuze stacit na live patchovani kernelu napsaneho v C.

[ebik]

A proč ne? Pokud v tom erlangu nebo haskellu máte data uložená v nějakých "strukturách" a změněná funkce v tom udělá bordel a celé to nakonec spadne (zničí data), tak to je přesně to co se může stát v tom C. Rozdíl je jen ten, že v C se musí dávat o trochu větší pozor na strukturu dat.

[smazáno]

V ciste funkcionalnim jazyku by si nemel mit globalni stav (narozdil od C).

Problem, ze muzes zmenit co znamena typ parametru funkce napriklad "void x(foo a) .." a zmenis co znamena foo - se teda tyka i funkcionalnich jazyku.

[Michal]

Pořád nějak nerozumím proč se z live patchování kernelu dělá taková věda a nezmiňuje se že security patche jsou o dost častěji nutné i v userlandu?

Instalovali jsme teď Oracle RAC pro zákazníka a oni (aniž by pořádně věděli o čem mluví) strašně trvali na ksplice aby už nikdy nemuseli ty servery rebootovat. No fajn říkám, ale co když bude nějaký další Heartbleed v OpenSSL, co když bude security bug v Glibc, atd? Stejně bude potřeba restartovat většinu procesů a to už zrovna můžeme rebootovat celý stroj.

Nějak ten hype kolem ksplice / kgraft nechápu - vždyť to řeší jen zlomek problému...?

[ebik]

No v "běžném" provozu je dobré být připraven na výpadek/odstávku stroje z různých důvodů, takže se ten reboot výjmečně udělat může. Ale existuje pár (extrémních) případů, kdy to má smysl. Třeba pokud by to byl řídící systém nějakého HW, které zrovna nelze vypnout, tak bych ten řídící linux asi nerad rebootoval.

[pavele]

Třeba když to bude HW, na kterém právě běží robotická operace srdce. Těžko potom budeš vysvětlovat mrtvému pacientovi, že byl potřeba reboot kvůli aktualizaci jádra.

[Michal Kubeček]

To není moc dobrý příklad. Systém, kde stačí počkat pár hodin a pak už bude všem jedno, že je pár minut down, rozhodně není use case pro live kernel patching.

[ebik]

Ne pokud, ta oprava zabraňuje úspěšnému dokončení operace.

[Michal Kubeček]

Zkuste si rozmyslet, jak reálná taková situace asi je.

[Sid]

tak tak, skor by som zameral pozornost na rozne scada aplikacie napr. Kde sa casto skor riesi HW aby bol dokonale odolny a ocakava,ze to nepretrzite bude bezat roky.

[victor8]

Ani velmi nie - SCADy (aspon tie ktore som mal ja tu "cest" vidiet) bezia vo vacsine pripadov na windowse (casto som vidaval este w2k, a to sa bavim o roku 2006+), a vonkoncom sa od nich nerata, ze by mali bezat 24/7/365.

Koniec-koncov, SCADA sa aj tak len pripaja niekam na PLCcko, ktore riadi technologicky proces - to uz v kuse bezat samozrejme musi :)

[Sid]

no asi zalezi na tom co si videl. A ze sa pripaja SCADA len na PLC je tiez zavadzajuce. Sice je fakt a mas pravdu, ze Windows je az neuveritelne rozsireny v automatizacnom svete. Ale ked sa budeme bavit o unixe tak som videl vxWorks a Solaris a aj Linux. Zaroven to boli stroje stroje ktore maju uptime v rokoch. Osobne som sice v automatizacii nezazil taku situaciu kde by restart sa nedal vylozene urobit ale islo to napr cez x ludi, v pripade dlhsieho vypadku (hodina) uz boli z toho tahanice takze si viem dobre predstavit, ze obcasny patch nejakej superkritickej veci bez toho aby sa prerusila sluzba by mal celkom dobry vyznam. Kde som toto patchovanie za behu zazil boli telekomunikacie kde sa bezne patchovalo jadro (ale vlastny OS). A robilo sa to napriek tomu, ze povacsine tie karty boli spriahnute 2 takze v pripade vypadku jednej by nastupila zalozna.

[victor8]

Suhlasim, svet je vacsi ako to com som mal moznost vidiet ja - povacsinou len Promoticy, popr. WinCC - v podstate veci na "domace" zuvanie.

Asi sa zhodneme, ze takato moznost v kerneli nikdy nebude na skodu, aj keby sa v zivote nemala pouzit (co by bol zrejme idealny pripad), aspon tu moznot mat je vzdy fajn.

[zigi]

Taky se zapomina na to, ze i ten hardware obcas potrebuje udrzbu.

Aktualiza BIOSu, firmwaru RAID radice, firmwaru dohledove karty (eLOM, iLOM, iLO, DRAC atd. - obcas ty mrsky dokonce chtej na par minut odpojit od napajeni), vymena BBU u RAID radice atd.

Takze odstavkam se clovek fakt nevyhne, pokud to chce delat dusledne. Proti tomu vsemu zase jde zlate pravidlo, ze kdyz to funguje, nech to byt a nesahej na to.

Opravy totiz nechodi samy a sem tam sebou privedou problem nekde jinde.

[Michal Kubeček]

Smysl live kernel patching není vyhnout se odstávkám úplně. Jde o to, aby v případě kritické chyby v jádře (např. remote root exploit) bylo možné odložit tu odstávku na reboot do doby, kdy se to bude hodit (až update projde interní QA zákazníka, až bude maintanance window, až doběhne měsíc trvající simulace, …).

Rozhodně je tedy mylná představa, že se budou live patche generovat pro všechny opravy (to obecně ani nejde) a rebootovat se nebude nikdy. Jde o to, aby když přijde kritický problém, s jehož opravou nelze čekat dny až týdny, opatchovalo se živé jádro a s rebootem na nový update se mohlo počkat na vhodný okamžik.

[Milan Vančura]

No, jak bych to tak řekl... Napadla tě možnost: "Protože jim Oracle obchodníci vymluvili díru do hlavy, když si kupovali ten RAC."? :)

[Ivan]

Pokud provozujete celo-zemekoulovej system tak s tim muzete mit problemy. V takovym pripade se da nejlip dohodnout vypadek na dobu kdy slunce prechazi nad Tichym oceanem. Ten je dost velikej a v te oblasti zije jen malo lidi. Ono uplne klidne staci aby se muslimove a zide mezi sebou dohodli jestli vypadek bude v patek, sobotu anebo v nedeli.

S tim RACem to ale moc nechapu. Zrovna tehle SW taky umi hot-patching. Tzn. vetsinu patchu jde aplikovat za behu databaze. Ovsem za jen predpokladu, ze aplikace podporuje TAF (transparent application failover), tzn databaze "nabidne" klientum aby se pripojili na jiny node a pak muzete vesele patchovat - dokonce i ten server muzete otocit.

[Ivan]

Jo jeste jsem si vzpomel. Kdysi jsem taky takovy "ksplice" taky "napsal". Soubor v /proc/<pid>/smaps na RHEL ver 5 nezobrazoval jestli je adresni prostor procesu zamceny anebo ne. Novejsi kernely uz to zobrazovaly. Takze jsem udelal ovladac do kernelu ktery obsahoval fci z novejsiho kernelu (ale s jinym jmenem) a pri natazeni ten modul binarne prepsal zacatek stare fce. Proste tam nakopiroval instrukci "jmp <addr>. Takze pri vypisovani toho souboru kernel zavolal starou fci, ale ta hned skocila na zacatek "nove" fce z mojeho modulu.

[Jiri Kosina]

I short jmp ma na x86_64 5 bajtu, takze atomicky tu zmenu neprovedete; tudiz se muze klidne stat, ze kdyz zrovna bude nejaky jiny CPU vykonavat kod na dane adrese, uvidi nesmyslny opcode.

[Ivan]

Jo to se muze stat. Nastesti v mym pripade jsem vedel, ze jsem to jen ja kdo pristupuje k tomu /proc filesystemu. Myslim, ze MSVC na to ma neco podobneho prepinac /hotpatch ktery zaruci, ze prvni instrukce ve funkci ma alespon 2 bajty. Akorat nevim jakou instrukci tak cpou oni.

[Jiri Kosina]

Pokud vim, tak oni pouzivaji neco trochu jineho -- maji v kazde funkci od zacatku pripraveny relativni short jmp s defaultnim offsetem 0 (tedy vpodstate nop -- relativni skok na nasledujici instrukci) a v pripade patchovani skoci timto kraktym jumpem na rezervovane misto pred funkci, kde si mohou v klidu predtim pripravit dlouhy jmp.

[smazáno]

Zajimave. Predpokladam, ze toto nemusite v kgraft resit, diky tomu rozsireni struktury thread_info.

A kdyz uz jsme v tomto threadu, jak toto resit v userspace?

Mimochodem, chapu spravne, ze patche pro kgraft musi byt specialne pripravene a overene (tzn. nova funkce napr. nemuze pouzivat jine definice struct atd. )?

[Jiri Kosina]

Pro userspace je to aktualne trochu komplikovane -- slo by pres ptrace() vkladat na prislusna mista int3 trapy a ty pak handlovat, ale to neni uplne sikovne. Existuje patchset ktery pridava novy syscall text_poke(), ktery implementuje vpodstate to same co kernelovy text_poke_bp() pro userspace kod, ale zatim neni zamergovany.

A ano, live patche budou zcela jiste vzdy vyzadovat nejakou manualni interakci a overeni, i kdyz je snaha celou zalezitost co nejvice automatizovat.

[smazáno]

Me napada. Attachnu gdb k procesu, pokud zadny thread neni zrovna v te funkci co se chystam patchovat, tak proste vlozim na zacatek jmp instrukci. Pokud nejaky thread zrovna je v te funkci, tak nejjednodussi asi chvili pockat a zkusit znova (nebo si trochu pohrat s breakpointama jak rikas). Ptrace imho staci.

[nyan]

Ono uplne klidne staci aby se muslimove a zide mezi sebou dohodli jestli vypadek bude v patek, sobotu anebo v nedeli.

Jo, ten byl dobrej, diky

[Michal]

S tim RACem to ale moc nechapu. Zrovna tehle SW taky umi hot-patching.

Sam sebe jiste opatchovat umi, ale kdyz je chyba v externi knihovne, treba OpenSSL nebo v GLibc tak ti to nepomuze.

[Ivan]

Pomuze mi rolling upgrade. RAC umoznuje presunout service a vsechna DB spojeni na jiny node v clusteru. Pak si muzu delat co chci, dokonce i rebootovat. Pak ten node vratim do clusteru a ani nevadi, ze kazdy nod v clusteru pouziva jinou verzi binarek. No a pak udelam to samy s druhym(a kadym dalsim) nodem.

Bohuzel Oracle obcas taktne zamlcuje, ze presun konexi mezi nody musi podporovat i aplikace.

[smazáno]

Jo souhlas - stejny (podobny) pristup by sel (a mel byt pouzit) i pro userspace. Gdb a trochu python ...

[nyan]

No, smysl to ma u virtualizace - teda konkretne patchovani jadra hosta. Preci jen userspace u hosta neni kritickej, a rebootovat vsechny guesty kvuli update hosta je vopruz.

(ovsem jestli tadle sada patchu funguje i s virtualizaci, netusim)

Ale jinak souhlas, u ostatnich masin je userspace vetsi problem.

Kdyz uz mas tendle napad... muzes zkusit napsat vlastni nastroj pro patchovani userspace-u a udelat hype kolem neho

[j]

Guesty premigrujes za chodu na jinyho hosta ... a sklidem restartujes co jen hrdlo raci ... provozovat ve virtualu vic stroju na singl stroji muze stejne leda blazen. To je prave ta krasa virtualizace ... ze tohle nemusis resit.

At ctu jak ctu, zatim tu nikdo neprisel s nicim, kvuli cemu by tohle bylo treba resit.

[Michal]

Kdyz uz mas tendle napad... muzes zkusit napsat vlastni nastroj pro patchovani userspace-u a udelat hype kolem neho

Jdu na to. Pojmenuju to usplice a pak to zkusim prodat Oraclu za mega penez ;)

[Grunt]

WOW. Já když tak sleduju složitost s jakou rostou na první pohled jednoduché úkoly v jádře si říkám, že on ten mikrokernel s IPC mezi servery na úplném začátku nebyl až zas tak úplně špatný nápad. Monolit linux už dávno není a zatím to vypadá na hybrid, který se blíží ideálu mikrojádra s tunou modulů pro každý úkol včetně uprdnutí si, víc a víc. Akorát při zběžném pohledu na některé funkce si říkám, že i kdybych to chtěl vymyslet fakt složitě, na tohle bych nepřišel. Vidím to tak, že až se bude linux blížit verzi 3.55.2-rc5 se kompletně celé zdrojáky zahodí a zůstanou jako legacy mód pro embedded zařízení a jaderní vývojáři se přesunou k vývoji GNU/Hurdu 0.5 (u této příležitosti se vydá ještě GNOME4 aby toho nebylo málo), ne?

[Michal Kubeček]

zatím to vypadá na hybrid, který se blíží ideálu mikrojádra s tunou modulů pro každý úkol včetně uprdnutí si

To si vůbec nemyslím. I kernel thready běží pořád ve stejném paměťovém prostoru a se stejnou úrovní oprávnění jako "core" jádro. Navíc když si vezmu typický driver zařízení, třeba síťové karty, tak mám sice oddělenou hardirq a softirq část, ale nejen že IRQ handler je součástí jádra, ale ani ta softirq část neběží zdaleka vždy v rámci kernel threadu. Takže ideálu mikrokernelu, kde by byly drivery zařízení striktně odděleny od "core" jádra, nejsme o moc blíž než na začátku.

[Grunt]

I kernel thready běží pořád ve stejném paměťovém prostoru a se stejnou úrovní oprávnění jako "core" jádro

To je vlastně fakt. Jenže díky tomu taky hodně stoupá složitost samotného monolitického blobu. Ono už z názvů funkcí lze vytušit, že provést nějaký jednoduchý úkol v jádře nemusí být jenom tak. Tohleto on-line patchování tomu jen nasazuje korunku (přitom by stačilo zabít příslušný proces a spustit ho znova).

[Michal Kubeček]

Ten nárůst komplexity je zjevný, ale ona není samoúčelná. Ve starých jádrech sice byla spousta věcí jednodušší, ale tehdejší jádra nemusela být schopna běhat na 4096 procesorech a obsluhovat 6 TB paměti nebo čtyřicetigigabitové ethernetové karty, život vývojářů nekomplikovaly věci jako namespaces nebo cgroups atd.

Pokud si dobře vzpomínám na někdejší debaty na téma monolitické jádro vs. mikrokernel, tak hlavní problém byl právě v tom, že úplně čistý mikrokernel měl sice spoustu designových předností, ale nikdo ho nedokázal implementovat tak, aby to bylo neprůstřelné a efektivitou se to vyrovnalo monolitickým jádrům. A za jeden z hlavních důvodů toho, proč se z mnoha různých systémů prosadil právě Linux, považuji to, že Linus je pragmatik, neopájí se tolik vznešenými idejemi a má čich na výběr toho řešení, které bude rozumně fungovat. Což ve výsledku znamená, že v Linuxu je sice spousta designových kompromisů a nouzových řešení, nad kterými srdce neplesá, ale na druhou stranu se moc často nestává, že by se prosadilo řešení, které je sice teoreticky dokonalé, ale v praxi buď pořádně nefunguje nebo je zoufale neefektivní.

[Grunt]

Ve starých jádrech sice byla spousta věcí jednodušší, ale tehdejší jádra nemusela být schopna běhat na 4096 procesorech a obsluhovat 6 TB paměti nebo čtyřicetigigabitové ethernetové karty, život vývojářů nekomplikovaly věci jako namespaces nebo cgroups atd.

Pravda. Jen by nebyly složité samotné subsystémy a ovladače, nýbrž servery v uživatelském prostoru.

Pokud si dobře vzpomínám na někdejší debaty na téma monolitické jádro vs. mikrokernel, tak hlavní problém byl právě v tom, že úplně čistý mikrokernel měl sice spoustu designových předností, ale nikdo ho nedokázal implementovat tak, aby to bylo neprůstřelné a efektivitou se to vyrovnalo monolitickým jádrům. A za jeden z hlavních důvodů toho, proč se z mnoha různých systémů prosadil právě Linux, považuji to, že Linus je pragmatik, neopájí se tolik vznešenými idejemi a má čich na výběr toho řešení, které bude rozumně fungovat. Což ve výsledku znamená, že v Linuxu je sice spousta designových kompromisů a nouzových řešení, nad kterými srdce neplesá, ale na druhou stranu se moc často nestává, že by se prosadilo řešení, které je sice teoreticky dokonalé, ale v praxi buď pořádně nefunguje nebo je zoufale neefektivní.

Moje pozorování? Ten pragmatismus se k tomu idealismu vždycky pragmatickou cestou stejně propracuje. Dle mého názoru prostě složitost jádra furt poroste až jednoho dle prostě Linus prohlásí „Tenhle bloatware já udržovat nebudu. Smazat a znovu přepsat!“ a stejně se to k něčemu jako je GNU/Hurd jednou propracuje. Akorát to bude dýl trvat.

[Michal Kubeček]

…a stejně se to k něčemu jako je GNU/Hurd jednou propracuje. Akorát to bude dýl trvat.

Dokud neuvidím, neuvěřím. :-)

Připomíná mi to, jak jsem se někdy v roce 1993 nebo 1994 začal zajímat o to, jak dostat na PC nějaký unixový systém, a kamarád mi zasvěceně vysvětloval, že unix, to už je odepsaná záležitost, že teď je skvělý nový systém plan9, který je navržen mnohem lépe a že to je budoucnost…

[Grunt]

, to je fakt. Ale teď je situace opravdu, ale opravdu jiná.

[Bystroushaak]

plan9, který je navržen mnohem lépe a že to je budoucnost…

To je v podstatě to, o čem Grunt mluví. Vždyť linux k tomu už skoro dospěl, jen je podstatně ošklivější a táhne si s sebou některé opravdu nepěkné dedictví (tty například).

[Grunt]

tty například

Huh? Co je špatně na tty?

[Bystroushaak]

Třeba to, že je to uvnitř pořád to samé, co kdysi řídilo dálnopisné tiskárny? Tedy nepřehledný mess věcí, které jsou dnes z většiny k ničemu? Programování složitějších multiplatformních (třeba jen v rámci unix-like systémů) terminálových aplikací je docela bolest.

Jinak viz seriál na rootu.

[Grunt]

Jo, to možná jo. Na druhou stranu fakt, že můžu ke konzoli připojit svůj Robotron a vím, že to bude fungovat mě docela hřeje u srdce.

[Michal Kubeček]

Vždyť linux k tomu už skoro dospěl

Jak se to projevuje?

[Bystroushaak]

Spousta dobrých myšlenek z Plan9 byla začleněna do linuxu. Například FUSE.

[Michal Kubeček]

To je hodně divoká konstrukce. FUSE se používá v Linuxu jako rozhraní pro speciální filesystémy, které buď v jádře z nějakých důvodů implementovat nejde (ZFS) nebo by to bylo příliš nepraktické (curlftpfs). Tedy spíš tam, kde není jiného zbytí. Výkon za moc nestojí a skoro nikoho by nenapadlo používat to pro normální filesystémy na běžných instalacích. Tomu říkáte "Linux skoro dospěl k plan9"? Opravdu myslíte, že takhle nějak si to lidé, kteří navrhovali plan9, představovali?

[Bystroushaak]

Opravdu myslíte, že takhle nějak si to lidé, kteří navrhovali plan9, představovali?

Ne, to si nemyslím. Na druhou stranu spousta z technologií, které tam uvedli byla portována v nějaké alternativě do linuxu. /proc, používání UTF a FUSE jsou takové hlavní příklady, které nemusí být nutně tak elegantní, jak byly navrženy v plan9, ale funkčně jsou na tom dost podobně. Tím nechci hanit plan9, ani nějak vyzdvihovat linux.

Osobně by se mi líbilo, kdyby se plan9 pohnul k větší praktické použitelnosti a z dlouhodobého hlediska se mu chci věnovat víc, až na to někdy budu mít čas.

[Michal Kubeček]

/proc, používání UTF a FUSE jsou takové hlavní příklady, které nemusí být nutně tak elegantní, jak byly navrženy v plan9, ale funkčně jsou na tom dost podobně

Tomu se tuším říká post hoc ergo propter hoc. Unicode se vyvíjel nezávisle na plan9 a postupný příklon k němu měl pramálo společného s tím, že si ho vybrali (i) v plan9. K FUSE už jsem se vyjádřil. A procfs existoval i v řadě jiných systémů, a to dokonce i před plan9. Stránka na wikipedii sice tvrdí, že implementace v Linuxu vznikla jako klon té z plan9, ovšem s poznámkou "citation needed". Ale i kdyby to byla pravda, stejně je to moc málo na to, aby se dalo tvrdit "Vždyť linux k tomu už skoro dospěl."

[Bystroushaak]

Unicode se vyvíjel nezávisle na plan9 a postupný příklon k němu měl pramálo společného s tím, že si ho vybrali (i) v plan9.

Unicode vs UTF. Afaik UTF-8 vzniklo právě pro plan9, ale můžu se mýlit.

Ale i kdyby to byla pravda, stejně je to moc málo na to, aby se dalo tvrdit "Vždyť linux k tomu už skoro dospěl."

Mě to stačí :)

[Michal Kubeček]

Unicode vs UTF.

V tom případě ale také UTF vs. UTF-8.

Afaik UTF-8 vzniklo právě pro plan9, ale můžu se mýlit.

Podle wikipedie sice s poslední úpravou oproti předchozím kódováním přišel Ken Thompson, který v té době pracoval na plan9, a plan9 byl prvním systémem, který UTF-8 začal používat, ale přesto bych to nepovažoval za nějakou featuru převzatou z plan9.

[Bystroushaak]

Moje pozorování? Ten pragmatismus se k tomu idealismu vždycky pragmatickou cestou stejně propracuje.

Tohle je docela dobré pozorování, které platí i v programovacích jazycích. Za pár (desítek) let bude vše hybrid mezi erlangem, smalltalkem a lispem :)

[Grunt]

Tohle platí úplně všude, nejen v prog. jazycích.

[Michal]

Tak to doufám že ne! Nerad bych se dočkal řízku co by byl hybrid mezi erlangem, smalltalkem a lispem!!!

[Bystroushaak]

To já se řízku nebojím! Hybrid nehybrid, pokud to není zkažené, tak na sádle, s trochou cibulky a pažitky by to nemělo chybu.

[Grunt]

Přílohy:

• IMG092.jpg (270970 bytů)
• IMG093.jpg (277346 bytů)

Suchare. Já žeru řízky i růžové a svítící… bych chtěl vidět jak by ses pak nebál. I když trocha kečupu, salátu, erteplí a nikdo skoro nic nepozná.

[ebik]

Jenže se dopracuje k tomu ideálnímu stavu jen tam je to potřeba. Tam kde to potřeba není a kde idealismus zanáší zbytečnou složitost zůstane jednoduché a přehledné řešení.

[ebik]

A tak kde o to nejde tak zůstane sice ošklivé řešení, ale s tím, že až to bude potřeba přepsat, tak pak teprve tomu někdo věnuje drahocenný čas vývojáře. Další výhodu pragmatismu vidím v tom, že idealismus občas vyřeší naprosto elegantním způsobem situaci, ke které v praxi nedojde a ztíží řešení situace ke které dojde.

Co je ale důležitější Linuz umí vést projekt tak, aby jeho vývoj byl trvale udržitelný. Prostě žádné nakupení featur (včetně návrhových featur) s tím, že se to vyčistí později (na což nedojde a další vývojář v pořadí provede refaktor, protože není v jeho silách porozumět kódu, který napsal předchozí vývojář). A to není jen o pragmatismu.

[citanus]

 

Co je ale důležitější Linuz umí vést projekt tak, aby jeho vývoj byl trvale udržitelný. Prostě žádné nakupení featur (včetně návrhových featur) s tím, že se to vyčistí později (na což nedojde a další vývojář v pořadí provede refaktor, protože není v jeho silách porozumět kódu, který napsal předchozí vývojář). A to není jen o pragmatismu.

+1

 

[mato]

A čo taký QNX príp. vxWorks ? .. Tie sa zdajú dostatočne výkonné.