Jaderné noviny 303

Trvalý obrázek na pozadí při použití framebufferu. Pravidla stromu w.x.y.z '-stable'. Otázka licence NVIDIA. Nekompatibilní moduly mezi vydáními w.x.y.z.

Trvalý obrázek na pozadí při použití framebufferu, 26 e-mailů

Fbsplash - Framebuffer Splash - je funkce umožňující zobrazování obrázků na pozadí konzolí, které používají fbcon. Projekt je částečně založen na bootsplash.

Oproti bootsplash nemá fbsplash žádný dekodér obrázků přímo v jádře. Dekomprimace obrázků je řešena pomocnou aplikací v uživatelském prostoru, která jádru předává surová obrazová data. Také neexistuje podpora věcí jako jsou tichý režim a ukazatele průběhu, protože je lepší je řešit uživatelskými programy.

Jsou podporovány režimy truecolor, directcolor a pseudocolor. Fbsplash nezávisí na žádném specifickém ovladači framebufferu. Byl testován s vesafb, rivafb a radeonfb.

Technické podrobnosti o rozhraní uživatelský prostor<->jádro jsou k nalezení v patchi 07/07, který obsahuje dokumentaci.

Uživatelské utility využívající fbsplash jsou na: http://dev.gentoo.org/~spock/projects/splashutils/

James Simmons si myslel, že to je zbytečná věc; laskominka pro oko, ale beze smyslu. Ale Pavel Machek poznamenal: Přinejmenším některé verze Debianu, Gentoo a SUSE používají nějakou variantu takové laskominky; všechny s jinými chybami. Bylo by fajn mít alespoň tu úvodní obrazovku správně (aby nevyžadovala vesafb a umožňovala tak funkční suspend-to-RAM).

Pravidla stromu w.x.y.z '-stable', 35 e-mailů

Tohle je první návrh procesu vydávání -stable 2.6 řady. Vytvořili jsme s Chrisem. Máte k tomu někdo nějaké otázky/stížnosti/nejasnosti?

Vše, co jste kdy chtěli vědět o jádrech Linux 2.6 -stable.

Pravidla týkající se druhu patchů, které budou přijímány a odmítány:

Musí být zjevně správný a testovaný.
Nesmí být delší než 100 řádků, včetně kontextu.
Musí opravovat pouze jednu věc.
Musí opravovat skutečný problém, který lidem působí potíže (ne věci typu "Tohle by mohl být problém...").
Musí opravovat problém, který způsobuje chybu při kompilaci (ale ne u chyb označených jako CONFIG_BROKEN), oops, zatuhnutí, poškození dat, skutečný bezpečnostní problém nebo nějakou záležitost typu "a jé, to není dobré". Prostě něco závažného.
Žádné "teoretické problémové případy" pokud neexistuje vysvětlení, jak může být problém zneužit.
Nesmí obsahovat žádné "triviální" opravy (opravy pravopisu, čištění kódu atd.).
Musí být schválen příslušným správcem subsystému.
Musí se držet pravidel v Documentation/SubmittingPatches.

Postup posílání patchů do stromu -stable:

Po ověření, že splňuje vyjmenovaná pravidla, patch pošlete na stable@kernel.org.
Odesílatel obdrží potvrzení o přijetí, pokud bude patch zařazen do fronty, nebo odmítnutí, bude-li odmítnut. Taková odpověď může pár dní trvat - podle toho, jak budou mít vývojáři čas.
Bude-li přijat, zařadí se do -stable fronty, která bude prohlédnuta dalšími vývojáři.
Bezpečnostní patche by neměly být posílány na tento alias, ale na běžný security@kernel.org.

Kontrolní období:

Jakmile se správci -stable shodnou na kontrolním období, budou patche odeslány kontrolní komisi, správci dotčené oblasti kódu (pokud není zadavatelem patche sám správce oblasti) a kopie do konference linux-kernel.
Kontrolní komise má 48 hodin na to, aby patch přijala nebo odmítla.
Je-li patch členem komise odmítnut, nebo stěžují-li si na něj členové konference linux-kernel, kteří upozorní na problémy, které unikly správci i členům komise, bude patch z fronty vyřazen.
Na konci kontrolního období budou schválené patche zařazeny do nového -stable vydání a jádro vyjde.
Bezpečnostní patche budou do -stable přijaty automaticky od jaderného bezpečnostního týmu a nebudou procházet běžným kontrolním procesem. Více podrobností o této proceduře sdělí jaderný bezpečnostní tým.

Kontrolní komise:

Bude vytvořena z několika vývojářů jádra, kteří se dobrovolně přihlásili (a několika, kteří se nehlásili).

Andi Kleenovi se nelíbil jeden z Gregových bodů. Nezamlouvala se mu představa, že bezpečnostní patche by procházely jaderným bezpečnostním týmem, a ne běžným kontrolním procesem. Řekl: Jak je možné, že má bezpečnostní tým větší kompetence než správci subsystémů? Viděl bych přehlasovávání správců ohledně bezpečnostních záležitostí jako rozumné, pokud by správci neodpovídali. Ale pokud reagují, měli by být myslím kontaktováni především oni.

Arjan takový výklad podpořil, ale Marcelo Tosatti připomněl: Bezpečnostní tým bude se správci spolupracovat - ne je přehlasovávat. To by bylo skutečně šílené. Chris to potvrdil a dodal: Jde o to, že je nutné koordinovat i zveřejňování. Andimu to stále nestačilo a měl pocit, že pravidla v této věci nejsou dost jasná. Ale po chvíli přetahování napsal Greg: Nechme dohadů o výkladu pravidel. Uvidíme, jestli to, co jsme navrhli, funguje ve skutečném provozu. Pokud ne, můžeme se k tomu vrátit.

Otázka licence NVIDIA, 7 e-mailů

Nedávno přidaný kód nvidia framebufferu je označen jako MODULE_LICENSE(GPL), ale některé věci se mi moc nezdají...

Úvodní text na začátku souborů drivers/video/nvidia/nv_dma.h, drivers/video/nvidia/nv_local.h a drivers/video/nvidia/nv_hw.c nevypadá jako licence kompatibilní s GPL. Bude to nějaká speciální nvidia licence s reklamní podmínkou a něčím, co omezuje práva koncových uživatelů z řad vlády Spojených států.
Soudě dle CVS značek v kódu pocházejí některé z těch souborů zjevně z XFree86. Byl tento XFree86 kód vydán původními autory pod dvojí licencí? Pokud ano, tak to z toho není zřejmé.

Andrew Morton se zeptal: Stačí jako vysvětlení tohle: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/ 2.6.11/2.6.11-mm3/broken-out/fbdev-nvidia-licensing-clarification.patch? Arjan van de Ven odpověděl: Více méně. Bylo by rozumné to vydat pod dvojí licencí (jako většinu věcí v jádře, které původně nebyly pod GPL), aby se ten právní stav doopravdy vyjasnil. Protože pokud to jen tak začleníte do GPL kódu, stane se z toho vlastně GPL kód (díky svobodě MIT a virové nátuře GPL). A já mám pocit, že autor měl v úmyslu ponechat možnost užívání pod MIT...

Jon Smirl připomněl, že všechny soubory v drivers/char/drm by skutečně měly mít výslovně duální MIT/GPL licenci. Projekt DRM přebíral z LKML zpět patche, aniž by upřesnil, že je DRM licencováno MIT. Dalo by se vyvozovat, že se tak DRM stalo GPL, aniž by to bylo zamýšleno. Arjan odpověděl: Bez výslovné dvojí licence je to fakt past.

Nekompatibilní moduly mezi vydáními w.x.y.z, 2 e-maily

Chápu-li to správně, tak ta "super-stabilní" jádra by neměla nikterak ovlivnit ABI modulů. Tedy, modul zkompilovaný pro 2.6.11 nebo 2.6.11.2 by měl fungovat s 2.6.11.4 a naopak. Mluvím samozřejmě o modulech neobsažených v hlavním stromu jádra.

Ale. S každým vydáním 2.6.11.x se mění EXTRAVERSION, takže cizí moduly jsou nekompatibilní jen proto, že obsahují jiné označení verze jádra.

Otázka je nasnadě: je tohle správné/zamýšlené chování? Možná, jen možná by EXTRAVERSION neměla být brána v potaz, když se rozhoduje o tom, jestli je daný modul zkompilovaný pro konkrétní jádro.

K tomu, že jádra w.x.y.z by neměla ovlivnit binární aplikační rozhraní jádra (ABI), Arjan van de Ven řekl: To je předpoklad, který se mi obecně nezdá moc platný. Více se o tom nediskutovalo.

Jaderné noviny 303

Trvalý obrázek na pozadí při použití framebufferu, 26 e-mailů

Pravidla stromu w.x.y.z '-stable', 35 e-mailů

Vše, co jste kdy chtěli vědět o jádrech Linux 2.6 -stable.

Otázka licence NVIDIA, 7 e-mailů

Nekompatibilní moduly mezi vydáními w.x.y.z, 2 e-maily

Související články

Odkazy a zdroje

Další články z této rubriky

Diskuse k tomuto článku