11.10.2005 05:55
David Watzke | skóre: 74
| blog: Blog...
| Praha
Rozbalit Rozbalit vše ...
Portál AbcLinuxu, 8. května 2025 07:59
Pár rad pro upgrade z 2.4 na 2.6. DevFS má stále hlavu na špalku; uživatelé se brání. Zpřístupnění NUMA dat uživatelskému prostoru. Umístění patchů čekajících na -stable jádro.
8. zář - 9. zář
Weber Ress měl vést tým techniků při upgradu jader z 2.4 na 2.6 na mnoha serverech. Požádal o rady a Michael Thonke připomněl: Google je tvůj nejlepší přítel a první zdroj informací. Ještě přidal odkaz na článek Williama von Hagena o tomto tématu. Jesper Juhl napsal:
Provádím upgrady mnoha kernelů, takže ti povím trochu o tom, jak to dělám a co doporučuji. Pak si s těmi informacemi nalož dle libosti :)
Úplně nejdříve se přesvědč, jestli jsou všechny základní utility/nástroje aktualizované na verze, které budou fungovat s novým jádrem.
Když stáhneš zdrojové kódy jádra 2.6.13, rozbal je a podívej se do souboru Documentation/Changes. Najdeš tam seznam nástrojů a utilit s uvedenými minimálními verzemi, které jsou vyžadovány pro správnou funkci s daným jádrem.
Až budeš mít aktualizované základní utility, musíš zkontrolovat, jestli budou s novým jádrem také fungovat všechny další důležité programy, které v systému máš.
Jakmile si budeš jistý, že je všechno aktualizované tak, aby to fungovalo s novým jádrem, můžeš 2.6.13 zkompilovat a nainstalovat. Není nutné odstraňovat stávající jádro, 2.6.13 můžeš nainstalovat vedle starého a zkusmo s ním nabootovat. Kdyby nenaběhlo, můžeš se vrátit ke starému.
Pro svou distribuci pravděpodobně najdeš v dokumentaci, která verze je "připravena na 2.6". Já používám Slackware a Slackware 10.1 je kompletně připraven na 2.6, takže na systému se Slackware 10.1 je vše snadné. Stačí nainstalovat nové jádro místo 2.4 a je to - všechny nástroje si s tím poradí.
9. zář - 14. zář
Greg KH, kterému nebylo umožněno odstranit DevFS před vydáním verze 2.6.12, poslal stejné patche oproti 2.6.13; doufal, že tentokrát už se na ně dostane: Pokud by někdo opravdu moc chtěl devfs v jádře, poslal jsem patch, který to zařídí v 300 řádcích - ndevfs. Chcete-li jej používat, najdete ho v archívech (je snadné ho spravovat mimo strom jádra, protože potřebuje jen 3 háčky [hooks] do hlavního jádra). Mike Bell odpověděl, že NDevFS je designově vadné. Vytváří pro zařízení zase další názvosloví. A co je horší, nefungují kvůli tomu zařízení jako ALSA a vstupní subsystém, jejichž umístění jsou natvrdo určená v knihovnách. Pokud nebude sysfs dostávat atributy, ze kterých půjdou odvodit skutečné názvy, nebude to fungovat. Greg připustil, že NDevFS není pěkné řešení, ale jen alternativa. A dodal: Kromě toho to vůbec nenabízím k začlenění do jádra, ale pouze jako důkaz pro ty, kteří tvrdí, že není možné snadno spravovat sadu patchů typu devfs mimo jádro.
Jinde řekl David Lang, že při odstraňování DevFS je potřeba být opatrný, protože hodně systémů by mohlo přestat fungovat. A Greg se zeptal: Ok, jak dlouho bych měl čekat? A David napsal:
Kdyby byla ve verzi 2.6.13 odstraněna konfigurační volba, pak by podle mě měl kód zůstat do 2.6.15 nebo 2.6.16 (pokud budou nové verze každé dva měsíce, muselo by to být .16). Zvláště když se tolik lidí bojí řady 2.6, je nutné počkat alespoň jeden celý vývojový cyklus, spíš dva (a možná více, budou-li krátké) a potom dát pryč zbytek kódu v další verzi.
Nezapomínej, že distribuce nebalí všechna jádra. Přeskakují verze a dokud je nevyzkouší, nebudou vyřešeny všechny problémy.
K tomu připočti, že je dost lidí zmatených číslováním verzí, takže protože je 13 liché číslo, považují 2.6.13 za testovací jádro a 2.6.14 za stabilní - na .13 se tedy nepodívají.
Tohle všechno za předpokladu, že již byly vyřešeny problémy, které měli lidé se sysfs - nedokázalo nahradit funkce používané s devfs.
Vlákno skončilo bez jasného rozhodnutí o tom, jak dlouho ještě bude DevFS v jádře.
10. zář
Andi Kleen napsal:
Právě jsem si všiml, že byl začleněn ten hnusný kód /proc/*/numa_maps od SGI. Několikrát jsem proti němu argumentoval a záměrně jsem podobnou funkčnost nepřidal při psaní kódu NUMA metod, protože nejde o dobrý nápad.
Mohl by být ten patch odstraněn, prosím?
Andrew Morton řekl, že do fronty zařadil odstranění patche. Christoph Lameter měl ale pocit, že patch není beznadějný, a nechápal, proč by měl být vrácen. Andrew odpověděl: Je-li užitečný vývojářům aplikací, pak fajn. Je-li však užitečný jen pro vývojáře jádra, pak je argument slabší. V té oblasti však stále probíhá dost vývoje, takže pořád existuje důvod takovou monitorovací funkci v hlavním jádře mít. Christoph reagoval:
Pořád se mi nedaří pochopit, jak mohou lidi přijmout argumentaci, která říká:
Uživatelé nemají právo vědět, které uzly [nodes] operační systém alokoval pro proces, a také nemají vědět, jak se na oblastech paměti projeví práce s pamětí.
Vývojáři aplikací pak musí hádat, jaký vliv má práce s pamětí na alokaci paměti. Při debuggování alokování paměti si dnes ti chudáci musí představit, co operační systém provádí. Prostřednictvím jiných záznamů v /proc vidí celkové množství paměti alokované na uzlu a pak na základě toho hádají, která aplikace si ji zabrala. Pak své aplikace upraví a zkusí to znovu.
V současné době mám za to, že by bylo lepší ponechat /proc/<pid>/numa_stats místo používání smaps, protože formát smaps je trochu ukecaný a bylo by těžké z něj vyčíst rozdělení alokace. Pokud použijeme smaps, bude asi potřeba nějaký nástroj, který by údaje zpracoval a prezentoval. numa_stats lze použít rovnou.
Přinejmenším potřebujeme mít možnost vidět, co se děje.
Samozřejmě bychom byli radši, kdyby bylo možné měnit pravidla, která ovládají alokaci paměti. Argument, který říká, že vrstva to není schopná řešit, je pochopitelně pravdivý, protože pokusy o napravení těchto záležitostí byly zablokovány.
Andrew se začínal přiklánět k uznání této argumentace a ponechání patche, ale debata se nedobrala žádného jasného rozhodnutí.
13. zář - 14. zář
Jean Delvare se zeptal:
Je někde možné vidět patche navržené pro jádro -stable?
Jsou emaily posílané do stable@kernel někde archivovány?
Řekl bych, že by to bylo vhodné. Já bych například uvítal začlenění jednoho patche do 2.6.13.2, ale nechci hlásit již známý problém.
Michal Piotrowski poslal odkaz na zkrácený log fronty pro -stable a Jean odpověděl: Přesně to jsem potřeboval, už to mám v záložkách. Díky.
V originálu Kernel Traffic 328 vyšla navíc ještě tato témata:
Tento článek vychází ze seriálu Kernel Traffic (www.kerneltraffic.org) a je zveřejněn pod licencí GPL verze 2.
2.6.13-gentoo-r3, tak na konci kompilace řval, že DevFS už je pryč a mně je to jedno, protože:
nove veci se maji nasazovat tehda, kdyz maji stejnou nebo vyssi funkcnost, nemyslis?A proc je teda sam nasazujes, hm?
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
11.10.2005 07:36
11.10.2005 10:15