Remember when WSL was an actual compatibility layer instead of a VM? Imagine if they had just gone further down that road instead of whatever the fuck this shit is.
Afaik original WSL suffered from the fact that filesystem syscalls went through Windows’ APIs, which allow user-level third-party programs to plug in at many points — like path resolution, block access, etc. Which also involves switching the context between the kernel and userspace a bunch of times. File access patterns in Linux apps worked poorly with this. Plus Linux apps expect the filesystem to cache metadata, which Windows doesn’t seem to do.
Much of this is mitigated when file access on the Windows side is done by chucking blocks into and out of a virtual disk, and when a kernel with the whole caching thing is introduced.
I’m guessing such mismatch problems would crop up in other places too.
Loop mounting is implemented as a separate syscall? But why? I’d expect it to be a parametric thing like mount("loop", ...)
ლ(•ᯅ• )ლ
Or do you just mean the whole feature was absent? I’m less surprised by that than the fact that loop mounting might be a separate syscall. Considering stuff like the fact that in NTFS, symlinks to files and to directories are two different things, and the program creating a symlink must distinguish which target it needs.
Remember when WSL was an actual compatibility layer instead of a VM? Imagine if they had just gone further down that road instead of whatever the fuck this shit is.
Afaik original WSL suffered from the fact that filesystem syscalls went through Windows’ APIs, which allow user-level third-party programs to plug in at many points — like path resolution, block access, etc. Which also involves switching the context between the kernel and userspace a bunch of times. File access patterns in Linux apps worked poorly with this. Plus Linux apps expect the filesystem to cache metadata, which Windows doesn’t seem to do.
Much of this is mitigated when file access on the Windows side is done by chucking blocks into and out of a virtual disk, and when a kernel with the whole caching thing is introduced.
I’m guessing such mismatch problems would crop up in other places too.
It also lacked a lot of system calls, like ability to loop mount.
Loop mounting is implemented as a separate syscall? But why? I’d expect it to be a parametric thing like
mount("loop", ...)ლ(•ᯅ• )ლ
Or do you just mean the whole feature was absent? I’m less surprised by that than the fact that loop mounting might be a separate syscall. Considering stuff like the fact that in NTFS, symlinks to files and to directories are two different things, and the program creating a symlink must distinguish which target it needs.
Mounting in general is a system call, loop mounting is the particular case that is required for features like snap to work