Windows port
Windows port of Open ZFS
The ZOW port does not yet have its own home, but I wanted to jot down some things I have come across while doing the port. There will be a mixture of information for myself, the occasional difference that surprised me and other left-side experiences. Since my background and knowledge comes from Unix, it is mostly looking at the way that Windows does things, so it is unlikely a Windows developer would say anything but "Of course it does it this way!". Still, it has been an interesting journey.
The first brick wall I hit was actually in the very first couple of weeks. Yes, there is a "Hello World" kernel (Windows Driver) example which I tried to compile to "run". This was surprisingly complex a task, a lot of information that is stale led me down the way you would do it if you were still running Windows XP. Just too much information exists. Eventually I figured out that "current" best way is to deploy in VisualStudio, where VS will copy the compiled binary over and "load" it into the running kernel. When I created the first project file, I called it "Open ZFS on Windows". Each time I had to re-create the project in frustration (as nothing worked, not even rebooting) I deleted one of the characters. In the end, it was "ZFSin" that finally had some progress. I feel I got close to giving up there, before I even started.
At first, the porting consisted of changing over the SPL primitives, like atomics, mutex, condvars, rwlocks, threads and taskqs, and all that. It is pretty straight forward porting work, and you never know if it'll work at this point.
The first real porting of a function, was the Unix `panic()` call. Ie, things have gone so bad, we want to purposely terminate the kernel. Used by the `VERIFY` macros throughout the ZFS sources.
During my first ZFS porting work, to OsX, the biggest annoyance when Googling for information was the lack of said information. There just is not many kernel devs on OsX, especially in the filesystem genre.
With Windows, I quickly found the opposite to be true. When trying to Google for how to trigger a BSOD (Blue screen of death), the first 1,000 or so hits are about "Troubleshooting: How to fix your BSOD!". As a side note here Windows people, when the steps to troubleshoot includes "try re-installing Windows". That is troubleshooting, that is giving up.
Anyway, the next lot of thousand hits are "How to abuse BSOD for malwares" - oh great, at least we are touching of development. A few thousand hits later, you do get some suggestions, but first always for XP or similar obsolete system.
Just too much information.
Eventually, I got everything to compile. (albeit with thousands of warnings).
And it did not take long to get SPL up and ticking, all taskqs running and firing when needed. After that, ZFS loads and ticks along. Which meant I needed a short detour to port over userland, so that I could eventually run `zpool` command to talk to the kernel. Userland already has a "soft" kernel shim layer, so it is already pretty portable. One of the big changes is that Windows "file descriptors" - ie the integer file used by POSIX, is very limited and there were quite a few things I could not really do with them. So userland porting included changing the integer file descriptors, to the Windows HANDLE type, replacing `open` siblings with `CreateFile` equivalent. Trivial.
