3 ms·

Reminds of WSL1, Microsoft originally also tried to have a translation layer between NT syscalls and Linux syscalls, but ended up scrapping all that in favor of

by kgeist 5y ago

Reminds of WSL1, Microsoft originally also tried to have a translation layer between NT syscalls and Linux syscalls, but ended up scrapping all that in favor of a virtual machine in WSL2 due to a multitude of problems in WSL1. I wonder if Fuchsia has solutions to the problems encountered in WSL1 or are they doomed to repeat same mistakes?

jsnell 5y ago
Given that the document has a section on WSL1 as prior art, they're clearly aware of the problem. It seems that they're mostly assigning the problem to NTFS not having the performance characteristics expected by Linux programs written against ext4, which seems like a solveable problem when working on a green field and can design the filesystem accordingly. Microsoft did not have that luxury. Do you think they're misdiagnosing the actual problem that WSL1 had?
- saagarjha 5y ago
  WSL1 also ran into issues trying to cover the breadth of the Linux API, which has considerable surface area.
- roca 5y ago
  Yes they are. The Linux API surface is huge. Reimplementing all of it in a compatible way is a colossal amount of work, work that is neverending as Linux evolves. If they can impose restrictions on applications, e.g. say to Android devs "you can only use this set of syscalls" and use e.g. seccomp to enforce that on Linux-Android, maybe they can get those applications to work. But if they want people to just take any Linux application and run it, they'll have to implement all kinds of crazy stuff. Take rr for example, they'd have to implement ptrace and perf_event_open and other arcane features that you really, really don't want to reimplement. Today they're probably thinking that with some bounded amount of work they can run "90% of Linux apps" or something like that. But Microsoft thought the same thing about WSL1 and it didn't pan out, hence WSL2. It's strange to me to see Google failing to learn from that mistake.
  - abdulla 5y ago
    Android began restricting what APIs you could use in your app with Android 9: https://developer.android.com/guide/app-compatibility/restrictions-non-sdk-interfaces https://developer.android.com/guide/app-compatibility/restri... Similarly, what is accessible from the NDK is limited: https://developer.android.com/ndk/guides/stable_apis https://developer.android.com/ndk/guides/stable_apis
corty 5y ago
WSL1 mostly had problems due to the layering violations and poor design decisions in the windows kernel and low level system libraries. E.g. filesystem functionality like "what constitutes an acceptable filename?" or "is that file locked?" is not only implemented by the NTFS driver and filesystem layer but also partly or fully by a number of higher-level system libraries. A lot of that lives on top of the windows syscall layer. The Linux syscall layer (which is most of WSL1) lives next to, not above the windows syscall layer. But e.g. for all that filesystem access functionality, WSL1 doesn't just have to talk to the NTFS driver and generic FS layer but also to a lot of Win32 system libraries. If it doesn't, things will break. If it does, you have dependencies across layers, syscall conventions and system services. WSL1 didn't work because windows internals are a mess.

by kgeist 5y ago

jsnell 5y ago

Given that the document has a section on WSL1 as prior art, they're clearly aware of the problem. It seems that they're mostly assigning the problem to NTFS not having the performance characteristics expected by Linux programs written against ext4, which seems like a solveable problem when working on a green field and can design the filesystem accordingly. Microsoft did not have that luxury. Do you think they're misdiagnosing the actual problem that WSL1 had?

saagarjha 5y ago
WSL1 also ran into issues trying to cover the breadth of the Linux API, which has considerable surface area.
roca 5y ago
Yes they are. The Linux API surface is huge. Reimplementing all of it in a compatible way is a colossal amount of work, work that is neverending as Linux evolves. If they can impose restrictions on applications, e.g. say to Android devs "you can only use this set of syscalls" and use e.g. seccomp to enforce that on Linux-Android, maybe they can get those applications to work. But if they want people to just take any Linux application and run it, they'll have to implement all kinds of crazy stuff. Take rr for example, they'd have to implement ptrace and perf_event_open and other arcane features that you really, really don't want to reimplement. Today they're probably thinking that with some bounded amount of work they can run "90% of Linux apps" or something like that. But Microsoft thought the same thing about WSL1 and it didn't pan out, hence WSL2. It's strange to me to see Google failing to learn from that mistake.
- abdulla 5y ago
  Android began restricting what APIs you could use in your app with Android 9: https://developer.android.com/guide/app-compatibility/restrictions-non-sdk-interfaces https://developer.android.com/guide/app-compatibility/restri... Similarly, what is accessible from the NDK is limited: https://developer.android.com/ndk/guides/stable_apis https://developer.android.com/ndk/guides/stable_apis

corty 5y ago

WSL1 mostly had problems due to the layering violations and poor design decisions in the windows kernel and low level system libraries. E.g. filesystem functionality like "what constitutes an acceptable filename?" or "is that file locked?" is not only implemented by the NTFS driver and filesystem layer but also partly or fully by a number of higher-level system libraries. A lot of that lives on top of the windows syscall layer. The Linux syscall layer (which is most of WSL1) lives next to, not above the windows syscall layer. But e.g. for all that filesystem access functionality, WSL1 doesn't just have to talk to the NTFS driver and generic FS layer but also to a lot of Win32 system libraries. If it doesn't, things will break. If it does, you have dependencies across layers, syscall conventions and system services. WSL1 didn't work because windows internals are a mess.