Jaderné noviny - 13. 6. 2007

9. 7. 2007 | Robert Krátký | Jaderné noviny | 5685×

Aktuální verze jádra: 2.6.22-rc4. Citáty týdne: Dave Jones, Paul Mackerras, Rusty Russell. Linus o GPLv3 a ZFS. První vydání ovladače pro ATI R500. Kdo napsal a schválil 2.6.22. Další zábava s popisovači souborů. Překládání dokumentace k jádru.

Obsah

• Aktuální verze jádra: 2.6.22-rc4
• Citáty týdne: Dave Jones, Paul Mackerras, Rusty Russell
• Linus o GPLv3 a ZFS
• První vydání ovladače pro ATI R500
• Kdo napsal a schválil 2.6.22
• Další zábava s popisovači souborů
• Překládání dokumentace k jádru

Aktuální verze jádra: 2.6.22-rc4

Aktuální předverze je (k 13. 6. 2007) i nadále 2.6.22-rc4. Do hlavního repozitáře proudí nové patche, většinou opravy; začleněn však byl i ZERO_SIZE_PTR patch pro SLUB alokátor.

Aktuální verze -mm stromu je 2.6.22-rc4-mm2. Změny z poslední doby jsou všechny zaměřeny na opravy chyb a stabilizaci.

Aktuální stabilní jádro řady 2.6 je 2.6.21.5, vydané 11. června; obsahuje dost dlouhý seznam oprav. 2.6.21.4 vyšlo 8. června a přineslo sadu bezpečnostních oprav: Oprava /dev/[u]random je důležitá zvláště pro systémy, které nemají žádný zdroj entropie (např. klávesnice, myš nebo disk) ani realtimové hodiny, protože po sobě jdoucí restarty by mohly z RNG [random number generator = generátor náhodných čísel] vygenerovat stejný výstup. Chyba v cpuset se týká možného úniku informací při čtení z /dev/cpuset/tasks (za předpokladu, že je podpora cpusetů zakompilována a cpuset fs připojen na /dev/cpuset). SCTP bug lze vzdáleně spustit při použití SCTP conntrack.

Starší jádra: 2.6.20.13 bylo vydáno 8. června se stejnými bezpečnostními opravami; následovalo jej 2.6.20.14 (11. června), které obsahuje další velkou dávku patchů.

2.4.34.5 vyšlo 6. června s několika opravami a přípravy na 2.4.35 pokračují vydáním 2.4.35-pre5, které také vyšlo 6.

Citáty týdne: Dave Jones, Paul Mackerras, Rusty Russell

Celková kvalita 2.6.21 je dost děsivá. Přibylo hodně nového kódu, který je důležitý pro správnou funkci jádra (např. beztikové věci), velké aktualizace oblastí jako ACPI a, aby to nebyla moc nuda, tak jsme přešli z IDE systému (věděli jsme, že je děsný, ale byl odzkoušený a prověřený) na systém založený na libata (úplně nový, ale vypadá slibně). Spousta změn = spousta potíží při prvním nasazení v produkčním systému.

-- Dave Jones

Nelíbí se mi, když si hodně vývojářů jádra myslí, že jakmile se objeví nějaká věc v jaderném/uživatelském API, která je trochu obtížná na implementaci, tak můžeme vinu svalit na aplikace, které na dané věci závisejí. Budeme o nich říkat, že jsou "zastaralé" [legacy], koncepčně chybné, vadné, zneužívají ABI [abuser] atd., a nakonec si ospravedlníme poškození ABI - protože se to stejně dotkne jen těch aplikací, které jsme už pomluvili.

-- Paul Mackerras

/* Slyšel jsem, že na světě existují jen dva příběhy,
 * které stojí za vyprávění: láska a nenávist. Takže tady
 * bývala scéna podobná této:
 *
 *  Launcher:	Mohli bychom spolu dělat krásné I/O.
 *  Host:	Páni, to je ale velký disk!
 *
 * Bohužel to bylo až příliš hříšné pro náš jinak
 * jemný příběh.
 */

-- Rusty Russell

Linus o GPLv3 a ZFS

Takže Sun by nakonec vypadal dobře, kdyby Solaris vydal pod GPLv3. Ale přitom by Linuxu zamezil převzít zajímavé části, zatímco oni by si mohli přinejmenším některé části Linuxu vzít, aniž by dali něco nazpět (ach, to jsou ty radosti fragmentace licencí). To oni samozřejmě vědí. A ano, ZFS by možná stálo za to, abych byl ochoten vynaložit úsilí na pokus o přelicencování jádra. Ale upřímně řečeno, můžu téměř garantovat, že Sun nevydá ZFS pod GPLv3 - i když jiné části třeba ano. Protože kdyby to udělali, přišli by o patentovou ochranu.

První vydání ovladače pro ATI R500

Podpora grafických čipsetů ATI R500 je jedním z největších chybějících dílů ve sbírce svobodných linuxových ovladačů. Situace se změnila s vydáním ovladače, který byl napsán s pomocí specifikací získaných reverse-engineeringem. Prozatím ovladač podporuje pouze 2D, ale na 3D se pracuje. Není překvapující, že vývojový tým by uvítal pomoc s přípravami na vydání verze vhodné pro produkční nasazení. Současná verze je velkým krokem vpřed; vývojáři, kteří práci dotáhli takhle daleko, si zaslouží gratulaci.

Kdo napsal a schválil 2.6.22

Blíží se oficiální vydání jádra 2.6.22. Do hlavního repozitáře stále přicházejí patche, ale všechno už je natolik stabilizováno, že se můžeme podívat, kde se kód vzal. Jonathan Corbet aktualizoval své skripty a prohrabal se všemi seznamy změn v tomto vývojovém cyklu.

Do této chvíle bylo do 2.6.22 přijato mírně přes 6 000 sad patchů. Přispělo 885 vývojářů, kteří přidali 494 000 řádků a smazali 241 000 jiných (nepočítá se přejmenovávání, které by obě čísla zvýšilo o přibližně 60 000 řádků). To z 2.6.22 dělá, ve srovnání s nedávnými předchůdci, velkou změnu:

Verze	Vývojářů	Sad změn	Přidáno řádků	Odebráno řádků
2.6.20	741	4983	286 000	160 000
2.6.21	842	5349	343 000	199 000
2.6.22-rc4+	885	6093	494 000	241 000

Nejaktivnější přispěvatelé:

Nejaktivnější vývojáři 2.6.22

Podle sad patchů David S. Miller 175 3,0 % Kristian Høgsberg 109 1,9 % Stephen Hemminger 86 1,5 % Arnaldo Carvalho de Melo 82 1,4 % Andrew Morton 79 1,3 % Stefan Richter 79 1,3 % Christoph Lameter 77 1,3 % Patrick McHardy 76 1,3 % Jean Delvare 75 1,3 % Dmitry Torokhov 70 1,2 % Stephen Rothwell 68 1,2 % Paul Mundt 66 1,1 % David Brownell 65 1,1 % Jeff Dike 63 1,1 % Alan Cox 60 1,0 % Andi Kleen 59 1,0 % Antonino Daplas 58 1,0 % Adrian Bunk 58 1,0 % Tejun Heo 57 1,0 % Russell King 57 1,0 %

Podle změněných řádků Bryan Wu 77594 12,9 % David Howells 23310 3,9 % Marcelo Tosatti 22351 3,7 % Patrick McHardy 21746 3,6 % Jiří Benc 18328 3,0 % Hans Verkuil 13683 2,3 % David S. Miller 13595 2,3 % Roland Dreier 12247 2,0 % Artem B. Bityutskiy 12065 2,0 % Kristian Høgsberg 11153 1,9 % Robert P. J. Day 7554 1,3 % Christoph Lameter 7378 1,2 % Andrew Victor 6638 1,1 % Mike Frysinger 6313 1,0 % David Brownell 6033 1,0 % Michael Chan 5851 1,0 % Andi Kleen 5431 0,9 % David Gibson 5321 0,9 % Nobuhiro Iwamatsu 5296 0,9 % Mark Fasheh 4921 0,8 %

Bryan Wu se vytáhl na čelo seznamu přispěvatelů (podle počtu změněných řádků) kvůli tomu, že přispěl podporou pro architekturu Blackfin. David Howells přispěl prací na AF_RXRPC a souborovém systému AFS; Marcelo Tosatti napsal ovladač pro bezdrátové zařízení OLPC "Libertas" a jméno Jiřího Bence je na stacku mac80211.

Když se to rozdělí podle zaměstnavatele, vypadají (přibližná) čísla takto:

Nejaktivnější zaměstnavatelé (2.6.22)

Podle sad patchů (neznámý) 1766 30,2 % Red Hat 720 12,3 % IBM 601 10,3 % Novell 411 7,0 % (žádný) 245 4,2 % Intel 203 3,5 % Oracle 127 2,2 % (konzultant) 119 2,0 % Linux Foundation 116 2,0 % Google 111 1,9 % SGI 93 1,6 % Nokia 83 1,4 % Freescale 80 1,4 % Astaro 76 1,3 % XenSource 56 1,0 % MontaVista 56 1,0 % Qumranet 55 0,9 % HP 53 0,9 % QLogic 52 0,9 % Analog Devices 49 0,8 %

Podle změněných řádků (neznámý) 130164 21,6 % Red Hat 104627 17,4 % Analog Devices 84561 14,0 % Novell 41366 6,9 % IBM 33629 5,6 % Astaro 22065 3,7 % (žádný) 20097 3,3 % (konzultant) 15403 2,6 % Linutronix 13585 2,3 % Intel 12288 2,0 % Cisco 12280 2,0 % Oracle 10482 1,7 % Freescale 10116 1,7 % SGI 8639 1,4 % Nokia 7328 1,2 % SANPeople 7045 1,2 % Broadcom 5952 1,0 % MontaVista 5810 1,0 % Linux Foundation 5746 1,0 % Atmel 5220 0,9 %

Jedna z věcí, která je hned vidět, je to, že množství kódu, kterým přispěli vývojáři pracující ve svém vlastním čase, pokleslo; 2.6.22 bude jedno z "nejfiremnějších" jader v historii.

Zajímavé výsledky nabízí také pohled na vývojáře, kteří přidali řádky "Signed-off-by" [odsouhlasil, podepsal]. Dáme-li do tabulek všech 12 678 podepsání v 2.6.22, dostaneme tohle:

Vývojáři s největším počtem podepsání (celkem 12 678)
Andrew Morton	1415	11,2 %
Linus Torvalds	1299	10,2 %
David S. Miller	814	6,4 %
Paul Mackerras	381	3,0 %
Jeff Garzik	344	2,7 %
Andi Kleen	252	2,0 %
Greg Kroah-Hartman	236	1,9 %
Mauro Carvalho Chehab	236	1,9 %
Stefan Richter	210	1,7 %
Russell King	189	1,5 %
James Bottomley	176	1,4 %
Jaroslav Kysela	145	1,1 %
Takashi Iwai	131	1,0 %
Len Brown	126	1,0 %
Kristian Høgsberg	126	1,0 %
Patrick McHardy	117	0,9 %
Jean Delvare	110	0,9 %
Roland Dreier	109	0,9 %
Antonino Daplas	106	0,8 %
Dmitry Torokhov	105	0,8 %

Všichni autoři musejí svůj kód podepsat. Kromě toho přidává podepsání každý správce, který kód předává výše na cestě k hlavnímu stromu, čímž dává najevo, že kód považuje za legitimní a vhodný k začlenění. Vynecháme-li podepsání patchů jejich autory, je zbývajících 7 000 podepsání od lidí, přes které kód přešel (několik z nich jsou dodateční autoři). Ti, kteří přidávají svá podepsání, mohou být tedy považováni za strážce, přes něž musejí všechny patche přejít. Neautorská podepsání vypadají takto:

Neautorská podepsání (celkem 7 028)
Andrew Morton	1336	19,0 %
Linus Torvalds	1279	18,2 %
David S. Miller	640	9,1 %
Paul Mackerras	371	5,3 %
Jeff Garzik	322	4,6 %
Greg Kroah-Hartman	222	3,2 %
Mauro Carvalho Chehab	216	3,1 %
Andi Kleen	193	2,7 %
James Bottomley	163	2,3 %
Jaroslav Kysela	142	2,0 %
Russell King	132	1,9 %
Stefan Richter	131	1,9 %
Len Brown	115	1,6 %
John W. Linville	85	1,2 %
Roland Dreier	85	1,2 %
Takashi Iwai	79	1,1 %
Martin Schwidefsky	54	0,8 %
David Woodhouse	53	0,8 %
Ralf Baechle	48	0,7 %
Antonino Daplas	48	0,7 %

80 % patchů začleněných do hlavního jádra prošlo přes těch dvacet vývojářů uvedených v tabulce. Můžeme jít ještě o krok dále a podívat se na počet neautorských podepsání podle zaměstnavatele:

Neautorská podepsání podle zaměstnavatele
Google	1338	19,0 %
Linux Foundation	1281	18,2 %
Red Hat	1246	17,7 %
Novell	700	10,0 %
(neznámý)	660	9,4 %
IBM	553	7,9 %
(žádný)	293	4,2 %
Intel	193	2,7 %
SteelEye	163	2,3 %
Cisco	85	1,2 %
MIPS Technologies	48	0,7 %
Nokia	42	0,6 %
Astaro	41	0,6 %
Analog Devices	35	0,5 %
QLogic	35	0,5 %
Cendio	32	0,5 %
SGI	28	0,4 %
NetApp	28	0,4 %
(konzultant)	23	0,3 %
Oracle	22	0,3 %

Podtrženo sečteno: ačkoliv je vývoj Linuxu vysoce distribuovaná činnost, prochází práce několika stovek vývojářů na cestě do hlavního jádra rukama překvapivě malého množství jednotlivců a ještě menším počtem společností.

Další zábava s popisovači souborů

Minulý týden vývojáři uvažovali o přidání dvou příznaků k systémovému volání open(); aplikacím by to umožnilo zvolit dříve nedostupné funkce, např. nesekvenční rozsah popisovačů souborů nebo okamžité uzavření při spuštění [close-on-exec]. Problém je v tom, že open() je jen jedno z mnoha systémových volání, která vytvářejí popisovače souborů; většina ostatních nemá parametr, který by aplikacím umožňoval předat doprovodné příznaky. Takže nesekvenční chování není možné požadovat, je-li popisovač získán např. pomocí socket(), pipe(), epoll_create(), timerfd(), signalfd(), accept() a tak dále.

V druhé verzi patche s nesekvenčními popisovači souborů se Davide Libenzi pokusil část problému řešit přidáním systémového volání socket2() s doplněným parametrem "flags" [příznaky]. To stačilo k vyděšení většiny vývojářů; nikdo nechce mít na krku masívní rozšíření počtu systémových volání kvůli přidávání variant všech volání, která vytvářejí popisovače. Vypadá to, že bude nutné najít jiný přístup, což však není zrovna snadné.

Jednou možností je prostě problém ignorovat; ne každý je přesvědčen o nezbytnosti nesekvenčních popisovačů souborů nebo okamžitého close-on-exec. Je však dost těch, kteří v tom spatřují problém, takže motivace k hledání řešení existuje. Ulrich Drepper, správce glibc, už viděl dost aplikací na to, aby došel k názoru, že je to skutečně potřeba řešit.

Alan Cox navrhl alternativní přístup, který spočívá ve vytvoření příznaku stavu procesu, pomocí něhož by šlo tyto funkce ovládat. Takže volání

    prctl(PR_SPARSEFD, 1);

by zapnulo nesekvenční alokaci popisovačů souborů pro všechna systémová volání provedená volajícím procesem. Potíž je v tom, že princip nejnižšího dostupného popisovače je dokumentovanou částí POSIXového binárního rozhraní. Proces by se této záruky sám za sebe mohl vzdát, ale těžko předvídat, jestli by při absenci tohoto chování správně fungovaly i všechny používané knihovny. Jedna knihovna by mohla chtít využít nesekvenční popisovače souborů, ale nemohla by je bezpečně zapnout pro celý proces, aniž by riskovala výskyt složitých chyb na podivných místech. Starým knihovnám by se mohlo dát vyhnout kouzlením s linkerem, ale Ulrich má pocit, že by lidé reagovali obyčejným překompilováním starších knihoven a potenciální chyby by v nich zůstaly.

Linus se do diskuze zapojil prohlášením, že přijatelné není ani přidávání hromady nových systémových volání, ani globální příznak. Místo toho přišel s úplně jiným nápadem: vytvořit mechanismus, který by jednotlivým systémovým voláním umožňoval spuštění s určitou sadou příznaků. Navrhované rozhraní vypadá takto:

    int syscall_indirect(unsigned long flags, sigset_t sigmask,
                         int syscall, unsigned long args[6]);

Výsledkem by bylo volání daného systémového volání s požadovanými parametry. Po dobu průběhu volání by platily předané flags a zároveň by byly blokovány signály v sigmask. Tento mechanismus by mohl být využit i pro implementaci série systémových volání (například pselect()), která existuje jen kvůli přidání signální masky k dřívější verzi volání. Nesekvenční popisovače souborů a close-on-exec by pak mohly být vyžádány pomocí parametru flags. Kromě toho by bylo možné přidat příznaky pro ovládání symbolických odkazů a různých dalších věcí. Matt Mackall navrhl, že by mechanismus sysletů mohl být implementován coby příznak "spusť toto volání asynchronně".

I s tímto přístupem by mohly být problémy. Objevily se obavy, že by bity flags mohly rychle dojít, což by znovu ztížilo přidávání parametrů k existujícím systémovým voláním. Linus navrhl přetížení [overload] bitů příznaků, aby vydržely déle. Existuje však nebezpečí, že by se vývojáři aplikací pokusili aplikovat na dané systémové volání špatné příznaky - nebylo by možné takové chyby automaticky zachytit. Je však nepravděpodobné, že by aplikace samy volaly syscall_indirect(), takže jde o poměrně malé riziko. Je však na místě si dělat starosti, jestli toto rozhraní pokrývá veškeré představitelné a smysluplné úpravy chování, nebo jestli potřebuje jinou sadu parametrů. Navíc je možné, že za pár let bude velké procento systémových volání prováděno přes syscall_indirect().

Toto nové systémové volání má však ještě jeden nedostatek: neexistuje žádná funkční implementace. Až nějaká bude, povede to patrně k širší diskuzi o navrhovaném rozhraní. Pokud to i pak bude bráno jako dobrý nápad, mohli bychom se dočkat způsobu, jak ke starým funkcím přidávat nové možnosti bez zvýšení počtu systémových volání. Někdy možná opravdu platí, že je nejlepší počítačové problémy řešit další úrovní [level of indirection].

---

Následující obsah je © KernelTrap

Překládání dokumentace k jádru

11. čer, originál

Překlady částí dokumentace k Linuxu do japonštiny vedly k diskuzi o tom, jestli je nebo není vhodné zařazovat přeloženou dokumentaci ke zdrojovým kódům jádra. Proti mluví fakt, že s rostoucím počtem zařazených překladů bude růst i velikost jádra. Navíc je pravděpodobné, že by jednotlivé překlady časem přestaly být aktuální. Jesper Juhl navrhl jiné řešení: Protože je angličtina společným jazykem většiny přispěvatelů, řekl bych, že bychom se v rámci stromu měli držet jen tohoto jednoho jazyka a překlady nechat někde na webu.

Greg KH poznamenal, že je v jádře několik souborů, které jsou měněny jen velmi zřídka, a jejichž překlady by rád ke zdrojovým kódům přidal: Opravdu bych v jádře rád viděl přeložené HOWTO, stable-api-nonsense.txt a možná ještě pár dalších souborů (SubmittingPatches, CodingStyle a SubmittingDrivers). Jde o soubory, které jsou měněny poměrně málo často (soubor HOWTO zaznamenal pouze 7 změn za rok a půl, většinou jen drobné úpravy), takže by překladatelům nemělo činit potíže je udržovat aktuální.

       

Komentáře

[Käyttäjä 11133]

Ty tabulky s vývojáři jsou v Jaderných novinách pokaždé? Pokud doposud v novinách nebývaly, tak budou v každých?

[Robert Krátký]

Tabulky s vývojáři vyšly v JN poprvé, protože je Jonathan Corbet zařadil do Kernel Page na LWN (poprvé od doby, kdy je LWN předlohou pro JN). V každém díle nebudou určitě, protože ne pokaždé je na spadnutí vydání nové verze jádra. Ale pravděpodobně nebudou ani doprovázet všechna vydání nových verzí, protože jde spíše o zajímavost než o podstatnou informaci.

[Petr (DotaZ) Jakubec]

dovolim si nesouhlasit: podle mne jde o zajimavou a podstatnou informaci. napriklad mi z nich vyplyva, kdo ma jaky vliv na podobu jadra (osoby firmy), kdo je sikulka pracovita a podobne...

rozhodne me ty tabulky prijemne prekvapily (resp. zavery vyplyvajici z tech dat)!

[Jary]

Děkuji za tento zajímavý a poučný seriál.

[Saha]

Je někde ten seznam přispěvatelů kompletní - mě by celkem zajímal podíl Canonicalu - docela mě překvapuje, že v první dvacítce není...

[Käyttäjä 11133]

<joke>Možná proto, že canonical jen vykrádá debian </joke>

[jikos]

Neni ani v prvni tricitce, viz preprint letosniho Gregova talku na OLS - https://ols2006.108.redhat.com/2007/Reprints/kroah-hartman-Reprint.pdf

[Murry]

velmi pěkný článek!! A zajímavé počty, procenta..... (nebo jak se to jmenuje)

[Petr (DotaZ) Jakubec]

jmenuje se to tabulka

ale klidne muzes pouzit velmi vtipnou hlasku o procentnich bodech, tedy "procentni bod", jak casto slysim v televizi apod.

[Michal Kubeček]

Na termínu procentní bod není nic vtipného. Není sice dvakrát názorný, ale je to pořád lepší, než kdyby komentátoři říkali úplné nesmysly, jak měli ve zvyku dříve, než se tento termín začal používat.

[Hynek (Pichi) Vychodil]

Když něco nevím, tak se zeptám, nebo si o tom něco zjistím. Když má produkt X podíl na trhu 4% a jeho podíl se zvětší o 50%, kolik bude mít podíl na trhu? 6%! A když se jeho podíl zvýší o 50 procentních bodů, kolik bude mít na trhu? 54% a to je sakramentský rozdíl. Zaplať pánbůh za to, že i už i ti ignoranti novinářští znají ten rozdíl.