Refactor ZFS code to support multiple platforms

[ryao]

Currently, the autotools build system has enabled us to support numerous distributions and kernel versions. That will eventually include FUSE support, which will close issue #8. However, I think we can take this a step further.

Much of the code is already shared with other platforms, which have all implemented Solaris compatibility layers. As such, it should be reasonable to introduce abstractions that will enable the build system to produce kernel modules for other platforms using their Solaris compatibility layers. Potential platforms include FUSE, FreeBSD, NetBSD and Mac OS X.

This would consolidate development resources between these platforms into a single project. This would have the beneficial impact of ensuring that code improvements made on one platform are immediately available on all others.

This is a low priority, but my discussions with the Mac-ZFS developers suggest that there is a degree of interest in this, so I am opening this issue to track it.

[dechamps]

That seems like a lot of work. Sure the compatibility layers are nice and all, but there is a lot of code in ZoL that bypasses the SPL and just call very Linux-specific APIs directly, or rely heavily on Linux-specific behavior. This is especially true for low-level modules, e.g. vdev_disk.c.

[mrobbetts]

This is perhaps a silly question, but if it is possible/feasible to implement SPLs for each platform which entirely decouple ZFS from platform-specific details, shouldn't we simply do that and merge any remaining ZoL differences to upstream Illumos? Then of course the benefits would go both ways.

I had always just assumed such a thing couldn't be done.

[behlendorf]

I've given this issue a lot of thought, and I'm not against it. But...

...it would certainly be a lot of work to get everyone running the same code base. As @dechamps mentioned there are a growing number of Linux specific bits in the ZFS code proper to handle the quirks of Linux. As mentioned, the vdev_disk.c file is a total rewrite for Linux, as is the majority of the ZPL code. There was really no way around this because the Linux block/vfs interfaces are so different than those on the other systems. These changes could be isolated and cleanly factored in to platform specific bit interfaces. That would simplify the process of porting to a new platform, I even think we'd have a decent chance of getting the changes back in to Illumos.

But to what end? It's not clear to me what the advantage would be. Ideally, the file system should part of the kernel sources. It just makes development easier. The ZoL source was only forced out of the kernel due to licensing concerns and that meant we needed an autotools build system. But neither Illumos nor FreeBSD have that issue and I doubt they'd like to inherit the added complexity. I would expect them to want to maintain their source with their respective kernels.

This probably only makes sense on other platforms where zfs is excluded from the kernel, such as Mac OS X. Or if it's done in a platform independent way using something like FUSE. Adding support for both options I'm open too if there are interested developers willing to work on this.

However, in practice I think the best way forward is going to be to continue to cherry-pick patches from Illumos. This is really the best way to ensure they get reviewed and any Linux specific concerns are addressed. Once we're fully caught up and start developing new features we can of course push our changes back to Illumos, or they can cherry-pick from our tree as they see fit.

[ryao]

Preprocessor directives can be used. In cases where entire files are entirely platform-specific, we could move them into OS-specific subdirectories and have the makefile access them there.

I was asked by one of the people involed with the mac-zfs project about the possibility of them rebasing on either the Linux or FreeBSD ports. My initial suggestion was to use FreeBSD's port. After thinking about it, I realized that relevant code from FreeBSD could be wrapped in preprocessor directives and controlled through autotools. Something like this would need to be done for issue #8. If the mac-zfs developers are willing to pursue it and avoid causing regressions, I see no reason to stand in their way.

[smuckola]

On behalf of the MacZFS community, thank you very much for considering us in your plans. Our devs are working on the next release, and I'll keep putting you guys into focus there. We're all in the same boat, because of free software, because of ZFS, because of kernel exile, and because they said it couldn't be done. ;) Thank you so much.

[dajhorn]

@smuckola: Did Google know that you were going to post here last week? Maybe. There was no need to ask who I was earlier; just put your trust the truth machine. :D

// Welcome to ZoL. I periodically test with MacZFS on my iBook.

[FransUrbo]

@ryao @behlendorf Should/could we close this as 'wont-fix' (considering this is what OpenZFS is for)?

[behlendorf]

I don''t think there's any rush to close this.