https://bugs.winehq.org/show_bug.cgi?id=48291
--- Comment #48 from qsniyg qsniyg@mail.com --- (In reply to Zebediah Figura from comment #47)
You proposed that the implementation of ntdll be moved to wineserver. That's a separate process; how exactly are you proposing we communicate with it? We currently do so via sockets; that's IPC and requires system calls.
If seccomp is used, ntdll uses syscalls, as (afaics) that's how windows works: https://j00ru.vexillium.org/syscalls/nt/64/ . IPC isn't used.
If seccomp is not used, IPC is used, and it doesn't matter that it uses linux syscalls because syscalls aren't being trapped :)
I'm not sure what you're even proposing here. ntdll runs in a given client process, wineserver runs in a different process. One of these has to execute, say, an NtReadFile() call and the underlying read() call that this probably implies. Making the wineserver do that incurs a lot of overhead no matter how it's done—it inheres just from counting the extra context switches and scheduling.
Sorry, I'm not very good at explaining, so let me use code instead. For the example you gave, let's say at user_kernel_shared/file.c, there's this function:
NTSTATUS Internal_NtReadFile(Internal_HANDLE ihandle, ...) { ... fread(buffer, 1, length, get_fp_from_ihandle(ihandle)); ... return STATUS_SUCCESS; }
Then in wineserver:
void handle_NtReadFile_syscall(struct seccomp_data data, struct seccomp_notif_resp* resp) { ... Internal_HANDLE ihandle = get_ihandle_from_handle(data.args[0]); resp->val = Internal_NtReadFile(ihandle, ...); ... }
And ntdll:
NTSTATUS WINAPI NtReadFile(HANDLE hFile, ...) { if (use_syscalls) { // perform syscall } else { return Internal_NtReadFile(get_ihandle_from_handle(hFile), ...); } }
Obviously this is all pseudocode, but that would be the general idea. In some cases, less code would be able to be shared (e.g. when IPC would be needed, as that code would only apply to ntdll), but it would help reduce some code duplication.