Vzhledem k tomu, jak je čas v Linuxu reprezentován, nemůže podepsané 32bitové číslo podporovat časy po 19. lednu 2038 po 3:14:07 UTC. Tento problém roku 2038 (Y2038 nebo Y2K38) se týká reprezentace typu časových dat. Řešením je použití 64bitových časových razítek.
Začal jsem na problému pracovat, když jsem pracoval jako Outreachy stážista pro vývojáře jádra Arnda Bergmanna. Outreachy je benevolentní program, který pomáhá novým programátorům dostat se do vývoje open source. Mentory pro projekty jádra jsou obvykle zkušení vývojáři jádra, jako je Arnd.
Rozhodl jsem se pracovat na problému Y2038, protože mi to umožnilo dotknout se všech subsystémů v jádře – a ještě víc než to. Problém se týká také uživatelského prostoru, knihovny C, standardů POSIX a C. Zjistil jsem, že problém se skutečně týká rozhraní mezi vrstvami.
Další zdroje pro Linux
- Cheat pro příkazy Linuxu
- Cheat sheet pro pokročilé příkazy systému Linux
- Bezplatný online kurz:Technický přehled RHEL
- Síťový cheat pro Linux
- Cheat sheet SELinux
- Cheat pro běžné příkazy pro Linux
- Co jsou kontejnery systému Linux?
- Naše nejnovější články o Linuxu
Řešení jednoho problému v jádře zřídka zahrnuje pouze jednu věc; zahrnuje také složitost vzájemně souvisejících věcí v jádře (před změnou je vždy potřeba ještě jedno vyčištění) a interakce s komunitou (zvláště jako nováček).
Jednou z oblastí, kterou jsme řešili, byl virtuální souborový systém (VFS). VFS je vrstva abstrakce souborového systému. Takže i když některé ze souborových systémů, jako je ext4, mohou na 32bitovém systému představovat časové značky po roce 2038, nemohou tak učinit bez podpory vrstvy VFS.
Změna na VFS byla jednou ze sérií patchů, kterým trvalo nejdéle, než bylo dosaženo konsensu a bylo začleněno.
Navrhování řešení
Problém: In-kernel reprezentace časových značek inodů byla v struct timespec , který není bezpečný pro Y2038. Navrhované řešení: Změňte reprezentaci na struct timespec64 , který je bezpečný pro Y2038.
První verzi seriálu zveřejnil Arnd v roce 2014. V té době se vyskytlo několik otevřených problémů a určitá zpětná vazba ohledně přidávání kontroly rozsahu časových razítek.
V lednu 2016 jsem k tomu zveřejnil první žádost o připomínky (RFC) s dotazem, zda existuje nějaká opozice vůči výše popsanému přístupu. Toto nebylo typické RFC pro komunitu jádra. Průvodní dopis série vysvětlil navrhovanou změnu a poskytl několik příkladů, jak by se změny měly provést. Došlo k určitému zmatku ohledně toho, co jsme se v seriálu snažili získat.
Zveřejnil jsem další sérii (ve skutečnosti tři) pro řešení problému třemi samostatnými způsoby. Jednalo se o zmenšenou verzi dřívější série, která řešila pouze základní problém. To bylo také atypické. Vývojář jádra Thomas Gleixner řekl, že mírně preferuje jeden z přístupů k řešení problému, takže jsme nechali všechny záplaty udělat tímto způsobem.
Než jsme mohli provést změnu, museli jsme se zbavit některých starých časových rozhraní. Když jsem zveřejnil sérii těchto zpráv, Linus Torvalds neměl rád jedno z rozhraní (current_fs_time(sb) ), protože superblok vzal jako argument pro přístup k granularitě časového razítka. Ale časová razítka jsou ve skutečnosti funkcí inodu, ne superbloku. Takže jsme se zbavili tohoto API.
Nyní se původní série musela znovu předělat. Udělat patch day flag se zdálo jako přístup k problému hrubou silou. Ale nakonec jsme to udělali. Dokonce jsme šli ještě o krok dále použitím skriptu Coccinelle. Tím se změnilo více než 80 souborů. Úkolem bylo učinit změny základními, aby nedošlo k regresi. Nakonec jsme skončili se sloučením oprav v červnu 2018 a neslyšeli jsme o žádných regresích ze změny.
Na konci celého tohoto cvičení jsme se zbavili tří rozhraní API v jádře, přeuspořádali jsme část zpracování časových razítek souborového systému, zvládli jsme tiskové formáty tak, aby podporovaly větší časová razítka, analyzovali výpisy objektů 32bitové architektury a přepsali nejméně pět verzí série od nuly. A to byl jen jeden z problémů, které jsme pro jádro vyřešili. Ale Y2038 byl zatím jeden z mých oblíbených projektů.
Deepa Dinamani představí na linux.conf.au, 21. až 25. ledna v Christchurch na Novém Zélandu, jak mě snaha zabránit vyčerpání času zavedla do všech koutů linuxového jádra.