A causa del modo in cui l'ora è rappresentata in Linux, un numero a 32 bit con segno non può supportare orari oltre il 19 gennaio 2038 dopo le 3:14:07 UTC. Il problema di quest'anno 2038 (Y2038 o Y2K38) riguarda la rappresentazione del tipo di dati temporali. La soluzione è utilizzare timestamp a 64 bit.
Ho iniziato a lavorare sul problema mentre lavoravo come stagista Outreachy per lo sviluppatore del kernel Arnd Bergmann. Outreachy è un programma benevolo che aiuta i nuovi programmatori ad entrare nello sviluppo open source. I mentori per i progetti del kernel sono generalmente sviluppatori del kernel esperti come Arnd.
Ho scelto di lavorare sul problema Y2038 perché mi permetteva di toccare tutti i sottosistemi nel kernel e anche di più. Il problema riguarda anche lo spazio utente, la libreria C, POSIX e gli standard C. Ho scoperto che il problema riguarda in realtà le interfacce tra i livelli.
Più risorse Linux
- Comandi Linux cheat sheet
- Cheat sheet sui comandi avanzati di Linux
- Corso online gratuito:Panoramica tecnica RHEL
- Cheat sheet della rete Linux
- Cheat sheet di SELinux
- Cheat sheet dei comandi comuni di Linux
- Cosa sono i container Linux?
- I nostri ultimi articoli su Linux
Risolvere un problema nel kernel raramente implica solo una cosa; coinvolge anche la complessità delle cose interconnesse nel kernel (c'è sempre un'altra pulizia necessaria prima del cambiamento) e le interazioni con la comunità (particolarmente vero come nuovo arrivato).
Una delle aree che abbiamo affrontato è stata il file system virtuale (VFS). VFS è un livello di astrazione del filesystem. Quindi, anche se alcuni filesystem, come ext4, possono rappresentare timestamp oltre l'anno 2038 su un sistema a 32 bit, non possono farlo senza il livello VFS che li supporta.
La modifica a VFS è stata una delle serie di patch che ha impiegato più tempo per ottenere consenso e fondersi.
Proporre una soluzione
Il problema: La rappresentazione all'interno del kernel dei timestamp degli inode era in spec timespec , che non è sicuro per Y2038. La soluzione proposta: Modifica la rappresentazione in struct timespec64 , che è sicuro per Y2038.
La prima versione della serie è stata pubblicata da Arnd nel 2014. All'epoca c'erano alcuni problemi aperti e alcuni feedback sull'aggiunta del controllo dell'intervallo di timestamp.
A gennaio 2016 ho pubblicato la prima richiesta di commenti (RFC) per questo, chiedendo se vi fosse alcuna opposizione all'approccio sopra descritto. Questa non era una tipica RFC per la comunità del kernel. La lettera di accompagnamento della serie spiegava la modifica proposta e forniva alcuni esempi di come sarebbero state apportate le modifiche. C'era una certa confusione su ciò che stavamo cercando di trasmettere nella serie.
Ho pubblicato un'altra serie (in realtà tre) per risolvere il problema in tre modi separati. Questa era una versione ridotta della serie precedente che affrontava solo il problema principale. Anche questo era atipico. Lo sviluppatore del kernel Thomas Gleixner ha affermato di preferire leggermente uno degli approcci per risolvere il problema, quindi abbiamo fatto tutte le patch in questo modo.
Ma abbiamo dovuto sbarazzarci di alcune vecchie interfacce prima di poter apportare le modifiche. Quando ne ho postati una serie, a Linus Torvalds non piaceva una delle interfacce (current_fs_time(sb) ) perché ha preso il superblocco come argomento per accedere alla granularità del timestamp. Ma i timestamp sono davvero una caratteristica dell'inode, non del superblocco. Quindi, ci siamo sbarazzati di questa API.
Ora la serie originale doveva essere rifatta di nuovo. Fare una patch del giorno della bandiera sembrava un approccio di forza bruta al problema. Ma abbiamo finito per fare proprio questo. Abbiamo anche fatto un ulteriore passo avanti utilizzando uno script di Coccinelle. Questo ha cambiato più di 80 file. La sfida era rendere le modifiche rudimentali per evitare regressioni. Alla fine abbiamo unito le patch a giugno 2018 e non abbiamo sentito alcuna regressione dal cambiamento.
Alla fine di questo intero esercizio, ci siamo sbarazzati di tre API interne al kernel, riorganizzato parte della gestione del timestamp del filesystem, gestito formati di stampa per supportare timestamp più grandi, analizzato dump di oggetti dell'architettura a 32 bit e riscritto almeno cinque versioni del serie da zero. E questo è stato solo uno dei problemi che abbiamo risolto per il kernel. Ma Y2038 è stato ancora uno dei miei progetti preferiti.
Deepa Dinamani presenterà come la ricerca per evitare che il tempo finisca mi ha portato a tutti gli angoli del kernel Linux su linux.conf.au, dal 21 al 25 gennaio a Christchurch, in Nuova Zelanda.