abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 01:23 | Zajímavý projekt
Studio Weybec ve spolupráci s Blender Institute představilo krátký pětiminutový open-source film Monkaa (YouTube). Film byl vytvořen pomocí Blenderu, GIMPu a dalšího otevřeného softwaru. Zájemci o datové soubory uvolněné pod licencí CC-BY si mohou zakoupit DVD nebo předplatit přístup do Blender cloudu.
Ladislav Hagara | Komentářů: 4
včera 21:30 | Nová verze
Bylo vydáno Ubuntu 14.10 s kódovým jménem Utopic Unicorn. Ke stažení jsou k dispozici Ubuntu Desktop a Server, Ubuntu Cloud Server, Ubuntu Netboot, Ubuntu Core, Kubuntu, Lubuntu, Ubuntu Studio, Ubuntu GNOME, Ubuntu Kylin, Xubuntu a Mythbuntu. Podrobnosti v poznámkách k vydání.
Ladislav Hagara | Komentářů: 0
včera 14:08 | Zajímavý článek
Ovladač čipů FTDI pro Windows naštval spoustu uživatelů čínských napodobenin tím, že u těchto napodobenin mění ProductID v EEPROM na 0, čímž zabrání jejich fungování nejen ve Windows, ale i v Linuxu.… více »
David Šmíd | Komentářů: 67
22.10. 23:34 | Komunita
V Düsseldorfu proběhla minulý týden GStreamer Conference 2014, tj. konference vývojářů multimediálního frameworku GStreamer. Videozáznamy přednášek jsou k dispozici na portálu UbiCast's WebTV.
Ladislav Hagara | Komentářů: 0
22.10. 12:32 | Zajímavý článek
Satya Nadella, CEO Microsoftu, ve svém vystoupení věnovaném cloudové platformě Microsoft Azure (Wikipedia) zmínil také Linux. Přímo řekl, a v prezentaci zdůraznil, že Microsoft má rád Linux (Microsoft ♥ Linux, webcast, 13:55). Důvod je jasný. Linux běží na 20 % Azure.
Ladislav Hagara | Komentářů: 22
22.10. 10:48 | Pozvánky
GDG Prague a GDG Unicorn College pořádá v sobotu 1.11.2014 od 9:30 v Praze celodenní Dart + Polymer Hackathon. … více »
Gug.cz | Komentářů: 0
21.10. 00:36 | Nová verze
Vyšel Emacs 24.4. Mezi novinky patří vestavěný webový prohlížeč (M-x eww), podpora více monitorů, celoobrazovkový mód, digitální podpis balíčků, podpora menu v textovém terminálu či nový blokový mód. Více informací v oznámení nebo v historii viditelných změn na stránce projektu.
little.owl | Komentářů: 18
20.10. 19:57 | Pozvánky
Jana Moudrá Vás 15. listopadu v budově Pilsfree v Plzni seznámí s novým skriptovacím jazykem Dart. Uvidíte spoustu ukázek a bude i prostor pro diskusi. Během následující codelab si můžete nabyté zkušenosti procvičit. … více »
hacup | Komentářů: 0
20.10. 19:54 | Pozvánky
Coreboot je svobodný firmware, „náhrada BIOSu“. O víkendu v Praze probíhal coreboot hackaton. V úterý večer vystoupí v brmlabu zakladatel Corebootu Ron Minnich.
Jendа | Komentářů: 6
20.10. 17:17 | Komunita
Po písmenech S, T a U následuje V. Po Saucy Salamander, Trusty Tahr a Utopic Unicorn následuje Vivid Vervet. Mark Shuttleworth v příspěvku V is for Vivid na svém blogu oznámil, že příští Ubuntu ponese jméno Vivid Vervet.
Ladislav Hagara | Komentářů: 12
Hlasuji z:
 (80%)
 (14%)
 (3%)
 (2%)
 (1%)
 (0%)
Celkem 4557 hlasů
 Komentářů: 50, poslední 12.10. 11:59
Rozcestník
Reklama
Autoškola testy online Levný benzín

Jaderné noviny - 28. 11. 2007

28. 12. 2007 | Robert Krátký | Jaderné noviny | 3173×

Aktuální verze jádra: 2.6.24-rc3. Aktuální verze jádra: 2.6.23.9. Citát týdne: Donnie Berkholz. Přiškrcení množství exportovaných symbolů. kmemcheck - kontrola neinicializované paměti. Aktualizace systémových volání: indirect(), timerfd(), hijack().

Obsah

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

link

Aktuální předverze je (k 28. 11. 2007) i nadále 2.6.24-rc3. Opravy dále velmi rychle proudí do hlavního git repozitáře; 2.6.24-rc4 musí být na spadnutí.

Aktuální verze -mm stromu je 2.6.24-rc3-mm2. Mezi nedávné změny patří nové API timerfd (vizte níže), několik změn ovladačového jádra a aktualizovaná verze bezpečnostního modulu SMACK.

Aktuální stabilní verze řady 2.6 je 2.6.23.9, vydaná 26. listopadu. V této verzi je pár desítek důležitých oprav.

Starší jádra: 2.6.22.14 vyšlo 21. listopadu.

Citát týdne: Donnie Berkholz

link

Linuxové jádro by potřebovalo, aby každou změnu doprovázela dokumentace -- část patche by vždy měla mířit do adresáře Documentation/.

-- Donnie Berkholz

Přiškrcení množství exportovaných symbolů

link

Jaderný mechanismus pro nahrávání modulů neposkytuje modulům přístup ke všem částem jádra. Místo toho musí být každý symbol, který je určen pro použití natahovatelnými moduly, výslovně exportován prostřednictvím jedné z variant makra EXPORT_SYMBOL(). Smyslem tohoto omezení je limitovat dosah modulů a poskytnout relativně dobře definované modulové API. V praxi však exportování moc omezováno není, takže jsou modulům k dispozici tisíce symbolů. Natahovatelné moduly mohou přistupovat k mnoha symbolům, jejichž užitečnost je zjevná (třeba printk() nebo kmalloc()), ale dostanou se i k obecným symbolům typu edd, tpm_pm_suspend(), vr41xx_set_irq_trigger() nebo flexcop_dump_reg().

Některým vývojářům dělá přílišné exportování symbolů právem starosti. Chybně exportované symboly mohou vést autory modulů ke špatným rozhraním; například exportování sys_open() vývojáře aktivně ponouká k otevírání souborů přímo v jádře, což téměř nikdy není dobrý nápad. Ale jakmile jsou symboly jednou exportovány, může být těžké je přestat exportovat. Ačkoliv oficiální stanovisko zní, že interní jaderné API se může měnit kdykoliv, pravda je taková, že přinejmenším někteří vývojáři se zdráhají dělat problémy externím modulům, když se tomu dá vyhnout.

Jako aktuální příklad může posloužit init_level4_pgt - nízkoúrovňový symbol exportovaný pouze architekturou x86_64. Aktuální -mm strom ten export odstraňuje, kvůli čemuž přestává fungovat proprietární modul NVIDIA. Andrew Morton to odstranění popisuje jako fikaný způsob, jak zúžit počet testerů, abychom nedostávali tolik hlášení o chybách. Přestože mnoho vývojářů dává hlasitě najevo, že jim nezáleží na binárních modulech, i tak je dost velká pravděpodobnost, že tohle odstranění exportu (symbolu, který by opravdu neměl být globálně přístupný) kvůli zmiňovanému problému neprojde až do hlavního jádra.

Každopádně je už dlouho patrný zájem o pročištění modulárního API, i když se tomu zrovna moc lidí nevěnovalo. Čas od času někdo ukáže na některý ze snadných terčů: symbolů, které jsou exportovány jen proto, aby bylo možné modularizovat další kousky kódu hlavního jádra. Například celá sada symbolů TCP stacku (věci jako __tcp_put_md5sig_pool()), které mají přesně jednoho uživatele: modul IPv6. Omezení těchto jednoúčelových exportů by mohlo výrazně zeštíhlit modulární API, aniž by bylo těžší hlavní jádro modularizovat.

Andi Kleen navrhl patch implementující jmenný prostor pro modulové symboly, který by měl umožnit právě takové zeštíhlení. S tímto patchem mohou být symboly exportovány do specifických "jmenných prostorů", které jsou dostupné pouze schváleným modulům. Termín "jmenný prostor" v tomto případě zrovna moc nesedí; pořád bude jen jeden globální jmenný prostor, v rámci kterého budou muset být všechny exportované symboly unikátní. Tyto "jmenné prostory" jsou spíše speciální zóny, jež obsahují symboly, které nejsou globálně přístupné. Fungují jako pouze-GPL exporty, které omezují dostupnost symbolů určité podskupině modulů.

Pro vytvoření omezeného exportu je běžná deklarace EXPORT_SYMBOL() změněna na:

    EXPORT_SYMBOL_NS(namespace, symbol);

Kde namespace je název omezeného jmenného prostoru. Takže když se vrátíme k příkladu s TCP, tak Andiho patch obsahuje množství změn jako:

    -EXPORT_SYMBOL(__tcp_put_md5sig_pool);
    +EXPORT_SYMBOL_NS(tcp, __tcp_put_md5sig_pool);

Všimněte si, že není žádná _GPL verze; všechny symboly exportované do konkrétního jmenného prostoru jsou automaticky brány jako pouze-GPL.

Druhou částí rovnice je umožnění přístupu ke jmennému prostoru. K tomu slouží:

    MODULE_NAMESPACE_ALLOW(namespace, module);

Taková deklarace (jež se musí objevit v modulu, který exportuje symboly do namespace) říká, že daný module může přistupovat k symbolům v určeném jmenném prostoru. Andiho patch vytváří tři jmenné prostory (tcp, tcpcong pro moduly kontrolující zahlcení a udp), čímž z globálního jmenného prostoru odstraňuje asi 30 symbolů.

Řada vývojářů tento patch přivítala, protože v něm vidí krok vpřed ve snaze o racionalizaci API natahovatelných modulů. Je to také bráno jako způsob, jak externím modulům zamezit používání symbolů, které by používat neměly. Kromě toho se tím snižuje počet rozhraní, která musí být udržována stabilní v situacích, kde nejsou změny přípustné (například u enterprise jader). A konečně, jmenné prostory symbolů umožňují trochu exporty organizovat a dokumentovat, kdo je má používat.

Ne všichni však souhlasí. Především Rusty Russell má obavy, že patch věci zbytečně komplikuje a ztíží práci vývojářům externích modulů. Rusty:

Například když dáváš všechny udp funkce do jmenného prostoru "udp", co nám to přinese? Co bude jednodušší spravovat? Všechny ty funkce začínají na "udp_": dělá snad lidem potíže uhádnout, k čemu jsou určené?

Pokud chceš opravdu omezit "veřejná rozhraní", pak by bylo mnohem jednodušší přímo říct, co smějí externí moduly používat.

Herbert Xu to vidí podobně:

Ty symboly jsou exportovány proto, že je potřebují protokoly. Kdyby nebyly každému přístupné, bylo by těžké začít s psaním novým protokolů...

Takže přinejmenším s ohledem na ten síťový kód začínám spíš souhlasit s Rustym: je-li symbol využíván více než jedním modulem z jádra, je dost pravděpodobné, že budeme chtít, aby byl exportován pro všechny.

Ačkoliv se zdá, že tyto hlasy jsou v menšině, mají docela velkou váhu. Nechce se mi tedy hádat, jestli bude patch začleněn, a pokud ano, tak v jaké podobě. Dříve nebo později se však něco v této oblasti stane, protože snaha o pročištění modulárního API jen tak nezmizí.

kmemcheck - kontrola neinicializované paměti

link

Používání neinicializované paměti může vést k opravdu nepříjemným chybám. Když máte štěstí, tak jádro slítne a v tracebacku nechá rozluštitelnou stopu, která zaneřádila slab [slab poisoning] (0x5a5a5a5a nebo něco podobného). Jindy se však stane nějaká zakuklenější nepravost a budete nuceni dlouho hledat jednu hloupou chybu. Nebylo by lepší, kdyby jádro prostě umělo detekovat odkazy na neinicializovanou paměť a nahlas v tu chvíle zařvat?

Patch kmemcheck, který nedávno poslal Vegard Nossum, nabízí právě to - i když možná trochu těžkopádným způsobem. Jádro se zapnutou funkcí kmemcheck nebude asi vhodné pro produkční nasazení, ale mělo by dobře umět hledat paměť, která ještě nebyla nastavena na užitečnou hodnotu.

Kmemcheck je poměrně jednoduchý patch; používá následující přístup:

  • Každá alokace paměti je zachycena na úrovni alokátoru stránek. Pro každou alokaci je požadovaný řád navýšen o jeden, což velikost alokace zdvojnásobí. Dodatečné ("stínové") stránky jsou inicializovány nulami a drženy schované.

  • Alokovaná paměť je vrácena volajícímu, ale bit "present" [přítomna] je v tabulkách stránek smazán. Každý pokus o přístup k takové paměti tedy způsobí výpadek stránky.

  • Jakmile dojde k výpadku, kmemcheck (pomocí nechutného kódu specifického pro jednotlivé architektury) zjistí přesnou adresu a velikost zkoušeného přístupu. Jde-li o zápis, budou odpovídající bajty ve stínové stránce nastaveny na 0xff a operaci bude povoleno dokončit.

  • Pro přístupy kvůli čtení jsou otestovány odpovídající bajty stínových stránek; jsou-li některé z nich nula, kód usoudí, že jde o snahu přečíst neinicializovaná data. Pak je vypsán traceback stacku, aby se přišlo na to, kde k tomu přístupu dochází.

Je zřejmé, že provozování kmemcheck bude mít negativní vliv na výkon. Výpadek stránky při každém přístupu do paměti slabu prostě nemůže být rychlý. Zdvojnásobení velikosti každé alokace si také vezme svoje, včetně vlivu na keš, která bude muset pracovat s dvakrát tak velkým množstvím paměti. Ale když běží jádro v debugovacím režimu, tak se to dá vydržet.

Vegard poslal ukázkový výstup, který ukazuje, jak systém reaguje na čtení z neinicializované paměti. Dá-li se tomu výstupu věřit, tak přistupování k neinicializované paměti není v současných jádrech nic exotického. Pokud se ukáže, že některé z odkazů, na které teď bylo upozorněno, jsou opravdu chyby, tak už se kmemcheck osvědčil, i kdyby si nikdy nenašel cestu do hlavního jádra.

Aktualizace systémových volání

link

indirect()

link

Když se minulý týden diskutovalo o navrhovaném systémovém volání indirect(), stěžovali si někteří vývojáři, že je to opravdu nepěkné rozhraní. Od té doby se diskuze přenesla na rozhraní systémových volání obecně, ale moc nápadů, jak vylepšit indirect(), z toho nevzešlo.

Zatím vede alternativa, kterou navrhoval H. Peter Anvin: raději než k rozšiřování systémového volání používat indirect(), to je lepší prostě vytvořit nové volání s požadovanými parametry. Pak může být většinou stará implementace nahrazena jednoduchým kouskem kódu, který volá novou verzi s výchozími hodnotami u nových parametrů. Je to jednoduchý přístup, který snadno zachovává binární kompatibilitu, aniž by měl za běhu velkou režii. Protože čísel systémových volání je dostatek, mohlo by se takto postupovat ještě dlouho.

Správa zvyšujícího se počtu systémových volání však něco stojí; každé z těch systémových volání je součástí uživatelského API, které už musí fungovat navždy. indirect() nová systémová volání nepřidává. Za předpokladu, že budou parametry přidávány opatrně (s výchozími hodnotami nula), pak by mělo být celkem snadné se vyhnout potížím s API.

Existují však omezení toho, kolik parametrů lze k systémovým voláním přidat; na většině systémů se to pohybuje kolem šesti. Pokud chce nějaké systémové volání více parametrů, musí se pouštět do nepříjemností s nepřímými bloky. Vytváření nových systémových volání s dodatečnými parametry zvýší počet případů, ve kterých bude toto nepřímé zpracování parametrů potřeba. Takže přístup využívaný voláním indirect() bude nakonec stejně v nějaké podobě nasazován.

Klíčovým argumentem je však stále mechanismus sysletů/threadletů. Možnost udělat z kteréhokoliv volání asynchronní volání je velmi lákavá, ale aby to šlo provést, jsou potřeba ještě nějaké další informace - přinejmenším místo, kam výsledek volání uložit. Asynchronní systémová volání v Linuxu jsou, z praktického hlediska, druh nepřímého volání. Navrhované rozhraní indirect() vypadá, že by mohlo být pro asynchronní volání dobře využito - i když přesné API ještě nebylo stanoveno.

V důsledku toho je pravděpodobné, že se indirect() v nějaké podobě nakonec do jádra dostane - přesto je však ještě dost času na to, aby někdo přišel s lepším nápadem.

timerfd()

link

Když se tu naposled mluvilo o timerfd(), bylo právě vypnuto v jádře 2.6.23 kvůli stížnostem na své rozhraní. Od té doby se toho moc nestalo, takže téměř určitě nebude ani v 2.6.24. Přesto se však na tomto systémovém volání pracovalo a byl představen návrh nového API. Tato verze má tři systémová volání, z nichž první je timerfd_create():

    int timerfd_create(int clockid, int flags);

Parametr clockid systému říká, které hodiny se mají použít: CLOCK_MONOTONIC nebo CLOCK_REALTIME. Parametr flags byl přidán nedávno; v současné době se však nepoužívá a musí být nula. Je tam kvůli předpokladu, že někdo někdy bude chtít chování nějak upravit, takže je lepší se vyhnout potřebě nepřímé verze, dokud to jde. Návratová hodnota z timerfd_create() je popisovač souboru, který je možné předat funkci read() nebo kterékoliv variantě poll(). Nejprve by však měl být časovač asi naprogramován pomocí:

    int timerfd_settime(int fd, 
                        int flags,
		        const struct itimerspec *timer,
		    	struct itimerspec *old_timer);

fd je popisovač souboru získaný z timerfd_create(). Je-li časovač nastaven na absolutní čas, pak flags obsahuje TFD_TIMER_ABSTIME. A timer je doba vypršení časovače. Pokud old_timer není NULL, tak bude umístění, na které je ukazováno, nastaveno na předchozí hodnotu časovače.

Hodnotu časovače je také možné získat pomocí:

    int timerfd_gettime(int fd, struct itimerspec *timer);

Hodnota vrácená v *timer bude aktuální nastavení časovače přiřazeného k fd.

Tato nová verze API nebyla moc komentována, takže bude asi začleněno něco podobného. Normálně už by bylo příliš pozdě na přidání změny do 2.6.24, ale log patchů v 2.6.24-rc3-mm2 říká "Asi 2.6.24?". Takže jeden nikdy neví. Pokud to nebude začleněno brzy, skoro určitě se to dostane do 2.6.25.

hijack()

link

Systémové volání hijack() je i nadále vyvíjeno v rámci relativně tichých konferencí jaderných subsystémů. Toto volání se chová podobně jako clone() v tom smyslu, že vytvoří nový proces. Na rozdíl od clone() však hijack() způsobí, že nový proces sdílí zdroje s určeným třetím procesem, místo s předkem. Existuje hlavně proto, aby bylo snadné vstupovat do různých jmenných prostorů.

Rozhraní hijack() je skoro beze změny:

    int hijack(unsigned long clone_flags, int which, int id);

Zadaná hodnota id je interpretována podle which, který má tři možné hodnoty:

  • HIJACK_PID říká, že id je ID procesu; nově vytvořený proces bude sdílet zdroje (včetně jmenných prostorů) s určeným procesem.

  • HIJACK_CG říká, že id je otevřený popisovač souboru tasks v cílové kontrolní skupině. V takovém případě jádro vyhledá proces v určené kontrolní skupině a ten je použit pro sdílení zdrojů a jmenných prostorů.

  • HIJACK_NS je nejnovější možnost; podobně jako u HIJACK_CG jde o otevřený popisovač souboru označující kontrolní skupinu. V tomto případě však nový proces zdědí pouze danou kontrolní skupinu a přiřazené jmenné prostory. Tato verze je určena pro vstup do prázdné kontrolní skupiny (když tam nejsou žádné procesy, po kterých dědit).

Toto nové systémové volání vůbec nebylo představeno na linux-kernel; je dost možné, že v současné podobě tam svůj první výstup nepřežije. Přinejmenším bude asi požadována změna názvu (na něco trochu více popisného, co by, pokud možno, nezpůsobilo, že se uživatelé objeví na seznamu podezřelých osob výzvědných služeb). Je však zřejmé, že plná implementace kontejnerů v Linuxu bude jednou potřebovat nějaké systémové volání enter_container().

       

Hodnocení: 100 %

        špatnédobré        

Nástroje: Tisk bez diskuse

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

28.12.2007 11:04 M.
Rozbalit Rozbalit vše Re: Jaderné noviny - 28. 11. 2007
Linuxové jádro by potřebovalo, aby každou změnu doprovázela dokumentace -- část patche by vždy měla mířit do adresáře Documentation/. To jim to trvalo, než na to přišli :-D
Jakub Lucký avatar 28.12.2007 19:27 Jakub Lucký | skóre: 40 | Praha
Rozbalit Rozbalit vše Re: Jaderné noviny - 28. 11. 2007
Andrew Morton to odstranění popisuje jako fikaný způsob, jak zúžit počet testerů, abychom nedostávali tolik hlášení o chybách.
Andrew ví, že se neustále Linux a Windows porovnávají podle počtu bugů... A chce to vyřešit po svém ;-)
If you understand, things are just as they are; if you do not understand, things are just as they are. (Zen P.) Blogísek
28.12.2007 20:19 Andrei Badea | skóre: 5 | Praha
Rozbalit Rozbalit vše Re: Jaderné noviny - 28. 11. 2007
Překlad toho citátu mi nějak nesedí. Originál zní:
The Linux kernel requires that any needed documentation accompany all changes requiring said documentation -- part of the source-code patch must apply to the Documentation/ directory.
Což se IMHO dá přeložit spíše jako:
Linuxové jádro vyžaduje, aby každý patch, který je potřeba zdokumentovat, tu dokumentaci rovnou obsahoval -- část patche musí měnit adrešář Documentation".
Heureux qui, comme Ulysse, a fait un beau voyage.
30.12.2007 15:32 fsckya
Rozbalit Rozbalit vše Re: Jaderné noviny - 28. 11. 2007
no ja zasnu, zda se, ze ani po novem roce neupgraduji svuj 2.6.22.9 kernel, ty novejsi verze jsou ponekud mne iritujici, zamerne z nich jsou odstraneny symboly, cimz je nasledne zpusobena nefunkcnost nejpouzivanejsich proprietarnich modulu. Andrew Morton je mamrd !
stativ avatar 31.12.2007 18:36 stativ | skóre: 54 | blog: SlaNé roury
Rozbalit Rozbalit vše Re: Jaderné noviny - 28. 11. 2007
Řekl bych, že to spíš mělo být tvůrci proprietárních modulů jsou mamrdi.
Ať sežeru elfa i s chlupama!!! stativ.kx.cz

Založit nové vláknoNahoru

ISSN 1214-1267   Powered by Hosting 90 Server hosting
© 1999-2013 Argonit s. r. o. Všechna práva vyhrazena.