Portál AbcLinuxu, 25. dubna 2024 13:27
Aktuální verze jádra: 3.15-rc4. Citáty týdne: David Miller, Josh Triplett, Alan Cox, Greg Kroah-Hartman. Vyšel GlusterFS 3.5. Možný odchod remap_file_pages(). Síťování na drobných strojích: Zmenšování síťové vrstvy; Měli bychom to vůbec zkoušet?
Aktuální vývojová verze jádra je 3.15-rc4 vydaná 4. května. Linus říká: Několik známých problémů ještě čeká na opravu (například zajímavé poškození seznamu dentries – při normálním používání byste na to ale nenarazili), obecně to ale probíhá v poklidu a nic mě neděsí. Jsme v půli období zklidnění a tak to mám rád.
Stabilní aktualizace: verze 3.14.3, 3.10.39 a 3.4.89 vyšly 6. května s obvyklou dávkou důležitých oprav.
Každá nová kombinace v konfiguraci je novou situací, která při testování konkuruje ostatním.
-- David Miller
Okolo patchů udržovaných mimo strom oprávněně panuje jisté stigma, ve kterém jde přibližně o to, že „lidé by měli patche předávat do upstreamu, patche mimo strom bychom neměli podporovat a ani se o ně starat“. Ale to funguje, jen pokud reagujeme na zaslané patche slovy „Ne, protože musíš opravit X, Y a Z“ nebo „Ne, protože vašemu případu užití lépe poslouží stávající mechanismy, co už v jádře jsou“, nikoliv však „Ne, váš případ užití není validní“.
Pokud používáte glibc a nástroje GNU, tak to nebude fungovat, ale před dlouhou dobou byly napsány nástroje, které odváděly právě tu práci, co měly, a byly drobné a čisté. Programátoři měli k jejich kombinaci za složitějšími úkoly používat shellové skripty, než aby to bylo tak, že jednou za rok někdo na světě spustí nějakou hloupost od GNU jako --naformátuj-na-bok-a-zpívej --melodie=matyldin-valčík.
-- Alan Cox
Co se ohlašování [dlouhodobě udržovaných stabilních vydání] předem týče, už to nikdy neudělám, následky byly hrozné, jelikož tam lidé cpali věci, které tam nemají být. Dokonce jakmile lidé vědí, z kterých verzí budou enterprise jádra, tak začnou do upstreamu cpát věci „předem“, takže se tento problém opakuje.
Vyšel GlusterFS ve verzi 3.5. Mezi nové funkce patří lepší logování, možnost pořizovat snapshoty jednotlivých souborů (zatím není možné dělat snapshoty celých jednotek), komprese při přenosu, šifrování na disku a lepší podpora geo-replikace.
Systémové volání remap_file_pages() je taková podivnost; umožňuje procesu vytvořit složité, nelineární mapování mezi svým adresním prostorem a příslušným souborem. Takového mapování lze dosáhnout i pomocí několika volání mmap(), ale náklady na straně jádra jsou pak vyšší: každé volání mmap() vytvoří v jádře oddělenou oblast virtuální paměti (VMA), zatímco remap_file_pages() si vystačí s jedinou. Pokud má v sobě mapování velké množství skoků, pak může být rozdíl na straně jádra významný.
remap_file_pages() má ale malé množství uživatelů. Je jich tak málo, že Kirill Shutemov poslal patch, který volání zcela odstraňuje. Říká: Nelineární mapování se těžko podporují a jelikož jsou teď 64bitové systémy běžně dostupné, tak to vypadá, že už nejsou žádné legitimní případy užití." Patch zatím nenavrhuje k začlenění, je to zatím jen koncept.
Není těžké pochopit, proč je tato změna zajímavá; odstraňuje z jádra přes 600 řádek záludného kódu. K odstranění ale nedojde, pokud se bude považovat za porušení ABI. Někteří jaderní vývojáři evidentně věří, že si odstranění remap_file_pages() nikdo nevšimne, ale od dojmu k potenciálnímu rozbití aplikací vede dlouhá cesta. Proto se mluví o přidání varování; Peter Zijlstra navrhl jít o krok dál a vyžadovat pro aktivaci systémového volání nastavení volby přes sysctl. To by navíc pomohlo zjistit, jestli by se současní uživatelé remap_file_pages() ozvali; když se ozvou hned, předejdou tak problémům v budoucnosti.
Zaslání patche zmenšujícího jádro vyvolalo rozsáhlejší debatu o tom, co se musí s jádrem udělat, aby se vešlo na drobné systémy, ale také o tom, jestli jde vlastně o něco, o co se chce komunita vůbec pokusit.
Šlo o patch o 24 částech od Andiho Kleena, který přidává do sestavování možnost sestavit minimalistický síťový subsystém. Andiho zajímá možnost běhu Linuxu na systémech s pouhými 2 MB paměti; na těchto systémech, když síťová vrstva v Linuxu představuje zátěž 400 KB jen pro základní podporu IPv4, je problém něco takového mít. Odstraněním řady funkcí, změněním některých datových struktur a používáním LTO k odstranění nepotřebného kódu se Andimu podařilo kód zredukovat na 170 KB. To vypadá jako užitečné zlepšení, ale jak brzy uvidíme, cesta do jádra nebude úplně hladká.
Mezi změny v Andiho patchi patří:
Výše uvedený výčet by mohl být kratší, ale asi vám už je jasné, jak to dopadlo: patch nebyl komunitou okolo síťování přijat s otevřenou náručí. Tato komunita je silně zaměřená na výkon a funkce současného hardwaru; síťoví vývojáři (nebo alespoň někteří z nich) nechtějí být obtěžováni výzvami, které přináší podpora uživatelů na drobných systémech. Eric Dumazet to shrnul slovy:
Kdysi jsem začal používat Linux na počítačích typu 386/486, které měly více než 2 MB paměti, takže jsem smutný z toho, že chceme spouštět linux-3.16 na takovém typu hardwaru a trávit čas tím, že na pár místech ušetříme několik KB.
Vývojáři síťové vrstvy také nechtějí, aby začali dostávat hlášení chyb od uživatelů se silně odlehčenou síťovou vrstvou a museli pak přemýšlet, jak to, že to přestalo chodit. Na to by jistě došlo, jakmile by podobné patche byly začleněny. Člověk si může představit, jaká funkčnost je naprosto zásadní a jaká je na drobných systémech volitelná, ale různí uživatelé dojdou k různým závěrům. Jediná volba „zmenši to“ může třeba poskytnout síťovou vrstvu pokrývající 99 % potřeb uživatelů drobných systémů – ale chybějící 1 % se bude u každého uživatele lišit.
Poukazovat na některé těžkosti spojené s takovým úsilím pořád neznamená říkat, že by se jádro nemělo snažit malé systémy vůbec podporovat, ale právě to zdá se lidé od síťování říkají. V jeden moment Andi poslal správci síťové vrstvy Davidu Millerovi přímou otázku: Které části bys odstranil ty, abys snížil využití paměti pro 2MB jednoúčelový stroj?„ Davidova odpověď byla jednoduchá: Nepoužil bych Linux, tečka. Možná před dvaceti lety, ale ne teď, tyhle časy jsou už pryč. Jinými slovy, bychom se podle něj neměli ani snažit o to spouštět Linux na takových strojích; namísto toho bychom měli použít nějaký specializovaný operační systém.
Tento přístup může pro mnoho dlouholetých pozorovatelů linuxové komunity být překvapivý. Jaderní vývojáři obecně vždy usilovali o to, aby systém fungoval na pokud možno jakémkoliv hardwaru. Odpověď typu „jdi pryč a používej něco jiného“ byla jen výjimečně slýchána v souvislosti s proprietárním a uzavřeným hardwarem, ale i v těchto případech to s Linuxem nakonec někdo obvykle rozchodí. Tentokrát tu ale máme typ hardwaru, na kterém by Linux mohl běžet, s uživateli, kteří by tam Linux rádi používali, ale nějací jaderní vývojáři jim říkají, že nemají zájem pro ně přidávat podporu. To není vzkaz, který uvítají.
Bylo nebylo, výrobci mainframů se kdysi posmívali minipočítačům – až do doby, než mnoho z jejich zákazníků přešlo na minipočítače. Výrobci minipočítačů vnímali pracovní stanice, osobní počítače a Unix jako hračky; jen málo takových společností tu je s námi doteď. Mnozí z nás si pamatují, jak svět proprietárního Unixu vnímal Linux v době, kdy začínal: mávali nad ním rukou, protože jej brali jako chabou hračku, která nestojí za pozornost. Stačí poznamenat, že dnes toho o proprietárním Unixu moc neslyšíme. Je to typický příběh o tom, jak průlomové technologie dělají čáru přes rozpočet zavedeným firmám.
Není jasné, jestli mikroskopické systémy představují zrovna takový typ průlomových technologií; přístup „počkat, než hardware dozraje“ pro Linux v minulosti často fungoval dobře. Obvykle je bezpečné sázet na to, že výpočetní schopnosti v budoucnosti porostou, takže úsilí spojené s podporou nevýkonných systémů za to často nestojí. Možná se ale setkáváme s novou kategorií hardwaru, kdy „menší a levnější“ je důležitější než „výkonnější“. Pokud bude možné tyto systémy vyrábět ve velkém a šířit je jako „chytrý prach“, pak se mohou stát důležitou součástí výpočetní techniky budoucnosti.
Proto by možnost, že by budoucí drobné systémy mohly ohrozit Linux, měla určitě být zvážena. Pokud Linux na těchto zařízeních nepoběží, tak něco jiného ano. Možná to bude linuxové jádro se síťovou vrstvou kompletně nahrazenou něčím v uživatelském prostoru jako lwIP nebo to třeba bude nějaký jiný svobodný operační systém, jehož komunita bude mít o podporu tohoto hardwaru větší zájem. Nebo to možná bude něco proprietárního a nepříjemného. Jakkoliv se tato situace vyvine, bylo by smutné jednoho dne vzpomínat a říkat si, že vývojáři Linuxu mohli jádro rozchodit na důležitém typu počítačů, ale rozhodli se, že tak neučiní.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.