Cosa serve per eseguire il software userland a 64 bit su un kernel a 32 bit?

Su Linux e Windows, sono abituato alla situazione in cui ho bisogno di un kernel a 64 bit per avere un sistema con multiarch / WoW in cui posso eseguire software a 32 e 64 bit fianco a fianco.

E poi, anni fa mi è venuto in mente quando qualcuno mi ha mostrato che MacOS 10.6 Snow Leopard poteva eseguire applicazioni a 64 bit con il kernel in modalità 32 bit. Questo può essere ampiamente dimenticato ora perché si è trattato di una transizione tecnologica una tantum. Con l'hardware in testa alla curva nello spazio mobile, per quanto ne so questo non è mai stato necessario nel passaggio a 64 bit per iOS e Android.

La mia domanda: cosa ci vorrebbe per ottenere la stessa capacità in un kernel Linux a 32 bit (i386 o armhf)?

Capisco che questo probabilmente non è banale. In tal caso, Microsoft avrebbe potuto inserire la funzionalità in Windows XP a 32 bit. Quali sono i requisiti generali però? È mai stata proposta una patch o una bozza di concetto?

Nel mondo embedded penso che ciò sarebbe particolarmente utile, poiché il supporto a 64 bit può rimanere indietro per molto tempo nei driver di dispositivo.

L'esecuzione di applicazioni a 64 bit richiede un po 'di supporto dal kernel: il kernel deve almeno impostare tabelle di pagine, tabelle di interruzione ecc., Se necessario per supportare l'esecuzione di codice a 64 bit sulla CPU, e deve salvare l'intero 64-bit contesto quando si passa da un'applicazione all'altra (e dalle applicazioni al kernel e viceversa). Quindi un kernel puramente a 32 bit non può supportare lo spazio utenti a 64 bit.

Tuttavia, un kernel può eseguire codice a 32 bit nello spazio del kernel, mentre supporta il codice a 64 bit nello spazio utente. Ciò implica una gestione simile al supporto richiesto per eseguire applicazioni a 32 bit con un kernel a 64 bit: in sostanza, il kernel deve supportare le interfacce a 64 bit che le applicazioni si aspettano. Ad esempio, deve fornire un meccanismo per il codice a 64 bit da chiamare nel kernel e preservare il significato dei parametri (in entrambe le direzioni).

La domanda allora è se ne vale la pena. Sul Mac e su alcuni altri sistemi, è possibile creare un caso poiché il supporto del codice del kernel a 32 bit significa che i driver non devono tutti effettuare lo switch contemporaneamente. Su Linux il modello di sviluppo è diverso: qualsiasi cosa nel kernel viene migrata quando necessario quando vengono apportate grandi modifiche e qualsiasi cosa al di fuori del kernel non è realmente supportata dagli sviluppatori del kernel. Supportare un'area utente a 32 bit con un kernel a 64 bit è sicuramente utile e ne vale la pena (almeno, era quando è stato aggiunto il supporto x86-64), non sono sicuro che ci sia un caso da fare per 64-bit su 32 -po...

Snow leopard è stato in grado di eseguire binari a 64 bit in una CPU Intel a 64 bit.

È stato anche in grado di avviarsi con un kernel a 64 bit quando il tuo efi era già a 64 bit (il mio batch di produzione del pro "modello di transizione" Macbook era già una macchina del genere).

Non è stata effettuata alcuna emulazione, hai appena pagato un costo di prestazioni inferiore all'avvio in modalità a 32 bit in modo discontinuo.

Nelle CPU pure a 32 bit, non sarai in grado di farlo, poiché non hanno idea di come interpretare il codice a 64 bit. A meno che non si stia emulando con un software, ciò rallenterebbe per quel tipo di macchine embedded tradizionalmente sottodimensionate.