On Thu, Jul 30, 2020 at 01:38:41PM +0200, Florian Weimer wrote:
- Daniel P. Berrangé:
I'm not familiar with what COPR is doing for s39x0 ? Is it using the simple QEMU linux-user syscall emulation, or is it running a proper QEMU s390x VM.
I'm guessing probably the former. The linux-user syscall emulation is truely amazing, but it is certainly not feature complete or fully robust.
It still implements vfork using fork, right? This means we should likely fix posix_spawn in glibc to support this deviation from the kernel interface. Other Linux emulations have exactly the same problem.
Yeah, all of fork(), vfork() and clone(), end up getting mapped onto fork() or pthread_create() depending the precise set of CLONE_* flags required.
Common helper for all:
https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L172 https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L608...
And then the syscall wiring
vfork: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L107...
fork: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L788...
clone: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L979...
there's no clone2/clone3 support at all either.
For emulating 32-bit targets, we have a broken readdir/telldir/seekdir implementation in glibc on 64 bit host kernels because we try to use d_ino directly, which is 64 bit and does not fit into the long value that POSIX requires. A kernel patch with a new interface has been posted which would work around this has been proposed, but it is not going anywhere.
The second issue also affects full-system virtualization if p9fs (not sure what the right name is, it's the older pass-through file system) is used. But it's specific to 32 bit, so maybe not that important after all.
Yep, 9p, its generally not great POSIX emulation no matter what.
The more modern virtio-fs is a more promising solution for the future, based on FUSE.
Regards, Daniel