15.10.2009 09:47
Karry | skóre: 10
Rozbalit Rozbalit vše Re: Jaderné noviny – 23. 9. 2009
Portál AbcLinuxu, 6. května 2025 07:19
Aktuální verze jádra: 2.6.31. Citáty týdne: Linus Torvalds, Andrew Morton, Stephen Hemminger. AppArmor: Je zpááááátky. Vydán SystemTap 1.0. Devtmpfs a práva. Konec paravirt_ops? Začleňovací okno 2.6.32, část druhá. Nový sloupek: Ptejte se jaderného vývojáře.
Začleňovací okno 2.6.32 je stále otevřené, v době psaní tohoto článku tedy není žádná vývojová verze jádra 2.6. Vydání 2.6.32-rc1 (a uzavření začleňovacího okna) lze očekávat 24. září.
Současné stabilní jádro je 2.6.31; během minulého týdne nevyšly žádné stabilní aktualizace; je revidována série aktualizací, ale v době psaní tohoto článku ještě nebyla vydána.
-- Linus Torvalds o netlinku.
-- Andrew Morton o zpětném zápisu podle BDI.
-extern void refrigerator(void); +extern void refrigerator(void) __cold;
-- Stephen Hemminger o správném mrazení.
Bezpečnostní modul AppArmor měl těžký život – a to i když uvážíme, že bezpečnostní moduly obecně mívají těžkou cestu do hlavní řady. Jeho přístup založený na cestách [pathname] vyvolal obavy u mnoha vývojářů a implementace způsobila, že se ze všech koutů sítě ozývalo NACK. Nakonec hlavní vývojáři přišli o práci, distributoři ztratili zájem a AppArmor se ztratil z dohledu. Mezitím modul TOMOYO Linux překonal překážky a do hlavní řady se dostal.
Při své řeči na LinuxCon autor článku prohlásil, že neví, jestli se AppArmor vrátí, nebo ne. O den později John Johansen zaslal novou sadu patchů AppArmor. Co je zajímavé, John pracuje v Canonicalu, takže AppArmor, pokud se dostane do hlavní řady, by se mohl stát jedním z největších příspěvků této firmy do jádra. Jeho šance na začlenění by nyní měly být lepší; TOMOYO Linux rozbil bariéry pro povinné kontroly přístupu založené na cestách a AppArmor používá nové háčky pro bezpečnostní moduly, které byly přidány pro TOMOYO. V době psaní tohoto článku nicméně nebyla zaslána žádná hodnocení, takže se stále může stát cokoliv.
Tým SystemTap oznámil vydání SystemTap 1.0; SystemTap je dynamický sledovací nástroj pro Linux. Autor článku neví, čím si toto konkrétní vydání vysloužilo označení 1.0, ale nových věcí je v něm hodně, včetně experimentální podpory pro neprivilegované uživatele, křížový překlad pro jiné architektury, propojení třídy C++ a rozsahu jmenného prostoru, omezení spotřeby paměti za běhu, omezení režie ve značkách v uživatelském prostoru, opravy chyb a další… Více informací vizte v oznámení.
Někteří vývojáři nejsou šťastni z toho, že do 2.6.32 bylo začleněno devtmpfs; jeden dokonce zaslal patch, který ho zase odstraňuje. Ingo Molnár místo toho jednoduše nahlásil chybu: Když devtmpfs vytvořil /dev/null a /dev/zero, znepřístupnil je neprivilegovaným účtům. To rozbíjí většinu aplikací v systému, což podle Inga není zcela žádoucí.
Vývojáři devtmpfs původně zareagovali tím, že v době, kdy by mohla běžet nějaká aplikace v uživatelském prostoru, by měl práva správně nastavit udev, nicméně devtmpfs nabízí možnost se přinejmenším na relativně jednoduchých systémech používání udev vyhnout. Linus souhlasil, že to by byla zajímavá možnost, ale poznamenal, že to nebude fungovat, pokud několik speciálních souborů nebude globálně přístupných. Nastavit práva správně není tak těžké, ale vede to směrem, kterým se vývojáři devtmpfs nechtěli dát: Směrem ke vkládání určitého objemu administrativních politik do jádra.
Nakonec se nicméně stalo přesně to; devtmpfs získal možnost dotázat se jaderných subsystémů na výchozí práva a ta nastavit. Vzhledem k tomu, že práva byla Linusovou největší stížností o celé této věci, zdá se nyní pravděpodobné, že devtmpfs má v jádře 2.6.32 bezpečné místo.
Mechanismus paravirt_ops poskytuje linuxovému jádru možnost efektivně se zaháčkovat do hypervizoru kvůli privilegovaným operacím, když běží ve virtualizovaném režimu. Postupem času se v procesorech objevily vlastnosti zaměřené na podporu virtualizace, nicméně stále bylo možné těžit z implementace některých operací pomocí paravirt_ops. Tato situace se ale, zdá se, mění.
VMI je paravirtualizační vrstva VMWare vytvořená nad paravirt_ops. Vývojáři ve VMWare nedávno zkusili sadu testů a došli k zajímavému závěru: Na současných systémech VMI výkonnost hostitelských systémů nezlepšilo – právě naopak, výkonnost se zhoršila. V blízké budoucnosti by měla být rozumná hardwarová virtualizace dostupná na téměř všech systémech, na kterých záleží, takže se vývojáři VMWare rozhodli, že VMI již nedává smysl; plánuji ji odstranit.
Vývojář KVM Avi Kiviti poznamenal, že v jeho táboře došli ke stejnému závěru; KVM se bude v blízké budoucnosti zbavovat podpory pro některé paravirtualizované operace. To nám ponechává dva další systémy – Xen a lguest – které paravirt_ops používají. Xen, jak se zdá, to tak bude dělat i nadále a lguest s vysokou pravděpodobností nikdy neobětuje dost štěňátek na to, aby mohlo začít hardwarovou virtualizaci používat. paravirt_ops tedy ještě malou chvíli zůstanou, ale jejich eventuální odchod je na obzoru. Až zmizí, dost možná vezmou lguest s sebou.
Od článku z minulého týdne bylo do hlavní řady pro vývojový cyklus 2.6.32 začleněno nějakých 3300 sad změn. Celkový počet neslučovacích sad změn mířících do 2.6.32 je nyní těsně přes 7800 – poměrně dost, ale rekord to ještě není.
Mezi změny viditelné pro uživatele patří:
Nyní jsou k dispozici další dvoje systémové hodiny: CLOCK_REALTIME_COARSE a CLOCK_MONOTONIC_COARSE. Jsou zaměřeny na aplikace, které potřebují získávat časové značky s minimálními náklady a přitom jsou ochotny obětovat rozlišení.
Nyní je podporována architektura Sunplus S+core.
Kód pro sledování výkonnosti získal nové schopnosti pro zaznamenávání a analýzu informací o latencích plánovače. Je zde nový nástroj pro sledování událostí změny stavu správy napájení. Také proběhla změna značky, z „čítačů výkonnosti“ se staly „události výkonnosti“.
Byl začleněn nástroj timechart Arjana van de Vena. Timechart zaznamenává události v systému způsobem, který uživatelům umožňuje přiblížit si specifická období a získat tak čím dál detailnější informace o tom, kde v systému vzniká zpoždění.
Ovladač grafických karet i915 nyní podporuje dynamické řízení frekvence hodin. Tato vlastnost umožňuje snížit frekvenci hodin, když na grafické kartě probíhá malá nebo žádná aktivita, čímž se sníží spotřeba.
Kód Radeon pro jaderné nastavování režimu (KMS) se stále vyvíjí rychlým tempem a je v něm podporováno čím dál tím více vlastností. Nyní je KMS podporováno i pro sérii R600.
Do virtuálních souborů, jako je /proc/meminfo, bylo přidáno mnoho nových informací se záměrem pomoci správcům vysledovat uživatele paměti v situacích, kdy paměť dochází.
Subsystém jádrem sdílené paměti [kernel shared memory, KSM] byl začleněn. KSM prohledává stránky v paměti a hledá stránky se stejným obsahem. Duplicitní stránky jsou nahrazeny odkazy s kopírováním při zápisu, což vede na významné omezení spotřeby paměti.
Změny governoru cpuidle popsané v článku Lepší ovládání cpuidle byly začleněny.
Vrstva Video4Linux nyní zná vysílací standardy ISDB-T a ISDB-S, což zpřístupňuje digitální TV v Japonsku a Brazílii.
V /proc lze nyní nalézt rozšířené informace o využívání zásobníku vlákny.
Souborový systém ocfs2 získal podporu pro referenční odkazy [reflink], ale bez systémového volání reflink() (bude přepracováno).
Ze souborového systému qnx4 byla odstraněna podpora pro zápis; to pravděpodobně bude vadit jenom málo uživatelům, protože stejně nikdy skutečně nefungovala.
Obvyklá hromádka nových ovladačů:
Desky a procesory:
Grafika:
Blokové: 64bitové čtyřkanálové UDMA133 ATA řadiče ARTOP 867X
USB:
Video4Linux:
Různé:
Mezi změny viditelné pro vývojáře jádra patří:
Kód architektury x86 byl dostatečně reorganizován, takže bylo možné přidat podporu pro architekturu Intel „Moorestown“.
Vnitřní API ovladačů bylo rozšířeno, aby se subsystémům umožnilo poskytnout ne-výchozí oprávnění pro uzly zařízení vytvářené v devtmpfs.
(Nyní) nepoužívaný mechanismus jaderných značek [kernel markers] byl odstraněn; místo nich by se měly používat sledovací body.
API pro USB ovladač v uživatelském prostoru nyní ovladačům umožňuje zabrat si specifické porty hubu.
Jsou k dispozici nové sledovací body pro alokace stránek v paměti a jejich uvolňování a události časovače a časovače s vysokým rozlišením.
Začleňovací okno by se obvykle blížilo svému konci; je však možné, že ho Linus trochu rozšíří, aby se nahradil čas, který strávil na LinuxCon a Linux Plumbers conference.
[Poznámka redaktora: Greg Kroah-Hartman ochotně souhlasil, že pro LWN příležitostně napíše sloupek, ve kterém bude zodpovídat otázky, které by čtenáři chtěli položit jaderné vývojové komunitě. Greg odvede skvělou práci, ale klíčem k úspěchu jsou zde dobré otázky; prosím, vymyslete co nejlepší a já je pošlu.]
Ahoj a vítejte u nového polotýdenního sloupku. Zde se budeme snažit zodpovědět vaše časté otázky o vývoji linuxového jádra. Tento sloupek bude spoléhat na čtenáře, že budou zasílat otázky k zodpovězení buď sem v komentářích nebo e-mailem na greg@kroah.com s pochopením, že ne na všechny lze odpovědět.
Platná témata jsou v rozsahu od technických po procedurálních otázky nebo směrem k čemukoliv, co je vzdáleně spojené s linuxovým jádrem a co vás napadne.
Abych začal, poskytl jsem pár „počátečních“ otázek, na které jsem často tázán a rád bych na ně tedy odpověděl najednou, abych to nemusel dělat znovu.
Stabilní série linuxového jádra se snaží spravovat jenom jeden jaderný strom naráz, ten nejnovější s malým přesahem jednoho nebo dvou vydání, když vyjde nové jádro. V současnosti, kdy bylo právě vydáno jádro 2.6.31, jsou aktualizovány jak stromy .31, tak .30. Po dalším vydání stromu .30 bude tento opuštěn a aktualizován bude pouze strom .31.
Některé jaderné stromy jsou ale trochu „zvláštní“. Jádro 2.6.27 vypadalo jako dobré jádro pro delší údržbu. Někteří uživatelé nahlásili, že by rádi zůstali u jedné verze jádra déle než 3-4 měsíce, takže jaderný strom 2.6.27 se bude pokoušet být tím stromem, u kterého se lze spolehnout na to, že se do něj budou dostávat bezpečnostní opravy i opravy chyb po delší dobu. Vzhledem k tomu, že bylo jádro 2.6.27 vydáno 9. října 2008, je podporováno již téměř rok.
Až budu unaven údržbou této větve, Adrian Bunk se nabídl, že ji bude udržovat ještě déle, takže během přibližně roku přejde správa na něj a tato verze bude žít dál.
Nejprve se podívejte na Documentation/stable_kernel_rules.txt a ověřte si, že patch, který zvažujete, splňuje pravidla pro stabilní vydání jádra. Pokud ano, nejjednodušší způsob, jak ho nechat začlenit, je přidat řádek:
Cc: stable <stable@kernel.org>
do oblasti Signed-off-by: patche předtím, než ho pošlete správci subsystému. Když je patch s touto řádkou začleněn do Linusova jaderného stromu, stabilní tým je automaticky upozorněn, že tento patch by měl být začleněn, a oni ho zařadí do fronty k příštímu vydání jádra.
Pokud si všimnete patche, o kterém si myslíte, že by měl patřit do stabilního vydání, ale tuto značku nemá a v Linusově stromě již je, jednoduše napište e-mail na stable@kernel.org a uveďte id commitu patche v Linusově stromě a krátký popis toho, do které stabilní verze jádra by měl podle vás být začleněn. To je vše, co je potřeba.
Tak sem s otázkami!
cp /etc/shadow /etc/shadow.bak .. cp /etc/shadow.bak /etc/shadowa jste v ... - novy shadow soubor nema spravne extended atributy.
Co je na nich tak zlého? Vždyť se používají všude.Prave to je na nich zle - su vsemocnym mechanizmom ako zasahovat do vsetkeho mozneho, a to bez spolocneho dizajnu, zjavnej semantiky a cohokolvek co by sa dalo nazvat navrhnutym rozhranim. Same o sebe povodne vznikli len ako workaround, ktory metastazoval do celeho kernelu.
su vsemocnym mechanizmom ako zasahovat do vsetkeho moznehobezesporu... Koukni na tento kousek:
unsigned long int value; fd = syscall(SYS_open, devf, O_RDONLY); ioctl(fd,VIDIOC_G_CTRL,&value); close(fd);Je to kus kódu z použití V4L API. Přijde ti tohle špatně navržené? Jak tohle udělat lépe, aby se pokud možno zachovala jednoduchost?
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.