5 ms·

Mmmmmm a kernel call translator. Microsoft attempted to do it with WSL. Then abandoned the idea and went with a VM called WSL v2. I have no solid proof but I

by _ugfj 4y ago

Mmmmmm a kernel call translator. Microsoft attempted to do it with WSL. Then abandoned the idea and went with a VM called WSL v2. I have no solid proof but I believe at least one of the factors were https://github.com/microsoft/WSL/issues/2028 https://github.com/microsoft/WSL/issues/2028 https://github.com/microsoft/WSL/issues/3031 https://github.com/microsoft/WSL/issues/3031 -- the ptrace() syscall is not a single syscall but more like the infamous rabbit hole which you have no idea the depth of.

Dylan16807 4y ago
WSL1 is a lot better for some use cases, are you sure they gave up on it?
- notRobot 4y ago
  They're no longer working on it, so that appears to be the case?
  - Dylan16807 4y ago
    They said they were still working on it, was that not true? It's functional enough that it's hard to tell at a glance.
    - tsimionescu 4y ago
      > They said they were still working on it, was that not true? Almost certainly yes. Microsoft almost never fully abandons projects, but they keep them in limbo for years and have no qualms about claiming they are still working on them. I bet they never officially stopped working on WinForms either.
      - leosarev 4y ago
        Winforms now is alive. They are accepting pull requests and have team to fix issues and even add small features
        tsimionescu 4y ago
        Wow, had no idea. I guess WPF is now the legacy UI framework? Or Modern/Metro/UPF?
        leosarev 4y ago
        WinForms and WPF both are legacy, but alive and staffed.
    - deleted 4y ago
      [deleted]
- NavinF 4y ago
  Indeed it is better for many use cases, but they seemed to have stopped taking feature requests for WSL1 a couple of years ago when I asked for the adjtimex syscall to set system time: https://github.com/microsoft/WSL/issues/6310 https://github.com/microsoft/WSL/issues/6310 > I presume this is wontfix for WSL1? > Yes WSL2 won't help your use-case presently. A feature requestion along the lines of "hardware clock passthrough" could be submitted under a different cover. It’s likely the feature freeze started even earlier and I just never noticed. Also see WSLg (GUI), which only works on WSL 2. I think it’s clear that WSL1 is in maintenance mode.
  - Dylan16807 4y ago
    I more or less give WSLg a pass because it's very complex and inherently requires WSL2 to run the internals. It would be nice if you could connect WSL1 programs to it at some point, but they only just got it working at all. For other issues, well, I'm willing to believe it either way, but I think the last couple comments on your example link make it clear that this feature doesn't really exist on WSL1 or WSL2.
    - NavinF 4y ago
      > they only just got it working at all WSLg was launched over a year ago > I think the last couple comments on your example link make it clear that this feature doesn't really exist on WSL1 or WSL2 They made it clear that this syscall will not be implemented at all in WSL1. With WSL2 on the other hand, they are willing. That’s what a feature freeze looks like.
      - Dylan16807 4y ago
        Saying to make a new ticket isn't exactly saying they're willing, though. The "fixed in wsl2" tag would be more damning but it's not on many newer issues and looking at a few it didn't seem like it was generally used as a resolution, I think? I found one issue directly saying they weren't dismissing it because they're done with WSL1 but because it's a minor TCP difference that the code should be less fragile about.
deleted 4y ago
[deleted]
wmf 4y ago
It's an idea with a long history. BSD and Solaris can also emulate Linux system calls and back in the day IIRC Linux could emulate system calls for some other OSes.
hencq 4y ago
In the starnix design doc [1] they mention the similarity to WSL1. There they mention the reason for abandoning WSL1 for WSL2 was due to poor performance characteristics of NTFS and that for starnix they need to make sure the filesystem is performant enough to compare against ext4. [1] https://fuchsia.googlesource.com/fuchsia/+/2940d6f300031e852333c3ee0548ecba1d69c961/docs/contribute/governance/rfcs/NNNN_starnix.md https://fuchsia.googlesource.com/fuchsia/+/2940d6f300031e852...
- chx 4y ago
  That's not what the document says. Let me quote > Unfortunately, WSL1 was hampered by the performance characteristics of NTFS, which do not match the expectations of Linux software. This is true but whether this was the cause or one of the causes to abandon WSL is impossible to know unless Microsoft tells us. Back in the day they said they are working on NTFS improvements but it needs assistance from the Windows side. Who knows.
saagarjha 4y ago
I happen to have some idea of the depth of ptrace, having written one partial reimplementation of it capable of bringing up a GDB on a "hello world"-type binary. It is not an easy system call to support, but also definitely not an impossible one. In some sense it's kind of sad to see Microsoft with a comparatively large amount of resources decide to give up on WSL1.
surajrmal 4y ago
It's a lot more tenable when you're not attempting to run all possible Linux applications. For that sort of thing using a VM is probably the way to go. If you're targeting a subset of applications with a more narrowly defined subset of the Linux surface it doesn't seem too unreasonable. For instance, I'm not sure it's even possible to emulate the eBPF in it's full fidelity via something like starnix.
kllrnohj 4y ago
Android apps have already been long since restricted in what syscalls they are allowed to use. And they have always run in a per-app sandbox. That's going to help tremendously. And for things like ptrace they don't have to support it at all. As long as Android Studio knows how to launch GDB or whatever on a Fuschia-based device, they're good to go. It's not like any app is going to be relying on ptrace otherwise, particularly since of course the ability to attach to anything else already isn't allowed.
- saagarjha 4y ago
  proot needs it.

by _ugfj 4y ago

Dylan16807 4y ago

WSL1 is a lot better for some use cases, are you sure they gave up on it?

notRobot 4y ago
They're no longer working on it, so that appears to be the case?
- Dylan16807 4y ago
  They said they were still working on it, was that not true? It's functional enough that it's hard to tell at a glance.
  - tsimionescu 4y ago
    > They said they were still working on it, was that not true? Almost certainly yes. Microsoft almost never fully abandons projects, but they keep them in limbo for years and have no qualms about claiming they are still working on them. I bet they never officially stopped working on WinForms either.
    - leosarev 4y ago
      Winforms now is alive. They are accepting pull requests and have team to fix issues and even add small features
      - tsimionescu 4y ago
        Wow, had no idea. I guess WPF is now the legacy UI framework? Or Modern/Metro/UPF?
        leosarev 4y ago
        WinForms and WPF both are legacy, but alive and staffed.
  - deleted 4y ago
    [deleted]
NavinF 4y ago
Indeed it is better for many use cases, but they seemed to have stopped taking feature requests for WSL1 a couple of years ago when I asked for the adjtimex syscall to set system time: https://github.com/microsoft/WSL/issues/6310 https://github.com/microsoft/WSL/issues/6310 > I presume this is wontfix for WSL1? > Yes WSL2 won't help your use-case presently. A feature requestion along the lines of "hardware clock passthrough" could be submitted under a different cover. It’s likely the feature freeze started even earlier and I just never noticed. Also see WSLg (GUI), which only works on WSL 2. I think it’s clear that WSL1 is in maintenance mode.
- Dylan16807 4y ago
  I more or less give WSLg a pass because it's very complex and inherently requires WSL2 to run the internals. It would be nice if you could connect WSL1 programs to it at some point, but they only just got it working at all. For other issues, well, I'm willing to believe it either way, but I think the last couple comments on your example link make it clear that this feature doesn't really exist on WSL1 or WSL2.
  - NavinF 4y ago
    > they only just got it working at all WSLg was launched over a year ago > I think the last couple comments on your example link make it clear that this feature doesn't really exist on WSL1 or WSL2 They made it clear that this syscall will not be implemented at all in WSL1. With WSL2 on the other hand, they are willing. That’s what a feature freeze looks like.
    - Dylan16807 4y ago
      Saying to make a new ticket isn't exactly saying they're willing, though. The "fixed in wsl2" tag would be more damning but it's not on many newer issues and looking at a few it didn't seem like it was generally used as a resolution, I think? I found one issue directly saying they weren't dismissing it because they're done with WSL1 but because it's a minor TCP difference that the code should be less fragile about.

deleted 4y ago

[deleted]

wmf 4y ago

It's an idea with a long history. BSD and Solaris can also emulate Linux system calls and back in the day IIRC Linux could emulate system calls for some other OSes.

hencq 4y ago

In the starnix design doc [1] they mention the similarity to WSL1. There they mention the reason for abandoning WSL1 for WSL2 was due to poor performance characteristics of NTFS and that for starnix they need to make sure the filesystem is performant enough to compare against ext4. [1] https://fuchsia.googlesource.com/fuchsia/+/2940d6f300031e852333c3ee0548ecba1d69c961/docs/contribute/governance/rfcs/NNNN_starnix.md https://fuchsia.googlesource.com/fuchsia/+/2940d6f300031e852...

chx 4y ago
That's not what the document says. Let me quote > Unfortunately, WSL1 was hampered by the performance characteristics of NTFS, which do not match the expectations of Linux software. This is true but whether this was the cause or one of the causes to abandon WSL is impossible to know unless Microsoft tells us. Back in the day they said they are working on NTFS improvements but it needs assistance from the Windows side. Who knows.

saagarjha 4y ago

I happen to have some idea of the depth of ptrace, having written one partial reimplementation of it capable of bringing up a GDB on a "hello world"-type binary. It is not an easy system call to support, but also definitely not an impossible one. In some sense it's kind of sad to see Microsoft with a comparatively large amount of resources decide to give up on WSL1.

surajrmal 4y ago

It's a lot more tenable when you're not attempting to run all possible Linux applications. For that sort of thing using a VM is probably the way to go. If you're targeting a subset of applications with a more narrowly defined subset of the Linux surface it doesn't seem too unreasonable. For instance, I'm not sure it's even possible to emulate the eBPF in it's full fidelity via something like starnix.

kllrnohj 4y ago

Android apps have already been long since restricted in what syscalls they are allowed to use. And they have always run in a per-app sandbox. That's going to help tremendously. And for things like ptrace they don't have to support it at all. As long as Android Studio knows how to launch GDB or whatever on a Fuschia-based device, they're good to go. It's not like any app is going to be relying on ptrace otherwise, particularly since of course the ability to attach to anything else already isn't allowed.

saagarjha 4y ago
proot needs it.