Hacker News Reader

Comment by mholt | Hacker News Reader

Apparently the 6.3 kernel made significant changes to some relevant APIs -- I noticed OpenZFS is not released for 6.3 yet. https://github.com/openzfs/zfs/issues/14622

View on HN

> So far, it looks like this will be a major undertaking. Whoever was responsible for the namespace support is going to have to rebase the entire dang thing with alternate code paths for everything, because as of Linux 6.3, they replaced a whole mess of APIs so they either newly accept struct mnt_idmap * instead of struct user_namespace *, or accept the former in addition to the previous parameters. This has far reaching implications, I think. Good luck to whoever attempts the task.

ouch

Ouch indeed. I've been wondering why it seems to be taking longer than usual for ZFS to build against the new kernel. Guess I'll be on LTS kernels for awhile yet.

For once at least I feel like these changes aren't just the Linux devs breaking ZFS for funsies.

Support is already merged in git tip, a stable release just hasn't been cut with those changes backported yet.

I don't think it'd be that problematic to backport, from what I saw, just nobody's done it.

the struct mnt_idmap stuff was badly needed, before struct user_namespace was being passed around for two different purposes - it was just asking for confusion and bugs.

I keep having this kinky fantasy of a GPL'd Rust ZFS re-implementation. Yeah, I know.

You'd be more likely to get one for bcachefs. Kent has expressed some interest in Rust although he is (correctly) just focusing on finishing the filesystem first.

I'm curious about which would stabilize more quickly, an all new filesystem or the reimplementation of an existing one in a different language? The reimpl has the advantage of having the original to compare and test with, but the fresh design can use a staged approach. Yet more hypothetical Friday-style questions.

Incremental file by file rewrite, for sure.

There’s a lot of unexplored stuff w.r.t. the GPL license, but I doubt that would legally work for a rewrite of CDDL-licensed ZFS to a GPL license.

An implementation in a different language should be pretty clear of license constraints? No code shared is no code shared.

koverstreet wrote “Incremental file by file rewrite, for sure.”

That implies intermediate versions that have both CDDL-licensed ZFS code and new rust code. That rust code, inside the ZFS code base, can’t be GPL-licensed because of the incompatibility of the two licenses.

As the writer of that code, you can separately license your code as GPL if you want, but not in a product containing any CDDL-licensed code (at least in the reading of the FSF. See https://en.wikipedia.org/wiki/Common_Development_and_Distrib...)

So, you could argue that you can license the full product as GPL once all CDDL licensed code has been replaced, and then continue working on that version.

IMO, it is at the least unclear whether that’s legally true.

(All personal opinion, not legal advice, etc)

Even if you finish your rewrite and then release it, the final product might still be a derivative work of the original, because "translations" are legally codified as derivative works. Of course, this is bounded by the merger doctrine and various court cases regarding software compatibility. If you can show that everything in your version has to be structured the same way as the original in order for it to read and write ZFS volumes, thus making it a sort of 'external interface', then you probably have good ground to stand on against Oracle. But things like source file structure or internal call chains are unlikely to constitute an interface in a filesystem driver.

The closest legal example of a "file-by-file rewrite" would be BSD; but the lawsuit they got from UNIX System Laboratories was settled, so it creates no precedent.

The reason why the reverse engineering crowd talks a lot about clean-room is because you naturally discover the interface boundaries as part of the development process. Legally speaking, you don't need two separate and isolated groups of people, but starting from a document of how the system 'should' work and then adding in implementation details that you actually need is a good way to avoid accidentally copying things you don't need to.

Only a clean-house reimplementation, by not looking at the code, just the functionality.

Could one do this alone if they had confirmed split personality disorder?

yep, just waiting on gcc-rust support to land and then we'll be moving our Rust interfaces into the kernel

gcc-rs will take a few years, rustc_codegen_gcc is pretty close to being ready to go.

Reply on news.ycombinator.com