Oh, I misunderstood. I thought the input back into Linux ZFS grew out of the (Free)BSD work. If its two independent OS trees both referring upstream to Illumos, its a minor moment.
What does the solaris compatibility shim do in the end, which couldn't be done direct in the codebase? I don't like shims, it feels like the linux compatibility ABI moment where something gets added and the shim drifts, and then you can't do eg DRI any more because "they changed how it worked and we didn't catch up"
But, thanks for the cluestick hit. If this is just flavour of ice-cream from the same truck, I'm less worried.
The shim, as I understand it, for linux is there to both handle some licensing differences and to also translate between Linux's io subsystem which isn't going to be turned into Solaris' nor will ZFS's be turned into Linux's IO subsystem directly. They're basically compatible but have different ways of doing things so it results in needing a shim to handle things.
I don't know a lot about it, but my understanding is that the shim is pretty thin, there to translate some slightly different syscall conventions. Compatibility shims done well (minimal to no overhead) can be very beneficial, allowing separate projects to share more code directly.
On a separate note, illumos is a really cool project. I hope this transition (and apparent reduced activity in their development on ZFS) is not a symptom of the project losing momentum. My first experiences with a computer were on SunOS and early Solaris, and illumos is the the [open source] heir to that throne.
What does the solaris compatibility shim do in the end, which couldn't be done direct in the codebase? I don't like shims, it feels like the linux compatibility ABI moment where something gets added and the shim drifts, and then you can't do eg DRI any more because "they changed how it worked and we didn't catch up"
But, thanks for the cluestick hit. If this is just flavour of ice-cream from the same truck, I'm less worried.