Windows NT Sync Driver Proposed For The Linux Kernel - Better Wine Performance

[phoronix]

Phoronix: Windows NT Sync Driver Proposed For The Linux Kernel - Better Wine Performance

Following discussions from last year's Linux Plumbers Conference, a Windows NT synchronization primitive driver has been proposed for the Linux kernel. This driver would expose /dev/ntsync as a new character device for implementing some of the Windows NT synchronization primitives directly within the Linux kernel. In turn this would help the performance of some Windows games/applications running on Linux via Wine and in some cases would mean significantly better performance...

https://www.phoronix.com/news/Windows-NT-Sync-RFC-Linux

[shmerl]

Interesting, I was waiting for this to be finally proposed for upstreaming. But I thought there was some reluctance to call it ntsync for some legal reasons (so it wouldn't be confused with WIndows NT), and alternative name was winesync? So ntsync is OK after all?

If this works out, there finally won't be a reason to drag around esync / fsync patches for Wine (given actual ntsync will be upstreamed in Wine too).

[rhadlee]

Do the likes of SteamOS already implement this in a custom Linux kernel? These performance gains are nothing to scoff at.

[kenren]

If this works out, there finally won't be a reason to drag around esync / fsync patches for Wine (given actual ntsync will be upstreamed in Wine too).

I don't think so, for years Wine developers have rejected gallium nine patch since "Wine is not only for Linux and BSD", if ntsync is only on Linux and not on Darwin and other, probably Wine have to continue to use actual method.

If not I will e happy, happy to be wrong.

[shmerl]

Do the likes of SteamOS already implement this in a custom Linux kernel? These performance gains are nothing to scoff at.

I think these gains are roughly the same between esync, fsync and ntsync. It's just that ntsync is more strictly correct... in some cases that practically no one uses anyway (sounds like) :P So I think Wine should have upstreamed esync a long time ago even if it's not being 100% correct. It could always be set behind an optional env variable same as it's now in staging.

[mdedetrich]

On the one hand for the obvious performance improvements this should be a yes.

On the other hand, its a bit weird that the Linux kernel is basically turning into a Linux + w/e bespoke features that other unrelated kernels have, essentially because we are running applications designed for other kernel's/OS's within Linux.

You could make an argument that a better way to solve this issue is to have a module system where if you are running something like Wine, it depends on a module that is registered which adds the necessary syscall interface that Wine needs for performance.

However Linux isn't designed to work like this at all and it seems like over time its going to turn into one massive behemoth (if it hasn't already).

[shmerl]

You could make an argument that a better way to solve this issue is to have a module system where if you are running something like Wine, it depends on a module that is registered which adds the necessary syscall interface that Wine needs for performance.

However Linux isn't designed to work like this at all and it seems like over time its going to turn into one massive behemoth (if it hasn't already).

Aren't various drivers essentially modules? You can even dynamically load and unload them with modprobe / rmmod. So how is this any worse?

[Steffo]

Funny how Windows und Linux are merging. 😄

[Volta]

I don't think so, for years Wine developers have rejected gallium nine patch since "Wine is not only for Linux and BSD", if ntsync is only on Linux and not on Darwin and other, probably Wine have to continue to use actual method.

If not I will e happy, happy to be wrong.

They're implementing Wayland, so maybe they already changed their stupid attitude. If not, Proton could be place for this or Valve should fork Wine, so it doesn't slow gaming on Linux, because of POS like mentioned darwin and its monkey OS.

[Volta]

Aren't various drivers essentially modules? You can even dynamically load and unload them with modprobe / rmmod. So how is this any worse?

Indeed or maybe implement it using eBPF if possible.