Pretty much. Long predates WSL1, though, and facing many of the same difficulties that prompted the Windows team to just run Linux in a hypervisor (WSL2).
> facing many of the same difficulties that prompted the Windows team to just run Linux in a hypervisor
How's that?
WSL had serious performance issues due to design differences between linux and NT. Linux and freebsd both being unices, there is no such impedance. Some features (like cgroups) remain unimplemented, true, but there haven't been any big difficulties afaik.
One that comes to mind is FreeBSD's kqueue, which opens a file descriptor for every file watched [1]
So inotify, inotify_add_watch, inotify_rm_watch isn't started. Lots of applications need watching of changes on directories. Even plain old FreeBSD gets messed since a large webpack project is going to chew up way too much.
Namely in WSL1, there were serious issues with package systems like npm, node_modules/ would have file descriptors get clogged, and it took a full system reboot to get WSL working again: https://github.com/microsoft/WSL/issues/1529. WSL2 Fixes it.
Sure, "BSL" doesn't have all the same difficulties as Windows WSL1 had. There are still design mismatches between FreeBSD and Linux that make implementing Linux features difficult (just for example, compare Linux clone() to FreeBSD fork()), and there are many, many features that remain unimplemented (inotify, cgroups, namespaces, ...).
I agree it's largely "just" a matter of implementing the missing functionality, which has a large surface area and requires building novel infrastructure in the FreeBSD kernel.
I'd say it doesn't have ~90% of the difficulties WSL1 had. From what I remember WSL1 had problems with even most basic functionality, like the filesystem semantics, and never got to support eg DRI for X11.
Regarding clone() - it's rfork(2) you want to compare to, not fork(2). Not the same, sure, but much closer.
(Disclaimer: I'm one of the people working on it, so I'm obviously biased.)
