How the Windows Subsystem for Linux Redirects Syscalls • Hacker News Board

Re: How the Windows Subsystem for Linux Redirects Syscalls

#251

Post by geocar » Thu, Jun 09, 2016, 3:09 PM UTC

ambrop7 wrote: post #244

geocar wrote: post #238

Earlier quoted context omitted.

> I'm not so sure the Linux design where copies are done in syscalls must be inherently less efficient. Windows overlapped IO can map the user buffer directly to the network hardware, which means that in some situations there will be zero copies on outbound traffic. > especially the RX copy I also don't think you need more than one copy, if you design the network stack with that in mind. When the interrupt occurs, th…

Thanks for the info. Yes I suppose zero-copy can be made to work but surely one needs to go through a LOT of trouble to make it work. I'm curious about sending data for TCP through, don't you need to have the original data available anyway, in case it needs to be retransmitted? Do the overlapped TX operations (on Windows) complete only once the the data has also been acked? Are you expected to do multiple overlapped…

Windows was designed for an era where context switches were around 80µsec (nowadays they're closer to 2µsec), so a lot of that hard work has already paid for itself.

> don't you need to have the original data available anyway, in case it needs to be retransmitted? Do the overlapped TX operations (on Windows) complete only once the the data has also been acked?

I don't know. My knowledge of Windows is almost twenty years old at this point.

If I recall correctly, the TCP driver actually makes a copy when it makes the packet checksums (since you have the cost of reading the pages anyway), but I think behaviour this is for compatibility with Winsock, and it could have used a copy-on-write page, or given a zero page in other situations.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#252

Post by jdmichal » Thu, Jun 09, 2016, 3:25 PM UTC

ygra wrote: post #248

jdmichal wrote: post #247

Earlier quoted context omitted.

See, and I personally dislike the system you mention. It bugs me to no end to have only a couple options, but the system will only fill in the common prefix. Now I have to look, figure out what's there already, figure out what the next letter is, hit it, then hit tab again. If I want to save key strokes, that what aliases and symlinks are for, not tab completion. Also, at least in PowerShell 5, if you run the ISE ins…

> if you run the ISE instead of the cmd-based terminal PowerShell depends (or is based) in no way on cmd.

I am fairly certain that they use the same console system. For instance, right-clicking on the title bar gives the exact same options as in `cmd.exe`. I was perhaps a little overzealous in calling it cmd-based; that's a slip-up on my part simply because `cmd.exe` was the only program to use that system before. Thanks for keeping me honest.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#253

Post by ksk » Thu, Jun 09, 2016, 3:27 PM UTC

deprave wrote: post #101

ksk wrote: post #94

Earlier quoted context omitted.

To level the playing field, and if we are to take your opinion seriously, it would be beneficial to know what books or articles or whitepapers you have read to inform yourself about the design of the NT kernel.

I'm sorry, who's "we"? You replied to a comment that presented fact. The fact is that Windows use is mostly limited to desktops. As far as you're concerned, I could be entirely illiterate and my argument would still hold because it's based on fact. If you want to claim Windows is superior, please don't point us to design documentation. Show us actual numbers and use cases where Windows outperforms Unix, or is used in…

>You replied to a comment that presented fact.

False. You ASSUMED facts based on co-relation - "Its used everywhere" doesn't mean anything. "But people must have a reason to use them" STILL doesn't mean anything. "Well, so why don't they use windows" STILL doesn't get you anywhere.

> I could be entirely illiterate and my argument would still hold because it's based on fact.

No. You can't enter into an argument when you know nothing about the subject. That is not how it works.

Why don't YOU present actual facts about the design? Show us you actually understand the internals of the kernel or have atleast some rudimentary knowledge. Otherwise you'd just be wasting everyone's time.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#254

Post by ygra » Thu, Jun 09, 2016, 3:37 PM UTC

jdmichal wrote: post #252

ygra wrote: post #248

Earlier quoted context omitted.

> if you run the ISE instead of the cmd-based terminal PowerShell depends (or is based) in no way on cmd.

I am fairly certain that they use the same console system. For instance, right-clicking on the title bar gives the exact same options as in `cmd.exe`. I was perhaps a little overzealous in calling it cmd-based; that's a slip-up on my part simply because `cmd.exe` was the only program to use that system before. Thanks for keeping me honest.

Both use the Windows console host, effectively what a terminal emulator is on Unix-likes. It provides the window and a bunch of other functionality (character grid with attributes, history, aliases, selection, drag&drop of files into the window, etc.).

It's just that every console application on Windows uses that host. This includes cmd, PowerShell, Far Manager, or even vi. Sorry, I may have seen it conflated with cmd too often. It just nags me. For Linux users it's probably when everyone starts calling a terminal (emulator) "bash".

Re: How the Windows Subsystem for Linux Redirects Syscalls

#255

Post by davidgerard » Thu, Jun 09, 2016, 4:53 PM UTC

Yes, yes, but can we run Wine on it?

Re: How the Windows Subsystem for Linux Redirects Syscalls

#256

Post by xorblurb » Thu, Jun 09, 2016, 6:08 PM UTC

lmm wrote: post #250

xorblurb wrote: post #95

Earlier quoted context omitted.

Well, you can do it on some versions of Windows. On Windows 10, and even future version of Windows 10, not so sure...

Windows 10 is still windows NT. The NT native API is widely used these days. It would be a huge departure for MS to stop supporting it in future versions of windows.

Most parts of the NT API have never been officially documented, officially supported, stable (in the "won't change" meaning), and the tiny parts that have actually been documented come with caveats that they are susceptible to change. Supporting fork through the NT API forever makes no sense if there are no users anymore. They could continue to do it for no specific reason, just because fork is internally needed by WSL for example, and so because it is easy to export the capability through the NT API, but I really don't see why they would necessarily do that.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#257

Post by xorblurb » Thu, Jun 09, 2016, 6:14 PM UTC

therein wrote: post #176

xorblurb wrote: post #80

Earlier quoted context omitted.

Well, tiny parts of the NT API (callable from userspace) are documented, but then often with the caveat that they are not stable (in practice, even some undocumented ones can be considered stable if used by enough programs in the wild, especially if they are simple and standalone and have no Win32 equivalent) The very precise mechanism, though, is extremely unstable. For example virtually every release of Windows (ev…

Ntdll is similar to VDSO in the sense that it is loaded into the memory space of every userspace process. Even that I think might have exceptions on the Linux side. Either way, unlike VDSO, Ntdll actually does export functions potentially useful when called from the program. Here is an interesting read. http://undocumented.ntinternals.net/

What do you think the VDSO is used for? It also exports "functions potentially useful when called from the program".

The approach is a little different though; ntdll exports all of the NT API, and you need to go through it to reach the NT API in a somehow more stable way than using syscall numbers. OTOH, the VDSO exports only virtual syscalls that gain (or have gained in the past) from being performed in userspace, and even then corresponding syscalls still exist in the kernel, with both stable numbers and even a stable API.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#258

Post by xorblurb » Thu, Jun 09, 2016, 6:19 PM UTC

wfunction wrote: post #156

xorblurb wrote: post #84

Earlier quoted context omitted.

You are right, but those points are details. FD under modern Unixes (esp. Linux, but probably others) serves exactly the same purpose (resource management). The FD where read/write can't be used just don't define those (same principle for other syscalls) -- similarly if you try to NtReadFile on an incompatible Handle it will also give you an error back. Both are in a single numbering space per process. NT largely mak…

> You are right, but those points are details. Uh, no, they are very crucial details. For example, it means the difference between letting root delete /dev/null like any other "file" on Linux, versus an admin not being able to delete \Device\Null on Windows because it isn't a "file". The nonsense Linux lets you do because it treats everything like a "file" is the problem here. It's not a naming issue.

Hm I was more thinking about open FD, not just special file entries on the FS. Well, I agree with you: it's a little weird and in some cases dangerous to have the char/block devices in the FS, and it has already been worked-around multiple times in different ways, and even in some cases simultaneously with multiple different work-around. NT is better on that point. But not once the "files" are open and you've got FD.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#259

Post by vegabook » Thu, Jun 09, 2016, 6:54 PM UTC

orionblastar wrote: post #177

mxuribe wrote: post #162

Earlier quoted context omitted.

Funny years ago i would have reflexively flabbergasted at the thought of microsoft buying canonical (or any linux distro producer)...but actually thinking on that concept, and seeing recent (perhaps less-than-hostile) approach that microsoft has taken towards open source and linux, that wouldn't be a bad idea. I mean if microsoft could have both offerings - for windows servers and ubuntu-installed servers - i suppose…

I think Microsoft should do what Apple did with BSD Unix aka Nextstep and merge it with their old OS. Microsoft should take the Windows GUI and put it over Linux as a desktop manager. Microsoft could sell the Windows GUI for Linux users that want to run Windows apps.

Could not agree more. Windows WM as an option on Linux is a clear and logical strategy.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#260

Post by quux » Thu, Jun 09, 2016, 8:00 PM UTC

stuaxo wrote: post #232

quux wrote: post #75

Interesting, I wonder how much overhead is added to syscalls to look up the process type. Does NT still do this check when no WSL processes are running?

Pretty sure these are different entry points, so you wouldn't need to do anything different for normal Windows processes whether WSL is running or not.

I don't think so... both linux and windows binaries are using the same SYSCALL cpu instruction, and thus must be going to the same handler in the NT kernel.