Please document the complete list of currently supported system calls, and for each of them how they are covered

[ytrezq]

It’s well known ptrace() is unimplemented But some other are only partially implemented : for exampleprctl(PR_SET_PDEATHSIG, SIGTERM) trigger theinvalid argumenterror (it’s part of a system package which works correctly on Linux).

So would it be possible to get the complete list of system calls. And for each of them, would it possible to implementation status (implementation complete or implementation partial) ?

The exception would beioctl()where the list would be the currently supported ioctls. I know the one which allows to list filesytems xattrs isn’t supported because thelsattrcommand doesn’t works.

[therealkenc]

They published the LTP results here.

[ytrezq]

@therealkenc : are there plans to implement all the ones which are failing or I can’t expect yum to successfully install some packages which use capabilities ?

Also what about the ones which aren’t in one of the list likesendmmsg() ? Does it means they aren’t implemented and there’s no plan at doing it ? I’m talking about the ones which are implemented in 3.4.0 and below. The version level Microsoft claims to support.

[fpqc]

Microsoft doesn't claim to support them. They are very open about the fact that lots of the syscalls are not implemented. The Kernel 3.4 string is unexplained right now. It could just simply be the kernelstring of whatever was the target kernel when the project was targeting Android (the original name of WSL was Project Astoria, and its target was Android rather than Ubuntu.

Not really sure if it's the same team working on it, but there are lots of bits and bobs related to Android still present. The device /dev/lxss was originally called /dev/adss and was, I think, related to the way Android connects to adb. There were, iirc, bits and bobs relates to Android's Binder ipc even in some of the early WSL builds released to Insiders.

[therealkenc]

@ytrezq - Don't read anything into the 3.4.0 string. It's just there to make some packages happy - just like your browser reports it is Mozilla 5.0 in in the user agent string.

Basically it's pretty clear they are "targeting" whatever syscalls get developer-related use cases working on the best bang-for-buck engineering effort as they move along. So basically, if you have a favorite package that doesn't work, do an strace -ff and see what syscall is failing. If your use case is shared by enough people, it tends to get priority. Bearing in mind that most of the in-scope popular missing stuff has long been reported already, and "they're working on it".

They don't post a roadmap unfortunately (the Typescript and VS Code teams are golden that way). Whether the WSL team gets funded though implementing "all" of the syscall surface is an open question. Linux has a long long tail. But so far the progress has been awesome.

[fpqc]

@therealkenc I bet they will be funded at least enough that you can run Windoes/Docker containers with a Linux payload for Azure reasons: It means MS can deploy one OS and one kernel without having to do two separate maintenance routines. I'm a little more skeptical about whether they will support direct OpenGL rendering (maybe by providing a weird shim living over-top the Windows drivers making them appear as linux drivers? Maybe tackle the problem higher up the stack by translating Linux's graphical ABI into a form that is compatible with Windows drivers?) Unlike the docker case, I just don't see an obvious market, but I also don't know how hard it would be to implement.

[therealkenc]

CUDA has 605 votes as of this writing, which they "DO want to get ... support at some point". That's one way to get there.

But as I mentioned in some other thread though, getting OpenGL for WSL, from a end-user perspective, is someone doing GLX properly. It is eminently possible right now; just no one has, because as you point out lack of use cases. For $300 I'm sure X-Win32 works just fine.

[fpqc]

@therealkenc Boy those guys are crazy. They could probably convince me to buy it for $50, but no more than that. They do have a free trial so I'm gonna test it.

Anyway, though, my understanding is that aiglx is basically deprecated at this point.

[therealkenc]

AIGLX doesn't come into play here. The X.org Server is on Windows not Linux. AIGLX only comes into play if you wanted to use a Linux Ubuntu box's X.org server to render WSL client applications. Which you can totally do right now with Ubuntu in a VM on your WSL machine over bridged ethernet adapter. But you loose brain cells doing that. See the block diagram. On Windows you'd implement OpenGL in the X Server with a Windows OpenGL library.

[fpqc]

@therealkenc It's still doing remote rendering, that is, GLX over IP, and in this case the only supported mode is AIGLX, except in that diagram, you remove that X server with an arrow into DRM and replace it with one on top of the WDDM (or whatever MS's graphics driver framework is called). There is no such thing, to my knowledge, as redirection of Direct GLX, because OpenGL is not network-agnostic, to my knowledge. You are using AIGLX to get the unrendered bits over to the XServer (by TCP) running on Windows for rendering post-X.

You can't do that with Wayland, bc it does not support remote rendering at all (and the Wayland guys are not interested in creating a remote rendering method; I looked it up).

Edit: There is this thing, GLERI. Don't know what it would take to implement a Windows version, plus it looks like you might need to build against it.

[bitcrazed]

@ytrezq Thanks for your ask. As @therealkenc pointed out, we do share our LTP test results and we also document many of the syscalls that we support (along with the builds they were added). I'll see if we can spend some time writing-up a more thorough list when things calm down in a few months' time ;)

To be clear though, we are building WSL to help developers build and run projects that require *NIX APIs, features and behaviors, and are laser-focused on supporting mainline developer tools, technologies, languages.

We are NOT currently supporting games, X/GUI apps, desktops, etc. Some people have had some amount of success getting some of these things working (to some degree) on WSL, but it's not something we're focusing-on, nor directly supporting right now.

It's not that we don't want to get around to more "interesting" scenarios in the future, but right now we need to deliver a great platform supporting mainline developer scenarios.

[ytrezq]

@bitcrazed : redirecting X11 opengl graphics to Windows drivers instead of executing them directly on Linux is really stupid in terms of performance (as an alternative the games can recompiled for Windows® in order to remove the wrapper layer).

But remember developers want to test their programs. Something which can’t be done without a complete posix implementation (instead of implementing just what is required to run and maintain a toolchain). So according to me this require full support forsetsockopt (which throws invalid arguments all over the time) as well as supporting things like semaphores or capabilites.

[fpqc]

@ytrezq WSL does more than implement POSIX. FreeBSD is basically POSIX compliant, but it can't run LSB binaries without a shim layer. POSIX compliance would be easy. MS could just dust off the old Windows Services for Unix/INTERIX and call it a day.

ABI compatibility is a lot harder, and they are making great progress every build. You can't just wave your hand and expect 100% reimplementation of the Linux ABI and syscall surface overnight. The FreeBSD guys took years writing their layer, and they had the benefit of having a much more closely-related OS.

[ytrezq]

@fpqc : I never heard about capabilties ever getting implemented for ꜱᴜᴀ :smiley: The advantage of Linux is you directly have the binaries : save times in order to avoid recompiling (you can distribute them directly).

[bitcrazed]

@ytrezq Re "redirecting X11 opengl graphics to Windows drivers instead of executing them directly on Linux is really stupid in terms of performance"

We cannot directly execute OpenGL on Linux since there is no Linux in WSL.

Again, we are focusing on delivering a great platform for mainline developer scenarios; we are not supporting GUI apps and scenarios at this time.

Re. sockets: Part of this work includes mating Linux networking capabilities to the Windows kernel's networking stack. Because of differences in architecture, approach, assumptions, and implementations, this requires some very detailed, very careful work. But the work is proceeding. Updates to follow.

[ytrezq]

@bitcrazed : We cannot directly execute OpenGL on Linux since there is no Linux in WSL.I was meaning on a real Linux kernel running on a physical machine.

So supporting ɢᴜɪ apps is nonsense in terms of performance. Other implementations exists already for doing that. I don’t see what benefits escaping the ᴡɪɴ32 layer for the ᴄᴘᴜ would bring here.

[bitcrazed]

@fpqc "MS could just dust off the old Windows Services for Unix/INTERIX and call it a day. "

If only it was that easy ;) WSL's approach is very different to how Interix/SFU worked, and offers significant benefits (e.g. ELF-64 binary compatibility).

[ytrezq]

@bitcrazed : yeah, though I remember sua got ported to 64 bits. But that was still ᴘᴇ executables. I remember you had X11r6 support.

[fpqc]

@bitcrazed Lol that was my point. The problem with SFU was that you had to port everything in a horrible way, and it was not well-maintained, with MS basically contracting out maintenance of a huge set of usermode libraries built on top of the undocumented NT native API (a "traditional" Windows subsystem) to a group of enthusiasts.

The way it worked, it could never have achieved ABI compatibility, since Unix binaries would try to context-switch in the wrong places (which is why you guys have the LX subsystem in kernel-mode). They had to be recompiled against the SFU libs, which would translate POSIX calls to the standard POSIX-API libs (like libc) directly into proper Windows NT nativr syscalls, which would then reach into kernel mode as the NT native syscalls. Unfortunately this is a huge amount of work for MS to maintain and for application developers to handle.

WSL is very similar to FreeBSD's Linux-compatibility shim module (also a Kernel module) though, and that works rather well, all things considered. And it is just as you say, it's more work mating Linux-style syscalls to NT vs to FreeBSD, since FreeBSD's syscalls map much more closely to the Linux ones than NT's do. I thought it was interesting reading how differently NT does IPC vs Linux wrt NodeJS, for example.

[ytrezq]

@fpqc : please notice this applies to cygwin too. and that Microsoft ended up asking to use cygwin instead of sua. Though cygwin didn’t bypassed the ᴡɪɴ32 layer.

But its purpose was working : running posix programs without having to rewrite the source code completely. Here recompiling isn’t even needed.

[therealkenc]

"We cannot directly execute OpenGL on Linux since there is no Linux in WSL". Well sure not directly, but you can execute OpenGL as well as any native Linux box that doesn't have a supported DRM driver. I get around 30fps with 500 fish in the aquarium sample using llvmpipe.

[benhillis]

Thanks for the discussion, as mentioned elsewhere we publish our LTP results and are very transparent about what we fix in our release notes.

[ytrezq]

They published the LTP results here.

@therealkenc : but the modifty_ldt systemcall isn’t in the list.

[therealkenc]

The devs gave up on LTP results in August 2017. Interestingly I can't find a LTP test case for modify_ldt(2), even to see if it return ENOSYS. You could add one in principle.

For WSL2 these days the list of syscalls supported is 'all of them'.

For WSL1, if you are finding modify_ldt() isn't working, that is not too surprising. I didn't find any duplicate issue hits in a quick search, but that doesn't tell much either way.