Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Darling in WSL? #260

Closed
DuIslingr opened this issue Mar 22, 2017 · 8 comments

Comments

Projects
None yet
5 participants
@DuIslingr
Copy link

commented Mar 22, 2017

What would it take to get darling to function on WSL? I can make and install it just fine, however I cannot build the kernel submodule since its a similar issue to a closed issue I came across regarding docker.

make -C /lib/modules/4.4.0-43-Microsoft/build M=/home/DuIslingr/darling/src/lkm modules make[1]: *** /lib/modules/4.4.0-43-Microsoft/build: No such file or directory. Stop. Makefile:36: recipe for target 'default' failed make: *** [default] Error 2

I know it was said that it wouldn't work due to docker being simply a chroot environment essentially basically so it has no real kernel to work with. Which the same can be said for wsl. just would be nice if i could run Apples toolchain without having to wait for ports to linux or windows etc.

@bugaevc

This comment has been minimized.

Copy link
Member

commented Mar 22, 2017

As of now, it's impossible to run Darling in WSL for various reasons, the two most important ones being:

  1. Darling needs to load its own kernel module. Since there's no Linux kernel in WSL, it's impossible to use our module there. To make it work, the functionality would need to be reimplemented in some other way.
  2. We make use of various features that WSL does not support, such as mount namespaces (last time I checked, WSL didn't have any support for mounting anything, let alone namespacing that).
@DuIslingr

This comment has been minimized.

Copy link
Author

commented Mar 22, 2017

Hmmm 2 would be the more likely to be resolved as work on wsl progresses more features are supported. As far as 1 goes idk. Probably be more likely for you guys to make it work in some other fashion. But oh well I guess for the time being. Can just vm linux or somethin.

@oscarbg

This comment has been minimized.

Copy link

commented Jul 31, 2017

would be nice if you submit type 2 issues as suggestions to Microsoft here:
https://github.com/Microsoft/BashOnWindows/issues
also reading:
https://msdn.microsoft.com/en-us/commandline/wsl/release_notes
seems latest preview builds have support for mount namespaces..
I'm right?

@oscarbg

This comment has been minimized.

Copy link

commented Jul 31, 2017

So I put an issue in WSL site for help..

@bugaevc

This comment has been minimized.

Copy link
Member

commented Jul 31, 2017

seems latest preview builds have support for mount namespaces

Seems so indeed! That's pretty cool, thanks for bringing it to my attention.

overlayfs is still missing, but we could do without it (the way Wine does it). PID namespaces are missing, too, though these could be faked quite easily in LKM (or whatever replaces it).

@fpqc

This comment has been minimized.

Copy link

commented Jul 31, 2017

@bugaevc Mount, PID, IPC, and UTS namespaces are all implemented now (they appear to be pursuing container support on the hush hush). I think the main problem here is going to be lack of 'kernel' headers or real module-loading capabilities.

The trouble is that WSL's modules, if they ever are implemented for arbitrary modules, will need to be a special kind of Windows signed driver (because the Windows Kernel enforces driver signing with either a Microsoft or very high-level microsoft partner signature. Drivers submitted for loading have to be signed after code review within Microsoft or a trusted partner).

Alex Ionescu wrote up a little article on his github about it, and he was able to write a very basic out-of-tree kernelmode driver to expose some virtual hardware inside WSL.

However, the WSL driver API is still neither finalized and versioned or even exposed with symbols, so even if you did want to write a driver for it, it would be a hack with no Kernel shim engine support, and it would only work if the system was set up to boot in 'Test Mode'. There are several people with signatures who might be willing to sign an opensource drivers for free (the people who sign dokany and who will sign the btrfs driver in the future), but it's unlikely they would do it if you're programming against an unstable and undocumented API.

So for the foreseeable future, it's going to be a no-go.

@CuriousTommy

This comment has been minimized.

Copy link

commented May 7, 2019

Seeing that WSL2 uses the actual Linux kernel, I wonder if there will be support for building and installing modules.

@bugaevc

This comment has been minimized.

Copy link
Member

commented May 7, 2019

Yeah, that's what I'm wondering as well. If modules are supported, there's a high chance Darling will work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.