Kernel Traffic #221 For 30 Jun 2003

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í.

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.

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.

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.

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ž poškozovalo 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.

"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á...]!

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...

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.

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.

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).

_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).

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.

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.

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/

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.

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

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 třízení 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.

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.