![[Výstup top]](http://www.lwn.net/images/2011/group-sched-top.png)
Portál AbcLinuxu, 23. dubna 2024 15:37
Aktuální verze jádra: 2.6.38. Citáty týdne: Linus Torvalds, Steven Rostedt, Hugh Dickins. Demonstrace skupinového plánování. Začleňovací okno 2.6.39, část první. API pro senzory. PostgreSQL, OpenSSL a GPL.
Jádro 2.6.38 je venku vydáno bylo 14. března. Když se na něj podíváme zeširoka, tj. na všechny změny od 2.6.37, mým osobním favoritem zůstávají změny ve vyhledávání jmen ve VFS. Způsobily nějaké problémy a Al dal jasně najevo, že chce další pročištění, ale dohromady bych řekl, že byly relativně bezproblémové. Mezi další významné změny v 2.6.38 patří podpora transparentních velkých stránek [transparent hugepages], skupinové plánování podle sezení, mnoho zlepšení Btrfs a další. Jako vždy excelentní stránka na KernelNewbies.org obsahuje všechny detaily.
Stabilní aktualizace: 14. března vyšly aktualizace 2.6.37.4 a 2.6.32.33.
-- Hugh Dickins
napsal Jonathan Corbet, 16. března 2011
O patchi skupinového plánování podle sezení a jeho zařazení do jádra 2.6.38 se diskutovalo hodně, ale je těžké vidět ho v akci, když neděláte překlad jádra v dvaceti procesech. Nedávno se nicméně autorovi tohoto článku podařilo takovou demonstraci vytvořit díky neočekávaným výsledkům upgrade Rawhide. Způsob, jakým plánovač pracuje, je možné vidět z toho, co v danou chvíli bylo možné zachytit.
Uživatelé Rawhide ví, že za neškodně vypadajícím příkazem yum upgrade se často skrývají překvapení. V tomto případě něco během aktualizace (pravděpodobně spojené s fonty) způsobilo, že se všechny grafické procesy v systému rozhodly, že je čas začít pracovat na něčem náročném. Výsledek je vidět ve výstupu příkazu top:
Heuristika řadící podle sezení většinu procesů vložila do jediné řídící skupiny, takže většinu času soupeřily o čas CPU mezi sebou. Tyto procesy ve chvíli zachycené na obrázku mají k dispozici přibližně 5,3 % z dostupného času CPU. Dva procesy, které v této řídící skupině nebyly, soupeřily o druhé jádro v systému; každý dostal 46 %. Celková zátěž systému byla téměř 22 a desktop vůbec nereagoval. Bylo ale možné se do systému přihlásit po síti a situaci prozkoumat, aniž by byla zátěž nějak znát.
Izolace je jednou z nejhezčích vlastností skupinového plánování; i když se velký počet procesů totálně zblázní, jejich schopnost ničit život ostatním procesům na daném stroji je omezená. To samo o sobě ospravedlňuje náklady na tuto vlastnost.
napsal Jonathan Corbet, 16. března 2011
Linus vydal jádro 2.6.38 14. března a následující den začal začleňovat patche do vývojového cyklu 2.6.39. V době psaní tohoto článku bylo do hlavní řady začleněno něco přes 1000 patchů. Proces začleňování zjevně teprve začal, ale přidáno bylo již několik zajímavých vlastností. Mezi ty viditelné pro uživatele patří:
Systémová volání pro otevření podle manipulátoru [open by handle] byla začleněna. Konečná podoba API je:
int name_to_handle_at(int dfd, const char *name, struct file_handle *handle,
int *mnt_id, int flag);
int open_by_handle_at(int dirfd, struct file_handle *handle, int flags);
Tuto funkcionalitu mají používat souborové servery v uživatelském prostoru, které pomocí manipulátorů mohou efektivněji sledovat soubory.
Systémové volání open() má nový příznak O_PATH. Cesta k souboru otevřenému s tímto příznakem byla ověřena jádrem a soubor existuje, ale nelze s ním dělat nic moc jiného. Systémová volání, která pracují přímo s popisovačem souboru (např. close() nebo dup()), budou fungovat; popisovače bude také možné předat jinému procesu přes Unix sockety, které používají datagramy SCM_RIGHTS. Důvodem pro existenci popisovačů O_PATH je možnost použít je jako popisovač pro adresáře v různých voláních *at().
Úlohy v třídě SCHED_IDLE se nyní mohou povýšit na SCHED_BATCH či SCHED_OTHER, pokud jim to umožní jejich „nice“ rlimit.
Přibylo systémové volání, které umožní nastavit POSIX hodiny:
int clock_adjtime(clock_id which_clock, struct timex *time);
Možnosti, jak upravit čas, jsou stejné jako u adjtimex(), ale specifické POSIX hodiny nemusí všechny operace podporovat.
Byly přidány POSIXové hodiny CLOCK_BOOTTIME
Nový atribut SMACK64MMAP řídí, kdy mohou být běžícími programy mapovány specifické knihovny.
Mezi změny viditelné pro jaderné vývojáře patří:
Nový příznak přerušení (IRQF_FORCE_RESUME), který vynutí povolení přerušení během probouzení bez ohledu na to, jestli bylo během uspávání vypnuto.
Jádro nyní může vynutit běh (téměř) všech obsluh přerušení ve vláknech; tato možnost se řídí parametrem threadirqs na příkazové řádce jádra. Je to užitečné pro ladění, protože když spadne obsluha přerušení ve vlákně, způsobí to pouze oops jádra místo kompletního pádu systému. Obsluhy přerušení, které by nikdy neměly být nuceny běžet ve vláknech, lze označit IRQF_NO_THREAD, ale očekává se, že to bude ojedinělé.
Ladící infrastruktura pro objekty nyní umožňuje specifikovat funkci pro „nápovědu k ladění“; ta vrací adresu, kterou je možné použít k lepší identifikaci specifického objektu. Detaily vizte v tomto commitu.
Dlouho zastaralé inicializátory zámků SPIN_LOCK_UNLOCKED a RW_LOCK_UNLOCKED byly odstraněny.
Subsystém událostí výkonnosti má nový monitorovací režim, ve kterém sleduje pouze procesy patřící do specifické řídící skupiny. K této funkci poskytuje přístup přepínač -G programu perf.
Do férového plánovače bylo přidáno přímé předání; tato vlastnost by měla vylepšit výkonnost hostů virtualizovaných pomocí KVM.
Nový mechanismus pro přidávání POSIXových hodin; vizte <linux/posix_clock.h>, kde najdete detaily o rozhraní.
Architektura x86 získala minimální podporu pro strom zařízení [device tree].
Vznikla nová globální pracovní fronta system_freezable_wq; od ostatních se liší tím, že je možné ji během uspávání zmrazit.
Vnitřní subsystémy mohou použít nový mechanismus syscore_ops a zaregistrovat si zpětná volání [callback] pro správu napájení, aniž by bylo nutné vytvářet systémová zařízení, která k ničemu jinému neslouží.
Pokud budou platit obvyklá pravidla, lze konec začleňovacího okna 2.6.39 čekat někdy kolem 29. března a finální vydání 2.6.39 někdy první týden v červnu.
napsal Jonathan Corbet, 16. března 2011
Senzory prostředí byly kdysi dávno výbavou, kterou bylo možné najít pouze ve specializovaných zařízeních pro řízení průmyslových procesů nebo ve výzkumu. Byly drahé a vyladěné ke specifickému úkolu. Čím dál tím více je ale můžeme najít ve všem možném. Mobilní handsety mají kompasy, akcelerometry a další. Senzory teploty, tlaku atd. jsou také častější a častější. Důsledek pobaví: z jakéhokoliv linuxového stroje se může stát přenosné zařízení pro sběr dat.
Jediný problém je v tom, že jádro ještě nemá zavedené žádné API – ani interní, ani pro uživatelský prostor – pro senzory. Jsou v něm rozhraní pro specifické typy senzorů; Video4Linux2 se například zabývá kamerami a subsystém hwmon zase senzory, které monitorují stav samotného počítače. V těchto oblastech jsou rozhraní zavedena dobře a je možná spolupráce. Pro senzory mimo tyto oblasti nicméně žádná pravidla neplatí. Výsledkem této situace je jako vždy to, že nová zařízení se přidávají bez konzistentních rozhraní, což ztěžuje život vývojářům aplikací.
Tato situace se (opět) projevila s nedávným zasláním ovladače pro senzor tlaku, který byl implementován jako jiné (misc) zařízení. Pro své rozhraní používal vstupní [input] subsystém; Jonathan Cameron, který pracuje na rozhraních pro senzory, upozornil na to, že v této podobě patch přijat nebude. Vstupní zařízení mají přijímat vstup od člověka; vzhledem k tomu, že většina lidí se svým počítačem nekomunikuje pomocí změn atmosférického tlaku prostředí, do této skupiny se senzor tlaku nehodí. Ovladač tedy potřebuje jiný domov. Navržen byl subsystém hwmon, ale senzor tlaku nemonitoruje hardware, takže tam ten ovladač také nebude vítán. A Arndu Bergmannovi se nelíbí používání misc rozhraní:
Tím zůstává subsystém pro průmyslové I/O [industrial I/O, IIO], kam patří „zařízení, která jsou v určitém smyslu A/D převodníky.“. IIO se snaží standardizovaným způsobem zvládnout široký záběr senzorů s podporou pro události, I/O s velkým průtokem dat a další. V IIO subsystému je poměrně hodně ovladačů; jediný problém je, že to všechno sedí ve stromě staging a seznam „TODO“ položek s tím spojený je poměrně dlouhý. Zařízení, která jsou tam zastoupena, nejsou, co se používání rozhraní týče, úplně konzistentní – a podoba žádaného rozhraní také není nijak jasná.
I tak je ale Jonathanovým cílem takové rozhraní vytvořit:
K tomu Jonathan dodal, že rozhraní a podpora pro jednoduchá zařízení (ta, která předávají málo dat a mají sysfs rozhraní ve stylu hwmon) je v poměrně dobrém stavu. Otázka je, jak zajistit zbytek.
Jednou alternativou je definovat v podstatě nové IIO jádro, které by bylo začleněno do hlavní řady. Jednotlivé ovladače by potom byly vylepšeny a přesunuty pod něj, až by to bylo možné. Problém je, že to může trvat dlouho a verze ovladačů z hlavní řady by nemusely z počátku mít v porovnání s černými ovcemi ze stromu staging všechnu funkcionalitu. To by nějaký čas znamenalo víc práce s údržbou obou verzí ovladače.
I tak je to ale přístup, který Arnd doporučil. Přechod do hlavní řady je poslední dobrá šance, jak definovat rozhraní, které bude nutné podporovat několik let. Současné problémy, pokud se s nimi vypořádáme správně, tedy mohou ospravedlnit to, že si v budoucnu zjednodušíme život. Přesvědčit vývojáře na tento nápad přistoupit nicméně nemusí být úplně jednoduché; většina z nich tráví čas jinými věcmi než psaním ovladačů pro Linux a může jim tak chybět snaha přepsat kód kvůli novému rozhraní, když to současné funguje. I tak je to ale téměř jistě nejlepší cesta kupředu. A téměř určitě je správný čas na to, aby s vývojem verze IIO rozhraní pro hlavní řadu pomohli lidé, kteří mají v této oblasti své zájmy.
napsal Jake Edge, 16. února 2011
OpenSSL licencované pod licencí ve stylu BSD s dodatkem o propagaci, je dlouhodobě zdrojem problémů, protože není příliš jisté, jestli je možné ji zahrnout do kódu licencovaného pod GPL. Většina distribucí je podle všeho spokojena s tím, že lze OpenSSL považovat za „systémovou knihovnu“, takže její používání nevyžaduje licenci kompatibilní s GPL. Free Software Foundation (FSF) a Debian ale s touto interpretací nesouhlasí a záležitost s licencí se tak znovu objevila v mailové konferenci pgsql-hackers (vývoj PostgreSQL).
U programů orientovaných na příkazovou řádku je běžné používání knihovny GNU readline, která umožňuje různé způsoby práce s příkazovou řádkou. Readline je ale licencováno pod GPL (ne pod LGLP) a to znamená, že programy, které ji používají, musí být pod kompatibilní licencí, což PostgreSQL se svojí jakoby-BSD licencí rozhodně splňuje. Licence OpenSSL ale přidává pro uživatele dodatečná omezení a s GPL tedy kompatibilní není. Jestli to je skutečný problém nebo ne v praxi závisí na tom, jak interpretujete GPL a jestli se OpenSSL dá považovat za systémovou knihovnu a platí pro ni výjimka.
Debian se rozhodl pro nekompromisní postoj, který zjevně souhlasí s interpretací FSF, a místo readline začal používat knihovnu Editline (libedit) licencovanou pod BSD. PostgreSQL podporuje libedit jako alternativu k readline, takže přepnutí je jednoduché. Bohužel chyba v libeditu způsobuje, že uživatelé PostgreSQL v Debianu nemohou do psql zadávat vícebytové znaky, když používají Unicode locale.
Pro PostgreSQL je tohle problém typu „kámen a tvrdá skála“. Kód OpenSSL funguje dobře a je poměrně těsně – možná až moc – integrován. Jsou zde nicméně dvě zjevné alternativy – GnuTLS a Network Security Services (NSS) Mozilly. Přechod k jednomu z toho by problém s readline odstranilo, protože jejich licence problematickou část o propagaci nemají.
Snahy o přechod k GnuTLS u PostgreSQL tu byly, což ve svém shrnutí historie problému popsal Greg Smith; patch ale byl příliš rušivý a velký, takže nebyl přijat. K problému zde přispívá to, že psql je příliš těsně spojené s OpenSSL, což Martijn van Oosterhout, který podporu pro GnuTLS vyvinul, popsal následovně:
Dalším řešením by mohla být změna licence readline nebo OpenSSL, ale to není příliš pravděpodobné. Někdo dává do GPL kódu explicitní výjimku ohledně OpenSSL, ale nedá se příliš očekávat, že by FSF udělalo pro readline totéž – již dlouhou dobu považuje tuto knihovnu za způsob, jak dostat více projektů pod licenci kompatibilní s GPL. A OpenSSL je se svojí licencí buď spokojené, nebo ji nemůže změnit, na což v jednom vlákně upozornil Stephen Frost.
Robert Hass doporučil revidovat podporu GnuTLS v PostgreSQL 9.2, ale mezitím tu budou uživatelé Debianu, kteří nemohou snadno používat psql. A netýká se to jenom Debianu, protože Ubuntu převezme verzi PostgreSQL + libedit v příští verzi. To problém dále šíří, což podotkl i Joshua D. Drake, který celé zmiňované vlákno začal: Jakkoliv je Debian populární, populace 'uživatelů' je ve světě Ubuntu a to bude mít závažné důsledky, co se týče pohledu veřejnosti.
Místo GnuTLS by se dalo použít NSS, což by mělo jednu zásadní výhodu: certifikaci Federal Information Processing Standard (FIPS) 140-2. FIPS 140-2 je standard Spojených států pro šifrování a některé firmy a organizace jej vyžadují, když jde o software, který obsahuje šifrování. OpenSSL tento certifikát má, stejně tak NSS, ale GnuTLS ne. Z toho důvodu se mluví o tom, aby PostgreSQL místo GnuTLS podporovalo spíše NSS.
Projekt Fedora se na NSS dívá také, je to součást jejich snahy konsolidovat šifrovací knihovny, které používají. Z mnoha důvodů, mezi které patří certifikace FIPS a některé vlastnosti, které v GnuTLS chybí (hlavně S/MIME), se ve Fedoře rozhodli pro NSS. Můžeme hádat, že licence nekompatibilní s GPL hrála roli v tom, že OpenSSL bylo ze zvažování vyřazeno.
Na jednu stranu Fedora dodává různé nástroje s readline i OpenSSL, mezi ně patří i PostgreSQL. Zdá se, že Fedora (a dost možná právníci Red Hatu) spoléhá na to, že OpenSSL se distribuuje jako systémová knihovna, což technický manager Fedory Tom „spot“ Callaway řekl roku 2008 a zopakoval to roku 2009. Možná také (stejně jako jiní) spoléhají na to, že je téměř nulová pravděpodobnost, že by se FSF někdy vážně pokusilo zastavit distribuci PostgreSQL používající readline.
Pro Debian to ale není dostatečné. Další hlášení chyby obsahovalo delší diskuzi o problému a způsob, jak ho obejít, který objevil Andreas Barth:
LD_PRELOAD=/lib/libreadline.so.5 psql
Je to poměrně ošklivý hack a nikomu se moc nelíbí, ale plánuje se přidat LD_PRELOAD do wrapperu psql (pokud bude libreadline k dispozici), který se dodává v balíku postgresql-client-common. Martin Pitt to shrnul takto:
Tento střet licencí se objevuje s určitou pravidelností a o licenci OpenSSL se ví, že je problematická – přinejmenším pro projekty, které používají GPL kód. Požadavek na propagaci, což je atavismus z prvních dní licence BSD, způsobuje, že je OpenSSL čím dál tím více izolováno. Distribuce a další projekty budou pravděpodobně pokračovat v hledání alternativ – a budou je nalézat. A to i když to bude jenom kvůli omezení nejasností ohledně licencování a s tím spojených otázek vývojářů a uživatelů. Je nešťastné, že jeden nebo dva články v licenci sloužící k nafukování ega způsobí, že se knihovna bude o něco méně používat, ale – jako vždy – si svobodný software najde cestu, jak tyto problémy obejít a fungovat dál.
28.3.2011 02:16
Gilhad | skóre: 20
| blog: gilhadoviny
28.3.2011 19:34
David Watzke | skóre: 74
| blog: Blog...
| Praha
při pokusech o zotavení se program často dostával do oblastí, kdy sice běžel dál, ale v podstatě nefungoval správněTakže pokud tomu dobře rozumím, tak jsi místo řešení problému ten problém radši obešel...
4.4.2011 16:53
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
3.4.2011 22:28
Gilhad | skóre: 20
| blog: gilhadoviny
což PostgreSQL se svojí jakoby-BSD licencí rozhodne splňuje-> rozhodně
konzolidovat šifrovací knihovny-> konsolidovat
29.3.2011 17:58
Petr Tomášek | skóre: 39
| blog: Vejšplechty
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.