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.

Sign up for GitHub

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

Jump to bottom

Windows Subsystem for Linux Support #61

Closed
ghost opened this issue Mar 12, 2017 · 15 comments
Closed

Windows Subsystem for Linux Support #61

ghost opened this issue Mar 12, 2017 · 15 comments
Labels
enhancement major

Comments

@ghost
Copy link

ghost commented Mar 12, 2017

Hi,

Is it possible to run winfsp on WSL?

microsoft/WSL#17

https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13522845-add-fuse-filesystem-in-userspace-support-in-wsl
@billziss-gh
Copy link
Collaborator

That is a great idea and I may in fact look into it now that WinFsp 2017 is almost out the door!

Caveats

I know almost nothing about WSL. I have a very basic understanding that it allows unmodified Linux executables to run on Windows. This means that these FUSE executables are already linked with libfuse (or a variant) and expect to see a /dev/fuse device, which they use to interface with the kernel.

http://man7.org/linux/man-pages/man4/fuse.4.html

I do not know how to create a "device driver" for WSL. Is there any information available?

An alternative might be to make /dev/fuse into a named pipe and have a Win32 process listening on the other end that can interface with WinFsp. Even if this is possible, it would be suboptimal: a single file system request would now have to go to the pipe server process and then to the FUSE file system to be serviced.

Food for thought. Thanks!

@billziss-gh
Copy link
Collaborator

An additional issue here is that /dev/fuse speaks the lowlevel FUSE protocol, which is not currently implemented in WinFsp. Luckily I have experience with it and believe it can be implemented on top of WinFsp.

@ghost
Copy link
Author

ghost commented Mar 12, 2017

some notes about device drivers and linux integration:

@billziss-gh
Copy link
Collaborator

I could not run memfs-x64.exe on WSL. WSL does not support removable & network drives.

Interesting. It may be that Windows processes do not have access to the NTOS object namespace under WSL. [MEMFS uses the WinFsp DLL, which needs to interface with the WinFsp FSD (File System Driver) and it does so by opening a special "file": \\?\GLOBALROOT\Device\WinFsp.Disk; this is a device controlled by WinFsp.]

What is the exact message you are getting?

[I should probably just install WSL and quit asking obvious questions :) ]

There is a way to develop device driver for WSL but its not documented. Sample driver: LxDrv

This is a very interesting pointer. Thank you!

@ghost
Copy link
Author

ghost commented Mar 12, 2017

What is the exact message you are getting?

WSL mounts only the C:\ drive to /mnt/c. There are no errors, just do not allow me to access network, usb & winfsp drive.

@billziss-gh
Copy link
Collaborator

WSL mounts only the C:\ drive to /mnt/c. There are no errors, just do not allow me to access network, usb & winfsp drive.

Makes sense, thanks.

@billziss-gh
Copy link
Collaborator

There is a way to develop device driver for WSL but its not documented. Sample driver: LxDrv

Ok, I now had the chance to watch the preso and read some more about WSL.

I need a few days to think about it, sketch a potential architecture and scope it. On a first approximation this looks to me like a 3-6 month project (if I work on it full time) to bring it to the stability level that WinFsp currently has. Obviously this falls under "unpaid work", but I am interested enough about it that I may just do it!

@billziss-gh
Copy link
Collaborator

billziss-gh commented Mar 21, 2017 •
edited
Loading

@ui4j I now had the chance to look into this some more.

I think I may have been over-enthusiastic in giving any time estimate on this. After seeing lxdrv that you pointed to me I erroneously assumed that there was sufficient information to write a driver for WSL and that such a driver would follow the familiar IRP-based model. Unfortunately I am finding that this is not the case.

My new estimate is: "no estimate". It is impossible to gauge the amount of work needed, because the WSL internals are not actually documented. Furthermore WSL at this point is a moving target, even if someone reverse engineered the portions of WSL needed to get FUSE going, any development on this knowledge would be very fragile and likely break at the next WSL point release.

For all intents and purposes WSL is like a new and changing OS at this point; it just happens to run on Windows and just happens to have a Linux-compatible interface. I strongly recommend that we wait until it stabilizes and Microsoft releases more documentation on it.

However I compile here some random notes based on my research so far. Most of these notes are based on Alex Ionescu's lxss project and some of my own WinDbg sleuthing.

  • WSL uses a VFS-compatible model for its drivers: https://github.com/ionescu007/lxss/blob/master/lxdrv/lxvfs.h#L120-L139. The familiar IRP model is not used.

  • A FUSE driver would have to register /dev/fuse. Lxdrv uses VfsInitializeStartupEntries to register /dev/lxdrv.

  • It is not clear how a new file system is to be mounted (although there are many interesting symbols in the lxcore.sys symbol list which I attach to the end). Presumably once a file system was mounted it would be getting calls in VFS_FILE_CALLBACKS, which it would then forward to the file system process connected to /dev/fuse. [NOTE: the WinFsp I/O queues can only queue IRP's and cannot be reused without significant rework.]

  • Symlinks created by WSL (on DrvFs) are reparse points with tag 0xa000001d. The actual link is stored in the file. For a link baz -> foobaz the following is stored:

      C:\Users\billziss\Projects>winfsp\ext\test\winfstest\winfstest.exe GetReparsePoint baz
  0
  ReparseTag=0xa000001d ReparseDataLength=4

  C:\Users\billziss\Projects>winfsp\ext\test\winfstest\winfstest.exe ReadFile baz 0 10
  0
  Length=6 Data="66 6F 6F 62 61 7A"

  • Apart from symlinks, other special files are not supported on DrvFs. It is unclear to me why this is so. It is also unclear why they did not use the existing NFS reparse points for symlinks and special files: https://msdn.microsoft.com/en-us/library/dn617178.aspx

I may update this list as I find out more about WSL.

Lxcore symbols: https://gist.github.com/billziss-gh/849ec9f01fbb3f790a4f445798083279#file-lxcore-sym-txt
Fstest on VolFs: https://gist.github.com/billziss-gh/849ec9f01fbb3f790a4f445798083279#file-volfs-fstest-txt

@MrObvious
Copy link

Useless info, which may help. I think the NFS/symlink/reparse thing is just that it hasn't been implemented yet. See the WSL github for more info.

@billziss-gh
Copy link
Collaborator

@MrObvious do you have a link?

@MrObvious
Copy link

I stand corrected, it was the thread you started. Sorry to get your hopes up. :(

microsoft/WSL#1798

@billziss-gh
Copy link
Collaborator

No problem :)

@ghost
Copy link
Author

ghost commented Apr 25, 2017

The latest WSL allows to mount removable USB sticks or CDs, and any network location. i did not try to mount WinFsp but probably it will work.

https://blogs.msdn.microsoft.com/wsl/2017/04/18/file-system-improvements-to-the-windows-subsystem-for-linux

@MrObvious
Copy link

MrObvious commented Apr 25, 2017 via email

@billziss-gh
Copy link
Collaborator

Closing this. It is unlikely will support WSL directly at this point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement major
Milestone
No milestone
Development

No branches or pull requests
2 participants
@MrObvious @billziss-gh