Portál AbcLinuxu, 7. května 2025 20:09
Jaderné noviny 335
Články
-
Jaderné noviny 335
Popis a debata vývojového procesu.
Hledají se testeři Sharp Zaurus-5500.
Nový souborový systém eCryptFS.
Podpora řadiče Secure Digital Host.
Popis a debata vývojového procesu, 78 e-mailů
29. říj - 7. lis
Paolo Ciarrocchi napsal:
Rád bych napsal krátký článek o novém vývojovém procesu diskutovaném
na posledním Linux Kernel Developers summitu. Neboť nemůžu najít přesný
zápis, o čem se během setkání diskutovalo, snažím se shrnout, jak
aktuálnímu procesu rozumím:
Existují dva druhy vydání, jádra 2.6.x a 2.6.x.y
2.6.x.y jsou udržovány stabilním týmem (stable at
kernel dot org) a vydávány skoro každý týden. Zde je poslední (jak
doufám) oznámení, které jsem našel v archivu, obsahující vysvětlení, jak
stabilní vývoj funguje:
Pravidla, jaké patche jsou přijaty a jaké ne, do "-stable" větve:
- Musí být samozřejmě správné a otestované.
- Nesmí to být delší než sto řádek včetně kontextu.
- Musí to opravovat jedinou věc.
- Musí to opravovat skutečnou chybu, která obtěžuje lidi (ne "To by
mohl být problém").
- Musí to opravovat problém, který způsobuje problém při kompilaci,
oops, zatuhnutí, poškození dat, skutečný bezpečnostní problém, prostě
něco kritického.
- Nesmí to obsahovat žádné triviální opravy (překlepy, úpravy počtu
mezer atd.).
- Musí to být přijato správcem daného podsystému.
- Musí to dodržovat zásady z Documentation/SubmittingPatches.
Postup pro zasílání záplat do -stable větve:
- Zašlete patch, po zkontrolování výše uvedených pravidel, do
stable@kernel.org.
- Odesílatel obdrží potvrzení, že patch byl přijat do fronty, nebo
zamítnut. Odpověď může trvat několik dní, podle rozvrhu vývojáře.
- Pokud bude přijat, patch bude zařazen do -stable fronty pro
prohlédnutí ostatními vývojáři.
- Bezpečnostní záplaty by neměly být zasílány na tuto schránku, ale
do dokumentované schránky security@kernel.org.
Kontrolní cyklus:
- Když se -stable správci rozhodnou pro přezkumný cyklus, záplaty
jsou zaslány kontrolní komisi [review committee] a správci dotčené
oblasti (pokud není zároveň odesílatelem patche) a do kopie i
konference linux-kernel.
- Kontrolní komise má 48 hodin na přijetí či zamítnutí patche.
- Pokud bude záplata zamítnuta členem komise nebo členové konference
linux-kernel naleznou problémy, na které správce či členové komise
nepřišli, patch bude vyřazen z fronty.
- Na konci kontrolního cyklu budou akceptované patche zařazeny do
nejnovější -stable verze a ta bude vydána.
- Bezpečnostní patche budou přijaty do -stable větve přímo
bezpečnostním jaderným týmem a nikoli běžným kontrolním cyklem.
Kontaktuje tento tým pro detaily této procedury.
Kontrolní komise:
- Bude vytvořena z většího počtu vývojářů jádra, kteří se dobrovolně
přihlásili pro tento úkol, a několika, kteří ne.
Jádro 2.6.x je spravováno Linusem Torvaldsem a Andrew Mortonem (oba z
OSDL) a vývoj je následující:
- Jakmile nový kernel je vydán, otevře se dvoutýdenní okno, během
kterého mohou správcové zaslat Linusovi velké diffy (obvykle prověřené
několika týdny v -mm jádrech). Preferovaný způsob je skrze git (více
na http://git.or.cz/ a v
http://www.kernel.org/pub/software/scm/git/docs/tutorial.html).
- Po dvou týdnech je vydáno -rc1 jádro a od té doby je možné zasílat
jen patche, které nepřidávají novou funkčnost.
- Po dvou týdnech je vydáno -rc2 jádro.
- Proces pokračuje, dokud není jádro považováno za stabilní, proces
by měl trvat tři měsíce (měla by být tedy vydána čtyři jádra za rok).
Je mi jasné, že jsem zapomněl na spoustu detailů, takže bych byl
vděčen za podporu při psaní tohoto článku, který snad bude užitečný mému
lokálnímu LUGu 
Jesper Juhl reagoval s tím, že nedávno napsal dokument o různých
jaderných stromech a jak do nich zasílat patche. Dokument je možné najít v
Documentation/applying-patches.txt nebo
online.
Tony Luck napsal Paolovi ohledně -rc1: Původně
Linus napsal, že bude přijímat pouze emailové patche po rc1 ..., ale zdravý
rozum zvítězil a později ujasnil, že git merge mohou být také použity, ale
jen pro opravy chyb. Pak dodal, že zcela nový ovladač či souborový
systém může být přijat i po -rc1, protože zde není riziko zhoršení. Tony
dále napsal, že oficiální pevný termín má pouze první kandidát -rc1, další
přicházejí, jak přicházejí. Pokud jde o tříměsíční termín, cílem je
vytvořit novou verzi v osmi týdnech, což je blíže šesti verzím za rok.
Linus Torvalds napsal:
Ano, tři měsíce by byly příliš mnoho. Osm týdnů je lepší, než bývalo
zvykem, ale myslím, že šest týdnů by mělo být naším cílem. Ale abychom
toho dosáhli, měli bychom zkrátit začleňovací okno z dvou týdnů na
jeden, jinak nebude dost prostoru pro vychladnutí. Protože se nejvíce
vývoje děje během předchozí chladící fáze, tak by to nemělo být nemožné:
měli bychom jen jeden týden na začlenění, ale to není ten týden, kdy se
vývoj děje, takže komu by to vadilo?
Takže plánuji pokračovat prozatím beze změny. Dvoutýdenní začleňovací
okno až do -rc1, pak další -rc vydání každý týden až do releasu. Cíl je
šest týdnu s tím, že osm týdnů je v pořádku. Nemyslím, že by někdo byl z
tohoto skutečně nešťastný, že?
Vývojáři diskutovali nad smyslem -rc vydání a zda by měl být poslední
-rc kernel přejmenován na finální verzi. Linus odpověděl:
To by vůbec nepomohlo. Proč? V prvé řadě protože jen malé procento
lidí testuje -rc jádra. Takže pokud vydáte poslední -rc verzi jako
standardní kernel, tak za prvé stejně nezískáte žádné výhodnější pokrytí
a za druhé jste promarnili týden snahou získat nějaké pokrytí, které
nedostanete.
Aktuální model vývoje kernelu je začlenit novinky na začátku, což
doufejme motivuje lidi zkoušet -rc jádra pro testování -rc1, neboť vědí,
že to je to jádro, které má všechny dobrůtky.
Většina z testerů -rc1 nikdy nenarazí na žádné problémy. A ti, kteří
ano, budou nejspíše testovat další -rc verze, dokud jejich problém není
vyřešen. A ti, kteří netestují -rc verze (protože neupgradují moc často)
nebudou nikdy testovat -rc verzi, ať už první nebo poslední.
Takže s čím musíme bojovat, je stabilní řada. Vypouštíme finální
2.6.x kernel s co nejlepším testováním, ale je nepopiratelným faktem, že
spousta lidí bude zkoušet toto jádro a často až po několika týdnech od
uvedení. Vytváření -rc verzí nic neprovede pro tyto případy. Takže
opakujte po mně: "Většina lidí nikdy netestuje -rc verze".
Hledají se testeři Sharp Zaurus-5500, 7 e-mailů
2. lis - 4. lis
Pavel Machek napsal, že hledá testery pro sharp zaurus sl-5500
ochotných otestovat kernel. Na kernel.org je k dispozici linux-z strom,
který se snaží držet synchronizován s hlavní větví a který se začíná
stávat použitelným. Hlavní nevýhodou je, že nabíjení baterie ještě není
hotovo, doteková obrazovka již má podporu, ale Pavel neměl možnost
ji otestovat.
Nový souborový systém eCryptFS, 42 e-mailů
2. lis - 7. lis
Phillip Hellewell napsal:
Tato sada záplat vytváří eCryptfs verze 0.1. Posíláme ji pro
prohlédnutí a případné začlenění do jádra. eCryptfs je stohovatelný
[stackable] souborový systém založený na Cryptfs, který je generován
pomocí frameworku FiST na stohovatelné souborové systémy napsaného
Erezem Zadokem: http://filesystems.org/.
eCryptfs ukládá kryptografická metadata do hlavičky každého souboru,
hlavičky obsahují pakety podobné OpenPGP (viz RFC 2440). To umožňuje
kopírování kryptovaných souborů mezi počítači, přičemž informace nutné
pro rozšifrování souborů zůstávají se soubory. eCryptfs se snaží, aby
šifrování a dešifrování každého souboru bylo úplně transparentní
uživatelským aplikacím, pokud má příjemce požadovaný klíč či heslo pro
daný soubor.
Michael Halcrow předvedl eCryptfs v roce 2004 a 2005 na Ottawském
linuxovém symposiu, základní přehled začíná na stránce 209 tohoto PDF:
http://www.linuxsymposium.org/2005/linuxsymposium_procv1.pdf.
Tato sada patchů obsahuje výrazně ořezanou verzi eCryptfs oproti
tomu, co bylo posláno do LKML minule. Verze 0.1 obsahuje podporu
zadávání hesla jen při připojování svazku, což činí eCryptfs snadnějším
pro analýzu a debugování, než budou složitější vlastnosti jako veřejný
klíč či rozšířená pravidla začleněna.
eCryptfs funguje dobře při spoustě testů včetně FSX a Connectathon.
eCryptfs používá keyring Davida Howella, verze 0.1 očekává existující
autentikační token v uživatelově keyring relaci. Zdrojový kód si můžete
stáhnout na SourceForge (ecryptfs-v0_1.tar.bz2):
http://sourceforge.net/projects/ecryptfs/.
Podpora řadiče Secure Digital Host, 1 e-mail
8. lis
Pierre Ossman napsal: Začal jsem pracovat na
ovladači podle specifikace Secure Digital Host Controller. Zdá se, že je
používán většinou řadičů dnešních osobních počítačů, takže ovladač přidá
podporu řadě čipů. Informace jsou vzácné, takže nevím, zda jej dotáhnu do
konce, ale pro ty, kteří chtějí trochu nebezpečí ve svém životě:
http://mmc.drzeus.cx/wiki/Linux/Drivers/sdhci
Tento článek vychází ze seriálu Kernel Traffic
(www.kerneltraffic.org) a je
zveřejněn pod licencí GPL
verze 2.
Další články z této rubriky
Diskuse k tomuto článku
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
