Portál AbcLinuxu, 19. dubna 2024 00:52
Výchozí 4k zásobníky. Užitečnost linux-next. Ksplice, bezpečnostní aktualizace jádra bez rebootu. Btrfs 0.14, zvládá více zařízení. Aktivní začleňovací okna. Citáty: Jak to bylo provedeno? Podpora pro všechna Atheros zařízení. Vlastně ne, počkej... Pravopisy, překlepisy a gramatisy. Otázky o licencování.
Následující obsah je © KernelTrap.
22. duben, originál
Andrew Morton reagoval na začleňovací zprávu, ke commitu, který nastavuje 4k zásobníky jako výchozí: Tenhle patch způsobí, že jádra budou padat. Ingo Molnár odpověděl: Která jádra z hlavní řady padají a jak budou padat? Fedora i další distra mají povolené 4k zásobníky už roky. Provedli jsme desítky tisíc bootovacích testů s povolenými všemi možnými ovladači a jadernými volbami a ještě jsme neviděli žádný pád, za který by mohly 4k zásobníky. Během dlouhé diskuze bylo naznačeno, že kombinace nfs+xfs+raid a používání ndiswrapperru jsou nejběžnější důvody pro přetečení zásobníku o velikosti 4k.
Andi Kleen zpochybnil užitečnost 4k zásobníků: Ať nad tím přemýšlím, jak chci, nestojí to za to. Možná by stály za použití na mizerných VM z jader 2.4, ale ty časy jsou dávno pryč. Arjan van de Ven řekl, že i když je VM v řadě 2.6 o mnoho lepší než v 2.4, fragmentace s 8k zásobníky zůstává neřešitelným problémem. Jsou to kupecké počty - VM v Linuxu se musí potýkat s dlouho i krátce trvajícími alokacemi bez ohledu na to, jak moc se snažíme udržet určitou úroveň fragmentace; obzvlášť díky 15:1 akceleraci, která nastane kvůli problémům s dolní pamětí [lowmem]. A předtím, než řeknete 'měl bys na takových strojích použít 64bit' - byl bych moc rád, kdyby víc lidí používalo 64bitový Linux. Bohužel rychlost přechodu na něj zdaleka není dobrá.
V jiném e-mailu Arjan vyjmenoval dvě výhody 4k zásobníků: 1) menší spotřeba paměti v oblasti dolní paměti [lowmem zone] (kritické pro podnikové využití a také pro všeobecnou výkonnost) a 2) jaderné zásobníky o 8k patří mezi nejvýznamnější jaderné alokace řádu 1; opět je problém fragmentace v dolní paměti v systémech s velkou pamětí (a distra, která se vydávají se 4k zásobníky, to dělají kvůli stížnostem zákazníků)
Kdo dělal to reverzní inženýrství a jak to udělal? Prosím ujistěte nás, že naše zadky nebude nikdo tahat po soudech nebo tak něco.
Andrew Morton, zpráva z 13. dubna 2008 na Linux Kernel mailing list.
23. duben, originál
V diskuzi o nedávnému rozbití stromu linux-next Stephen Rothwell napsal, že problému si nikdo nevšiml, protože arm strom momentálně není začleňován, to je důvod, proč bych byl rád, aby ses podílel na stromu linux-next. Správce arm architektury Russell King zpochybnil užitečnost: Linux-next mi nedává nic, co by mi nedal -mm. Jak jsem řekl v diskuzi, hodnota linux-next je pro mě velmi malá. Omlouvám se, ale je to tak. V reakci na to se ozvali někteří další a zmínili několik důvodů, proč je strom linux-next užitečný.
Andrew Morton psal: Vložení arm do linux-next znamená, že Stephen (a git) zvládnou začlenění místo toho, abych to musel dělat já (a ne-git). To pomáhá mě. Očekávám, že linux-next se bude testovat cross-kompilací mnohem důkladněji než -mm. To pomůže tobě.
Greg KH dodal: Vložení tvých věcí do linux-next by ostatním poskytlo veřejné místo, kde vzít základní bod. Tím se jim zjednoduší posílání patchů, protože se zajistí, že se aplikují správně. To nakonec pomůže ostatním snadněji přispívat a tobě to pomůže tím, že ti budou posílat patche, u kterých nebudeš muset měnit základ stromu sám [rebase].
Stephen Rothwell shrnul výhody pro správce: Pětkrát týdně se tvůj strom slučuje se spoustou dalšího kódu, který je určen pro Linusovo další vydání. Z toho potom musíš zjistit, které věci v ostatních stromech kolidují s tvými. Linux-next se překládá pro několik architektur a konfigurací (včetně arm), takže přijdeš na to, když věci v ostatní stromech rozbijí tvoje. Jsem rád, že překládám víc (prakticky všechny) configy pro arm tak, jak jsem nabízel dříve.
Píšu, abych vás informoval, že jsem se rozhodl přijmout u Atherosu práci na plný úvazek jako softwarový inženýr, abych jim pomohl v jejich cíli podporovat každé Atheros zařízení v upstreamu v Linuxu.
Luis Rodriguez, zpráva z 16. dubna 2008 na ath5k development mailing list.
25. duben, originál
Dal jsem dohromady automatický systém pro aplikování jaderných bezpečnostních patchů bez restartu jádra a chtěl bych tento systém nabídnout komunitě pro případ, že by pro někoho byl zajímavý a hodil se mu, psal Jeff Arnold v oznámení ksplice. Vstupem pro tento systém je jaderný bezpečnostní patch (což může být unifikovaný diff převzatý přímo z Linusova GIT stromu) a zdrojový kód odpovídající běžícímu jádru. Automaticky se pak vygenerují moduly, které provedou update. Běžící kernel nemusí být žádným způsobem upravován předem.
Webová stránka projektu k tomu poznamenává: Ksplice nedokáže zvládnout sémantické změny datových struktur - tj. změny, které by vyžadovaly transformaci existujících instancí jaderných datových struktur. I s tímto omezením by však podle Jeffa ksplice byl schopný automaticky aplikovat 84 % jaderných bezpečnostních patchů uvolněných mezi květnem 2005 a prosincem 2007. Jeff dále řekl:
O tento projekt jsem se snažil, protože nerad dělám rebooty pokaždé, když je objevena lokální bezpečnostní slabina jádra. Postupy/systémy pro aktualizace bez rebootu, které se používají, vyžadují ruční sestavení aktualizace (což je proces, který může být ošidný a náchylný k chybám) a mívají i další nevýhody (jako potřebu vlastního jádra, špatného zpracování inline funkcí atd.). Tento nový systém funguje na existujících jádrech a jako vstup jednoduše bere unifikovaný diff, zbytek udělá sám.
To proto, že tě nenávidím. Vlastně ne, počkej, to proto, že mně jsi ten patch neposlal.
Linus Torvalds, zpráva z 26. dubna 2008 na Linux kernel mailing list.
30. duben, originál
Btrfs 0.14 je nyní dostupný ke stažení, oznámil Chris Mason, prosím, berte na vědomí, že diskový formát se změnil a je nekompatibilní se staršími verzemi btrfs. Projekt získal novou domácí wiki stránku v doméně kernel.org, kde je popsán: Btrfs je nový souborový systém typu kopírování při zápisu. Je určen pro Linux a zaměřen na implementaci pokročilých vlastností při zachování tolerance chyb, možnosti opravy a jednoduché administrace. Původně byl vyvinut Oracle, nyní je Btrfs uvolněn pod licencí GPL a otevřený příspěvkům od kohokoliv.
K nejnovější verzi Chris řekl: v0.14 obsahuje několik oprav výkonnosti a uzavírá několik souběhů [race condition], které by mohly vést k poškození metadat ve v0.13. Hlavní novou velkou vlastností je schopnost spravovat několik zařízení [multiple devices, MD] pod jedním Btrfs připojením [mount]. Podporovány jsou RAID0, RAID1 a RAID10. A i pro souborové systémy na jednom zařízení jsou metadata ve výchozím nastavení duplikována. Po dokončení čtení jsou ověřovány kontrolní součty a pokud nesouhlasí, použijí se kopie.
Chris nabídl odkazy na benchmarky pro více zařízení a shrnul: Obecně tato čísla ukazují, že Btrfs při této konfiguraci úložných zařízení dobře škáluje a stejně dobře se vyrovnává jak s HW raidem, tak s MD. Zprávu zakončil pohledem do budoucnosti: Další položkou na TODO seznamu Btrfs je dokončení odstranění zařízení a kód pro řešení I/O chyb. Poté přidám jemnější zamykání do b-stromů.
Nerad začleňuji patche, které opravují pravopisy, překlepisy a gramatisy, jednoduše proto, že bych tím byl zavalený. Takové opravy beru jenom v textu viditelném pro uživatele (Documentation/, komentáře v kerneldoc a printk výpisy).
Andrew Morton, zpráva z 14. dubna 2008 na Linux kernel mailing list.
2. květen, originál
Tohle pro mě začíná být víc než frustrující, stěžoval si David Miller na nejaktuálnější začleňovací okno, čímž začal velmi dlouhou a ještě pokračující diskuzi o vývojovém procesu linuxového jádra.
Koncept pravidelného "začleňovacího okna" byl poprvé diskutován v červenci 2005 při vydání jádra 2.6.14-rc4 po summitu vývojářů v roce 2005. Od 2.6.14 dále je vydání každého oficiálního 2.6.y jádra následováno čtrnáctidenním obdobím, během kterého se do něj začleňují významné změny, potom vychází 2.6.y-rc1.
David si stěžoval, že toto konkrétní začleňovací okno je horší než ostatní: Strom se každý den rozbije a jako prostředí pro práci je to čím dál tím méně zábavné. Potřebujeme zpomalit začleňování, potřebujeme věci více revidovat, potřebujeme, aby lidi testovali své [...] věci!
Během dlouhé diskuzi tvůrce Linuxu Linus Torvalds napsal:
Názor, že bychom se měli vůbec pokusit věci zpomalit, považuji za pravděpodobně nesprávný a ani nechápu, proč by to někdo považoval za logický cíl. Samozřejmě - když bude méně změn, bude méně chyb. To ale není cíl, to je tautologie a naprosto nezajímavá. Malý program pravděpodobně bude mít míň chyb, ale to, že je něco malé, ještě neznamená, že je to 'lepší' než něco, co je větší a umí víc.
Stejně tak stagnující komunita vývojářů bude méně často zanášet nové chyby. Ale bude ta stagnující lepší než komunita kypící aktivitou? To ani omylem. Takže neříkám, že bychom se měli snažit o horší kvalitu, ale dávám argumenty proti falešné dichotomii - víře, že kvalita je nekompatibilní se spoustou změn.
Otázky o licencování by se měly pokládat spíše právníkům, ne programátorům. Položil bys náhodné skupině právníků ve veřejné mailové konferenci medicínskou otázku a věřil bys pak jejich odpovědi?
Greg KH, zpráva z 29. dubna 2008 na Linux kernel mailing list.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.