30.3.2008 12:20
Petr (DotaZ) Jakubec | skóre: 5
Rozbalit Rozbalit vše suspend to disk
Portál AbcLinuxu, 5. května 2025 19:03
Sledování nadcházejících začlenění do stable jádra. 2.6.25-rc2, "vítěz". Lokální cache pro síťové filesystémy. Cesty uspání na disk a do paměti. 2.6.25-rc3, "užijte si ho". NDISwrapper a GPL. 2.6.25-rc4, "slušné množství malých změn".
Následující obsah je © KernelTrap.
14. únor, originál
Andrew (Morton) hledal někoho, kdo by vedl strom linux-next, který by obsahoval jenom subsystémové gitové stromy a quilty pro 2.6.x+1, a já (v chvilkovém pomatení smyslů) jsem se přihlásil dobrovolně. Takže tohle je oznámení o vzniku toho stromu, začal Stephen Rothwell zprávu, která vedla k dlouhé diskuzi o současném vývojovém procesu Linuxu. V následujícím emailu, který oznamoval první vydání linux-next, Stephen objasnil účel tohoto stromu: Má dvě větve - master a stable. Stable je momentálně jen Linusův strom a nikdy nebude měnit základní bod [rebase]. Master bude měnit základní bod téměř denně (možná v začátcích pomaleji). Potom uvedl další detaily o master větvi:
Strom master se skládá ze subsystémových gitových stromů a quiltů. V současnosti jsou quiltové stromy integrovány importováním do gitových větví s odpovídajícím základním bodem a poté sloučením těchto větví. To má tu výhodu, že řešení konfliktů stačí provést jednou při slučování, místo několikrát během série. Nicméně zvažuji pouhé aplikování quiltových stromů na současný strom tak, abych získal výsledek podobný Linusovu stromu - uvidíme. Gitové stromy jsou zjevně jenom sloučené.
Jedním z cílů nového stromu je to, aby se správci subsystémů více zapojovali do řešení konfliktů při slučování tak, že budou rychle informovat všechny, kterých se to týká, a automaticky zahodí provinilce do doby, než se problémy vyřeší. Andrew na tomto stromu plánuje založit svoje nové -mm jádro, čímž poskytne stabilnější testovací větev pro kód předtím, než bude začleněn do Linusovy hlavní řady jádra.
U FS je spousta věcí, nad kterými je potřeba se hluboce zamyslet, ale perfektní systém, jak využít prvních 64 k na 1TB souborovém systému, není v tuto chvíli zrovna na čelní příčce mého seznamu.
Chris Mason, zpráva z 12. února 2008 na Linux file system development mailing list.
16. únor, originál
Ok, tohle jádro je vítěz, začal Linus Torvalds oznámení o 2.6.25-rc2, který získal jméno Funky lasička kolem něj křepčí.
Abych ukázal, jak moc je tohle jádro vítězem, bylo oceněno vytouženou sérií jmen s lasičkou, což by vám mělo říct, jak dobré bude. To jméno je v historii jádra Linuxu velmi ctěno a jako takové přináší ty staré dobré časy, kdy když jste našli chybu, téměř určitě jste se zmýlili a pravděpodobně jenom udělali něco špatně. Ale co, můžete zkusit dokázat, že se pletu. Zkuste to.
Linus pokračoval popisem některých změn pomocí git dirstat: Při podrobném pohledu se ukazuje, že téměř přesná polovina aktualizací je v ovladačích, kde samotné síťové ovladače zabírají třetinu celého patche. Polovina ze zbývající poloviny jsou aktualizace v architekturách, zejména SH. Jsem optimista a doufám, že tento vývojový cyklus nebude ani trochu takový porod jako 24, což je důvod, proč mizím na prodloužený víkend a zůstanu na pláži.
Naprosto upřímně: jestli kgdb začne dělat něco 'zajímavého', v žádném případě ho nezačlením.
Linus Torvalds, zpráva z 12. února 2008 na Linux kernel mailing list.
21. únor, originál
Tyto patche přidávají lokální cache pro síťové souborové systémy, jako je NFS, začal David Howells, když popisoval aktualizovanou sadu třiceti sedmi patchů, které zavádějí FS-Cache. Když byl dotázán, jak tyto patche ovlivňují výkon, odpověděl, že to závisí na situaci. Nejvíce se objevují problémy, když se pracuje s velkým množstvím metadat: Získání metadat z lokálního souborového systému na disku je pomalejší, než stáhnout si je z nesdíleného gigabitového ethernetu ze serveru, který je již má v paměti.
Tyto případy neznamenají, že fscache je k ničemu, ale to, že je potřeba pečlivě zvážit, jestli se hodí právě "vám" ve vaší konkrétní situaci, což závisí na mnoha faktorech. Pak ještě dodal, že momentálně je FS-Caching zakázán pro jednotlivé NFS soubory otevřené pro zápis, protože neexistuje způsob, jak ošetřit problémy s koherencí, které se tím zavádějí. David zprávu uzavřel několika jednoduchými benchmarky výkonu.
Jestliže nevidíš etický problém v tom, že odstraníš fungující ovladač, protože ho nikdo nepodporuje, abys lidi donutil testovat a ladit ovladač, který nepotřebují a nepotřebovali by, aby nakonec nabízel stejné funkce jako ten, který už byl k dispozici... pak tě asi nepřesvědčím, že technologické vydírání je zlo.
Bill Davidsen, zpráva z 16. února 2008 na Linux kernel mailing list.
22. únor, originál
Problémy hlášené během procesu uspání na disk [suspend-to-disk] vedly Linuse Torvaldse k návrhu: Prosím, předělejte to zas*ané uspávání na disk tak, aby používalo jiné rutiny. 99 % hardwaru nepotřebuje při uspání na disk dělat vůbec nic. A ten zbytek, který něco dělat musí, toho obyčejně nepotřebuje dělat nijak moc. Pokračoval vysvětlením, proč je sdílení kódu mezi uspáním na disk a do RAM špatné:
Například uspání do paměti by pro USB (což je pro uspávání jedna z nejsložitějších záležitostí) mělo znamenat doslova něco takového, jako nastavit STOP bit řadiče a počkat, až se zastaví. Probuzení z paměti by pak mělo jenom vynulovat ten bit, zatímco probuzení z disku by mělo vyresetovat řadič tak, aby použil současný obraz paměti. NIC Z TOHO NEMÁ ABSOLUTNĚ NIC SPOLEČNÉHO S USPÁVÁNÍM NA DISK. Nikdy nemělo a říkal jsem to už několik let. Možná že teď, když všichni vidí problémy, si to lidé konečně uvědomí.
Linus také zmínil další výhodu toho, když tyto dvě akce budou mít oddělené kódové cesty [code paths]: Další záležitost, kterou jsem chtěl vyřešit už dávno, je zajistit, aby, když někdo opraví chybu v uspání do RAM, nezmršil zároveň uspání na disk a obráceně. Během diskuze Rafael Wysocki napsal, že to brzy opraví: Už jsi mě přesvědčil, opravdu :-).
Není to nerozumné. To není ani aristotelovská fyzika. Nicméně ani jedno se příliš neshoduje s realitou.
Alan Stern, zpráva z 16. února 2008 na Linux kernel mailing list.
27. únor, originál
Ok, je venku, užijte si ho, napsal Linus Torvalds, když oznamoval jádro 2.6.25-rc3.
Jako vždycky je většina aktualizací v ovladačích a v architekturách, dirstat ukazuje okolo 37 % změn v arch (a to je se zapnutou detekcí přejmenování: v arch/xtensa bylo nějaké přesouvání souborů, které by podíl zvedlo na 43 %, kdybyste se na to podívali jako na tradiční diff) a 50 % v ovladačích. Aktualizace v ovladačích jsou z větší části rozdělené rovnoměrně, nicméně část pochází z pár nových ovladačů: mvsas SCSI ovladač, nový ovladač adt7473 a pár nových watchdog ovladačů.
Linus pokračoval: Když budete ignorovat pro architektury specifické záležitosti a ovladače, je zbytek převážně v síťování, nějaké aktualizace dokumentace a pár aktualizací filesystémů (hlavně efs a xfs). Závěr toho všeho? Zcela upřímně, změny jsou všude. Změny v -rc3 jsou větší než v -rc2 pravděpodobně proto, že jsme měli víc času (-rc2 byla vydána o několik dní dříve kvůli prodlouženému víkendu ve Spojených státech), ale snad také proto, že lidé začali nacházet regrese.
Z oprav chyb zdůraznil: Měli jsme v -rc2 ošklivý problém s poškozením SLUBu, který je opraven (pravděpodobně ho moc lidí ani nevidělo) a doufejme, že jsme také opravili mnoho regresí v síťování a suspend/resume.
'tmp' je otřesný identifikátor a přejmenování na 'temp' to sotva vylepší.
Andrew Morton, zpráva z 15. února 2008 na Linux kernel mailing list.
3. březen, originál
Kvůli změně po 2.6.24 přestal fungovat ndiswrapper, protože byl odstraněn jeho přístup k pouze-GPL symbolům, napsal Pavel Roskin a nabídl patch, který měl problém opravit. Na Linuse to moc nezapůsobilo: Nevidím důvod, proč by se s ndiswrapperem mělo zacházet jinak než s ostatními. Jestliže nahrává ne-GPL moduly, tak by neměl být schopen používat pouze-GPL symboly.
Domovská stránka projektu NDISwrapper to vysvětluje takto: Mnoho výrobců ke svému hardwaru neuvolňuje specifikace ani neposkytuje linuxový ovladač pro své bezdrátové síťové karty. Tento projekt implementuje API jádra Windows a NDIS (specifikace rozhraní pro síťové ovladače [Network Driver Interface Specification]) API do jádra Linuxu. Ovladač bezdrátové síťové karty pro Windows je poté slinkován s touto implementací, takže běží nativně, protože si myslí, že běží ve Windows, bez binární emulace. K tomu Linus napsal:
Ndiswrapper sám o sobě není kompatibilní s GPL. Snažit se tvrdit, že z nějakého důvodu je kompatibilní s GPL, i když potom nahraje moduly, které nejsou, je stupidní a zbytečné. Zcela jasně prostě přeexportovává tyto pouze-GPL funkce kódu, který není GPL.
Nvidia potřebuje opravit svůj kód. Jestliže je to pro ně problém, možná by ten kód měli uvolnit pod GPLv2 kompatibilní licencí, abychom jim mohli ukázat, jak to udělat.
Chris Snook, zpráva z 28. února 2008 na Linux kernel mailing list.
5. březen, originál
Je o pár dní opožděné, ale čekal jsem s vydáním na několik oprav pro ty nejotravnější regrese, takže konečný výsledek je snad použitelnější, začal Linus Torvalds oznámení jádra 2.6.25-rc4. Poskytl dirstat shrnutí a poznamenal: Dirstat ukazuje, že (jako obvykle) je nejvíc změn v ovladačích a v architekturách (~51 % a ~17 % v uvedeném pořadí), přičemž okolo poloviny aktualizací ovladačů se týká sítí.
Zvláště změny v blokové vrstvě by se měly ustálit a lidem už snad zase bude fungovat vypalování CD a podobně. To samé platí pro regrese plánovače a množství otravných problémů při bootování. [...] Skutečně se jedná o slušné množství malých změn rozprostřených po celém jádře, přičemž většina z nich je celkem malá (604 commitů, většina je malá; pouze síťový ovladač BNX2X a nový ovladač fsldma se změnily výrazněji).
Wow, tohle opravdu funguje? Jestli jo, tak to bez problémů začlením.
Rusty Russel, zpráva z 2. března 2008 na Linux kernel mailing list.
A ten zbytek, který něco dělat musí, toho obyčejně nepotřebuje dělat nijak moc.Tady to chtělo nechat "nepotřebuje udělat úplně všechno". Ta úprava mění význam toho, co Linus řekl a o co v jeho příspěvku jde.
Tady to chtělo nechat "nepotřebuje udělat úplně všechno". Ta úprava mění význam toho, co Linus řekl a o co v jeho příspěvku jde.Jak si to tak čtu znovu a znovu a koukám na Linusův krkolomný slovosled ("tend to need to not do"), tak si říkám, že jsme asi oba vedle a bylo tím možná myšleno "obyčejně potřebují, aby se toho nedělalo moc". Takovému významu se mi však zprvu nechtělo věřit, protože to není vůči danému kódu moc lichotivé. Pokud se ovšem Linus nespletl a nechtěl ve skutečnosti napsat "tend not to need to do" (to mi stále připadá nejpravděpodobnější). Pak by platil můj první překlad, protože aby to znamenalo "úplně všechno", muselo by být v originále "the whole lot" ("Apples, oranges, the whole lot", tj. "Jabka, pomeranče, prostě všechno"). Jelikož je tam však "a whole lot", tak to znamená "nic moc" či něco podobného ("I don't think it matters a whole lot", tj. "Myslím, že na tom zas tak moc nezáleží").
akce 1 (nutná jen pro uspání do RAM) akce 2 (nutná jen pro uspání do RAM) akce 3 (nutná jen pro uspání do RAM) akce 4 (nutná jen pro uspání do RAM)To je první část té věty "99% of all hardware needs to do exactly *nothing* on suspend-to-disk" - 99% HW nepotřebuje při uspávání na disk nic dělat (ale přesto to dělá, protože se používá stejný kód) Druhý příklad - zařízení Z2
akce 1 (nutná jen pro uspání do RAM) akce 2 (nutná jen pro uspání do RAM) akce 3 (nutná jen pro uspání do RAM) akce 4 (nutná pro uspání do RAM i na disk)To je druhá část té věty - "and the ones that really do need things tend to need to not do a whole lot.", tedy ten zbytek, který při suspendu na disk něco dělat potřebuje (zde akce4), nepotřebuje dělat úplně všechno (tedy z těch 4 akcí nepotřebuje udělat 1,2,3). Když se napíše, že "nepotřebuje udělat nijak moc", tak se tam tahle informace ztrácí.
${SUBJECT}?
K tomu Linus napsal: Ndiswrapper sám o sobě není kompatibilní s GPL. Snažit se tvrdit, že z nějakého důvodu je kompatibilní s GPL, i když potom nahraje moduly, které nejsou, je stupidní a zbytečné. Zcela jasně prostě přeexportovává tyto pouze-GPL funkce kódu, který není GPL.Achjo, uz je to tady zase.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.