O que é necessário para executar o software da terra do usuário de 64 bits em um kernel de 32 bits?

No Linux e no Windows, estou acostumado com a situação de exigir que um kernel de 64 bits tenha um sistema com multiarch / WoW onde eu possa executar o software de 32 e 64 bits lado a lado.

E então, anos atrás, fiquei impressionado quando alguém me mostrou que o MacOS 10.6 Snow Leopard podia executar aplicativos de 64 bits com o kernel no modo de 32 bits. Isso pode ser amplamente esquecido agora, porque foi uma transição de tecnologia única. Com o hardware à frente da curva no espaço móvel, até onde eu sei, isso nunca foi necessário na mudança para 64 bits para iOS e Android.

Minha pergunta: o que seria necessário para obter o mesmo recurso em um kernel Linux de 32 bits (i386 ou armhf)?

Eu entendo que isso provavelmente não é trivial. Se fosse, a Microsoft poderia ter colocado o recurso no Windows XP de 32 bits. Quais são os requisitos gerais? Alguma vez houve um patch proposto ou prova de conceito?

No mundo incorporado, acho que isso seria especialmente útil, pois o suporte a 64 bits pode ficar para trás por um longo tempo nos drivers de dispositivo.

A execução de aplicativos de 64 bits requer algum suporte do kernel: o kernel precisa pelo menos configurar tabelas de páginas, interromper tabelas etc., conforme necessário, para suportar a execução de código de 64 bits na CPU e salvar os arquivos de 64 bits completos. contexto ao alternar entre aplicativos (e de aplicativos para o kernel e vice-versa). Portanto, um kernel puramente de 32 bits não pode suportar o espaço do usuário de 64 bits.

No entanto, um kernel pode executar código de 32 bits no espaço do kernel, enquanto suporta código de 64 bits no espaço do usuário. Isso envolve manipulação semelhante ao suporte necessário para executar aplicativos de 32 bits com um kernel de 64 bits: basicamente, o kernel precisa suportar as interfaces de 64 bits esperadas pelos aplicativos. Por exemplo, ele precisa fornecer algum mecanismo para o código de 64 bits chamar no kernel e preservar o significado dos parâmetros (nas duas direções).

A questão então é se vale a pena. No Mac e em alguns outros sistemas, é possível argumentar, pois o suporte ao código do kernel de 32 bits significa que os drivers nem todos precisam fazer a troca simultaneamente. No Linux, o modelo de desenvolvimento é diferente: qualquer coisa no kernel é migrada conforme necessário quando grandes alterações são feitas e qualquer coisa fora do kernel não é realmente suportada pelos desenvolvedores do kernel. O suporte à terra do usuário de 32 bits com um kernel de 64 bits é certamente útil e vale a pena o esforço (pelo menos foi quando o suporte a x86-64 foi adicionado), não tenho certeza se há um argumento a ser feito em 64 bits no 32 -mordeu...

O Snow Leopard foi capaz de executar binários de 64 bits em uma CPU Intel de 64 bits.

Ele também foi capaz de inicializar com um kernel de 64 bits quando seu efi já tinha 64 bits (meu lote de produção do Macbook "modelo de transição" pro já era uma máquina).

Não havia emulação envolvida, você pagou um custo de desempenho menor ao inicializar no modo 32 bits.

Em CPUs puras de 32 bits, você não poderá fazer isso, pois elas não têm idéia de como interpretar o código de 64 bits. A menos que você esteja emulando com software, o que seria lento para esse tipo de classe de máquinas incorporadas tradicionalmente com pouca potência.