Jaderné noviny 221

24. 7. 2003 | Richard Bukovanský | Jaderné noviny | 3292×

Status ACPI ve verzi 2.4. Linus přechází do OSDL. Stav podpory VFS Automount. Pravidla zasílání patchů. Update MegaRAID ovladače.

Do konference přišlo celkem 1989 emailů, nejvíce jich poslali Greg KH, Andrew Morton, Adrian Bunk.

Status ACPI ve verzi 2.4, 24 e-mailů

Marcelo Tosatti během diskuze řekl, že by rád přidal velké ACPI patche do verze 2.4.23 místo do 2.4.22, jak chtěli ostatní. Chtěl by také velmi rychle (během pár měsíců) vydat 2.4.22 a to mu nedává dost času na řádný test těch změn v ACPI. Andrew Grover mu odpověděl:

To není problém, až na to že odsouváš sloučení už přes rok. Udržujeme tento patch mimo hlavní strom už OSMNÁCT MĚSÍCŮ. Přestaň mě prosím vodit za nos. Sloučíš to vůbec NĚKDY?

Jsem přesvědčen, že se to sloučí čistě.
Jsem přesvědčen, že to nepřivodí problémy, když bude nastaveno CONFIG_ACPI=off
Jsem přesvědčen, že vzroste celkový počet funkčních strojů.
Jsem ochoten na to vsadit SVÝCH 500 dolarů.

Chlape, mluv se mnou. Co ještě chceš? Hodně na tom závisí.

Marcelo ho ujistil, že to zařadí v 2.4.23-pre, a slíbil, že 2.4.22 bude vydána co nejrychleji, aby nepředstavovala velké zpoždění. Alan Cox poznamenal:

Již nějakou dobu je to v 2.4.21-ac. Mám přesně nula zpráv o problémech v případě acpi=n a celou hromadu typu "první Linux, který běží na mém Toshiba/Comapaq/HP notebooku."

Funguje tak dobře, že tomu mohu důvěřovat.

Stephan von Krawczynski to potvrdil vlastními zkušenostmi a Torben Mathiasen dodal, že ACPI bylo potřebné, aby se jeho notebook tak nepřehříval.

Eric Valette někde jinde napadl Marcelovu upřímnost. Marcelo slíbil přidat ACPI v 2.4.22-pre a neudělal to a teď slibuje přidání v 2.4.23-pre. Eric zopakoval význam, který lidé kladou na ACPI v 2.4 jádře. A také poukázal, že Marcelo neobjasnil, co plánuje v 2.4.22, co by mohlo bránit přidání ACPI. Marcelo odpověděl (všimněte si jeho změny postoje k ACPI):

Můj plán pro 2.4.22:

• Zařazení nového aic7xxx ovladače.
• Zařazení ACPI. (Teď jsem si uvědomil jeho důležitost). Už s Andrew diskutujeme, jak to nejlépe udělat.
• Oprava problému s latencí a interakcí (Chris, Nick a Andrea na tom pracují)
• Připojení zjevně správných -aa VM patchů.

Myslím, že to jsou nejvíce potřebné věci.

Linux 2.5.71 uvolněn, 34 e-mailů

Linus Torvalds oznámil 2.5.71, a dodal:

Myslím, že budu tento kernel nazývat "líná želva" ["sticky turtle"], na památku historického kernelu "namydlený blesk" ["greased weasel"] a toho, jak smutně závislý jsem se stal na denních BK obrazech. Bylo to hodně dlouho od 2.5.70.

Slibuji, že se polepším. Ne každý používá denní obrazy či BK strom, tak jak to dělá většina vývojářů, mnoho uživatelů chce "skutečná vydání".

V tomto vydání toho není tak moc zajímavého, ale Al Viro vyčistil tty vrstvu a Stephen Hemminger s pomocí různých lidí opravil alokační/uvolňovací potíže některých síťových zařízení.

A samozřejmě jsou také aktualizace usb/pcmcia/sound architektury s modely ovladačů a síťování jako bonusem.

Linux 2.5.72 uvolněn; Linus přechází do OSDL, 10 e-mailů

Linus Torvalds oznámil 2.5.72 a napsal:

Ok, čekal jsem hodně dlouho s 2.5.71, takže zde je včasné vydání 2.5.72.

Je to dost rychle převážně proto, že hash list poisoning nalezlo nějaké problémy v kódu RPC, což shazovalo NFS. Trond to vyhledal a opravil, takže by měla 2.5.72 také v NFS prostředích fungovat bezvadně. Uvidíme, zda list poisoning ukáže nějaké další nebezpečné uživatele. Klepu na dřevo.

Kromě toho Arnaldo vyčistil spoustu síťového kódu tak, aby používal všeobecný seznam hashů místo starého ad-hoc pro síť specifického seznamu kódu. Tento kód byl velmi dobře otestován, ale pokud něco uvidíte, prosím křičte.

Seznam změn pro ostatní je přiložen.

Další velkou zprávou je - tedy aspoň pro mne osobně - že jsem se po více jak 6 letech rozhodl opustit Transmetu, abych se mohl naplno věnovat jádru.

Transmeta mne vždy nechávala trávit nadměrnou dobu s Linuxem, a kvůli tomu jsem se cítil trochu provinile, že jsem poslední dobou neudělal moc *skutečné práce*. Abych to napravil, budu místo toho pracovat v OSDL, kde bude konečně Linux hlavní náplní mé práce.

[ Neočekávám v důsledku toho velké množství změn, což svědčí o tom, jak volně mne nechávala Transmeta pracovat na Linuxu. Má e-mailová adresa se změní na "torvalds@osdl.org" a bude platná od prvního července, ale každý se snaží udělat ten přesun plynulý, takže zajistíme, aby se adresy dostatečně dlouho překrývaly atd., aby nenastal žádný problém. ]

OSDL a Transmeta o tom zítra ráno vydají společnou oficiální (čti: "nudnou". Měli jste vidět ten životopis - ten se tam nedostal - který jsem kvůli tomu pro sebe navrhoval.) tiskovou zprávu, ale hlavně jsem chtěl poděkovat Transmetě. Bylo to neobyčejné zaměstnání, a ahoj OSDL, kde to bude, jak doufám, stejné.

Fňuk. Jsem z toho nakonec úplně naměko.

Miles Bader poznamenal:

"Stále ještě trochu žasnu nad tím, když si připomenu, že Linus - až do teď - _napracoval_ na plný úvazek na jádře. [Je to jako ti chlápci, co ujedou na kole sto mil před snídaní, ale i tak jsou vždy v práci dřív než já...]!

Někde jinde pod předmětem: [PATCH] OProfile: IO-APIC fixup, se John Levon zeptal, jestli už je nová Linusova adresa funkční, a Linus odpověděl:

Měla by a můžete ji začít zkoušet. Mám stále nastaveno posílání všech e-mailu od Transmety, takže odpovědi dostanete ze staré adresy, ale čím více testů, tím lépe...

Stav podpory VFS Automount, 26 e-mailů

David Howells oznámil:

Připojený patch přidá do VFS podporu automatického připojování a podporu vypršení připojovacího bodu.

Tento patch také zahrnuje přidání následujících vlastností:

1. Nová dentry operace, která (a) označí dentry jako bod pro automatické připojení, a (b) je volána VFS, aby dodala vfsmount strukturu, kterou pak VFS přišije [stiches] do struktury stromu připojení [mount tree fabric] na správné místo.
2. Nový hledací příznak [lookup flag], jenž úžívá nsys_*stat(), což zabraňuje automatickému připojení koncového bodu cesty. To znamená, že "ls -l" v adresáři automatického připojovače nezpůsobí bouři připojování, ale zobrazí všechny přípojné body v tomto adresáři jako podadresáře (buď adresáře mapovacích bodů o úroveň níže nebo kořenového adresáře připojeného souborového systému, jestliže byl mountpoint již spuštěn).
3. do_kern_mount() je nyní exportováno.
4. Struktura vfsmount získala, mimo dalších věcí, také položku času vypršení [timeout field]. Jestliže mntput() zpozoruje, že bylo vfsmount použito více než jednou, pak je nastaven expirační čas vfsmount a jmenný prostor, který obsahuje vfsmount, má zařazenu do fronty pracovní zprávičku o vypršení.
5. Jmenný prostor struktury získal pracovní strukturu, která je používána pro expiraci vfsmountu v kontextu procesu.

Linus Torvalds neřekl, že by se mu to nelíbilo, ale před začleněním chtěl slyšet názor Alexandra Vira a ostatních. Alexander řekl:

Moc se mi to nelíbí. Když už nic jiného, tak je to podle mne špatná cesta řešení problému - když chceš, aby několik souborových systémů vypadalo jako jeden objekt (tj. aby byly pohromadě kamkoliv je připojíme, atd.), vytvoř souborový systém. To by dávalo ude mít význam a nejen pro AFS.

Potřebujeme jednoduchý automount. Bez debaty. Ale měl by být pro jednotlivé jmenné prostory - tj. "Chtěl bych na vyžádání připojit <foo> do /usr/barf a nechci to pokazit někomu jinému - někomu, kdo bude chtít vidět stejný adresář jako /usr/local/debian/barf a zde na vyžádání připojit <blah>".

Jmenný prostor je řízen svým vlastníkem. Je to bezpečnostní hranice, kromě dalších věcí. A události v jednom jmenném prostoru by neměly způsobit připojování v jiném. Ano, AFS chce iluzi jednoho souborového systému složeného daným způsobem z několika kusů. Ale jestli to chceš udělat, udělej to správně - ujisti se, že to funguje jako jedna větev v připojovacím stromu. Jinými slovy, ať to vypadá jako jeden souborový systém.

David nesouhlasil s Alexandrovým hodnocením, ale nebyly schopni vyřešit problémy v tomto vlákně.

Někde jinde pod předmětem: [PATCH] VFS autmounter support v2, David napsal:

Přepracoval jsem svůj patch, aby proces v jednom jmenném prostoru nezměnil topologii jiného (kern_automount() v tomto případě vrátí chybu, tak jako (u)mount). A jako bonus byl check_mnt() zjednodušen tak, aby bral ohled na na ukazatel jmenného prostoru, který je nyní ve vfsmount.

Taky jsem to upravil tak, že když je automaticky připojený podstrom vytvořen pomocí "mount --bind" nebo "mount --move", tak se u základu stromu smaže jeho expirační doba, tudíž se z něj stane pevná součást (dokud nebude ručne odpojena).

Ale Alexander napsal:

_Stále_ jsi to nepochopil. OK, naposledy: kern_automount() bude vždy fungovat stejně bez ohledu na to, ve kterém jsme jmenném prostoru. Možná je to OK pro AFS, ale ne pro jakékoliv jiné použití.

Žádné "použijte (u)mount pro přeuspořádání topologie" zde nepomůže - ve tvém kódu je dentry označeno a jeho využití (v kterémkoliv jmenném prostoru, v kterékoliv instanci takového fs ve jmenném prostoru) udělá vždy totéž. A to je Špatně(tm).

David znovu nesouhlasil:

Myslím, že byto mělo fungovat stejně (ale s výsledky omezenými na jmenný prostor toho, co spustilo automount), dokud správce danou část stromu nezruší (pomocí umount -l). Nemyslím si však, že se debatou s tebou kamkoliv dostanu.

A opět se v rámci vlákna neshodli.

Jinde pod předmětem: [PATCH] VFS autmounter support v3, napsal David:

Okay, ukázalo se, že skutečně nepotřebuji speciální operaci pro body automatického připojení... jak už říkal HPA, to stejné je možné pomocí follow_link() operace...

Ale budeš souhlasit s akceptací tohoto patche (nebo něco podobného)? Jsou z toho odstraněné ty automount věci, kromě dvou částí:

1. Pohodlnou funkci (__do_add_mount), kterou může modul zavolat, aby připojila vfsmount do topologie připojení v místě popsaném strukturou nameidata (které bude předáno follow_link).

   Může to být odstraněno, jestli trváš na tom, abych přehodil parametry připojení do uživatelského prostoru, aby mohlo být spuštěno připojení - pod podmínkou, že něco, co se blíží fmount() bude taky poskytnuto, takže připojování mezi jmennými prostory [inter-namespace] může být prováděno v řízených podmínkách.

2. Automatická expirace přípojného bodu. To umožní zadat kterémukoliv přípojnému bodu dobu vypršení, takže když mntput() detekuje, že vfsmount je používáno jen svým rodičem, do fronty bude zařazena zprávička, aby se zajistilo pozdější vyčištění daného jmenného prostoru od mrtvých připojení.

Byl bych rád, kdyby bylo možné každému připojení udat dobu vypršení, ale nejsem si jist, jak to nejlépe provést.

Alexander tento přístup označil za "vadný" a vlákno skončilo.

kexec pro 2.5.72 uvolněno, 3 e-maily

Andy Pfiffer oznámil:

Je dostupná sada patchů kexec pro 2.5.72. Je založena na stabilních 2.5.{67,68,69,70,71} verzích.

Tento patch byl otestován (nepočítaje inicializační problém VESA framebufferu po kexec-nutí nového jádra) na dual-procesorovém P4-1.7GHz Xeon systému.

Více informací zde.

Sjednocený kexec patch pro 2.5.72 je zde.

Asi to nebude nikoho zajímat, ale sjednocený patch pro 2.5.71 je zde.

Nestabilní 2.5.69 kexec patche od Erica Biedermana jsou dostupné zde:
http://www.xmission.com/~ebiederm/files/kexec/

Později napsal:

K dispozici je patch pro kexec v 2.5.72-mm1. Tento patch je založen na stabilní 2.5.72 verzi.

Tento patch byl zlehka otestován na dual-procesorovém P4-1.7GHz Xeon systému. Budete-li ho zkoušet a používáte VESA framebuffer, očekávejte na vaší obrazovce tmu během rebootu. ;^)

Více informací zde.

Patch je zde.

Zdroje odpovídajícího nástroje pro user-mode.

Někde jinde pod předmětem: [KEXEC][ANNOUNCE] kexec for 2.5.73 available Andy napsal:

Sada patchů kexec pro 2.5.73 je dostupná. Tato sada patchů je založena na stabilních 2.5.{67,68,69,70,71,72} verzích.

Tento patch byl testován na dual P4-1.7GHz Xeon systému, jednoprocesorovém P3-800 systému a duálním P3-866 systému. Pokračuji v sledování podivností během reinicializace VESA framebufferu (znaková konzole TTY funguje normálně), zádrhelů s kernelem ve verzi 2.5.72 na 4-cestném při přípravě reboot bufferu paměti a vytuhnutí systému při používání sériové konzole (RS232).

Více informací zde.

Sjednocený kexec patch pro 2.5.73 je zde.

Zdrojový tarball odpovídající user-mode utlitky.

Nestabilní 2.5.69 kexec patche od Eric Biederman jsou zde

Pravidla zasílání patchů, 7 e-mailů

Michael Hunold poprosil Linuse Torvaldse, aby si stáhl DVB patche z Michaelova BitKeeperového stromu, a Linus odpověděl:

Nebudu stahovat patche, opravdu chci, aby mi byly zaslány (a raději přes pár lidí, kteří se podílí na kontrole kvality a údržbě).

A jestli není údržba jasná a potřebuješ je poslat přímo mně, tak raději jako čistý text (e-maily mohou být velké, když je potřeba) za těchto podmínek:

• jeden patch na e-mail. Bez příloh a ne několich patchů jdoucích po sobě. Několik e-mailů, každý s jedním patchem a jestli jsou na sobě závislé, v hlavičce uveď něco jako:

  [DVB PATCH 1/9] Replace frobutomic counter with sequence numbers

  protože když jsou přeuspořádány e-mailovým systémem (což určitě budou), uvidím to z přehledu.

  Ta "[xxx]" syntaxe je důležitá: moje skripty tuto část automaticky odstraní a nahradí ji za "PATCH", ze zprávy pak bude:

  [PATCH] Replace frobutomic counter with sequence numbers

  protože jakmile je to jednou ve stromu, pak je již v SC řazení implicitní.

• na vrchu patche vysvětlení patche pro changelogy, abych nemusel vymýšlet vlastní, které pak nebude správně.
• Ujisti se, že tvůj mailový systém nezkazí e-maily narušením prázdných znaků (mezery na koncích řádků by měly zůstat a tabelátory zůstanou tabelátory) nebo takovými nesmysly jako je sedmibitový quoted-printable bordel.

Prosím.

John Levon poslal hacknutý skript od Grega KH, který pomáhá držet se Linusových pravidel.

Update MegaRAID ovladače, 1 e-mail

Atul Mukker oznámil:

1.18 řada ovladačů byla aktualizována na 1.18i. Tento ovladač obsahuje opravy pro management aplikace, které nefungovaly se základním 1.18f ovladačem. Další změny jsou: Kernel panikařil, když se nahrál 2.00.x MegaRAID ovladač přes 1.18h nebo dřívejší ovladače. Bylo to kvůli chybě ve starších ovladačích, které si nerezervovali region v paměti řadiče.

Tento ovladač také zahrnuje důležité změny v 1.18g a 1.18h ovladačích pro firmware handshake. Ovladač a patch pro 1.18f ovladač lze stáhnout zde.

Související články

Jaderné noviny 220
Jaderné noviny 219
Jaderné noviny 218

Odkazy a zdroje

Kernel Traffic 221

       

Komentáře

[Eagle]

Kdyz to tak ctu, tak by me docela zajimalo, jakou distribuci pouziva treba Linus, nebo Alan. Sice hodlam jeste nejakou dobu zustat u slackware, ale ... proste by me to zajimalo. PS: trizeni? nemelo by byt trideni?

[Libor Chocholaty]

což takhle řazení?

[Robert Krátký]

díky za upozorneni. opraveno.

[Robert Krátký]

díky za upozorneni. opraveno.

[Eagle]

Razeni je neco jineho nez trideni. Samozrejme nevim, co myslel autor.

[Milan Keršláger]

Určitě alespoň někdy Red Hat, protože jeho bugreporty se k různým verzím vztahují (naleznete je i v Bugzille: http://bugzilla.redhat.com). Bude to asi tím, že se zabývá enterprise záležitosmi kolem Linuxu a je zaměstnán u Red Hatu

[Ondřej]

IIRC a nic se nezměnilo, Linus i jeho manželka používají Red Hat.