From: Ryan Houdek
Sorry about the noise. I obviously don't work in this ecosystem.
Didn't get any comments previously so I'm resending
The problem:
We need to support 32-bit processes running under a userspace
compatibility layer. The compatibility layer is a AArch64 process.
This means exposing
From: Ryan Houdek
Sorry about the noise. I obviously don't work in this ecosystem.
The problem:
We need to support 32-bit processes running under a userspace
compatibility layer. The compatibility layer is a AArch64 process.
This means exposing the 32bit compatibility syscalls to userspace.
Why
From: Ryan Houdek
This is a continuation of https://lkml.org/lkml/2021/1/6/47
This patch is currently based against a 5.10 kernel but rebasing against
latest HEAD is trivial
Specifically Amanieu pointed out a couple of problem spaces that would
show up around memory management and various other
From: Ryan Houdek
Problem presented:
A backwards compatibility layer that allows running x86-64 and x86
processes inside of an AArch64 process.
- CPU is emulated
- Syscall interface is mostly passthrough
- Some syscalls require patching or emulation depending on behaviour
- Not viable fro
From: Ryan Houdek
Problem presented:
A backwards compatibility layer that allows running x86-64 and x86
processes inside of an AArch64 process.
- CPU is emulated
- Syscall interface is mostly passthrough
- Some syscalls require patching or emulation depending on behaviour
- Not viable fro
From: Ryan Houdek
Problem presented:
A backwards compatibility layer that allows running x86-64 and x86
processes inside of an AArch64 process.
- CPU is emulated
- Syscall interface is mostly passthrough
- Some syscalls require patching or emulation depending on behaviour
- Not viable fro
6 matches
Mail list logo
