Disallow bootfs in conjunction with sha512/skein/edonr/large_dnode + future features

[bunder2015]

Describe the problem you're observing

I was looking into the possibility of adding more feature flag support to grub, mainly sha512 and large_dnode, and in requesting assistance on IRC, I've been told that any attempts to improve grub's boot code with further features would most likely be in violation of the CDDL and GPL.

Considering that grub already supports ZFS up to a certain point, I was under the impression that adding more features would be trivial, especially considering illumos already has support for sha512 and we share code back and forth on a frequent basis.

Seeing that we're (supposedly) not allowed to enhance grub at this point in time, I think it would seem appropriate for us to not allow users to enable these features on boot pools, or allow setting bootfs on pools with these feature flags enabled, at least until such a time where someone ports btx from freebsd/illumos to linux.

[sylveon]

I use EFISTUB to boot my bootfs. I don't know why I should be disallowed to use those features only because GRUB (which I don't use at all) doesn't supports them.

[bunder2015]

I wasn't aware that it was possible to boot without a bootloader. Sorry for giving you the wrong impression. However it might be appropriate to have a discussion of how to proceed with grub and if we should be looking for alternatives in the long-term.

[bunder2015]

I'm going to close this for now, as EFI stub booting appears to be a viable option, and since there aren't any code changes to make at this time. It might still be worthwhile to have a discussion about bootloaders for platforms that can't use UEFI, but the mailing list is more appropriate.

[rlaager]

For the recording, to add code to GRUB, you need to be able to at a minimum release it under GPLv3+. So you typically need to be the original author of code from ZFS if you want to re-use it, or you need to re-implement from scratch. That said, due to the differences in architecture (GRUB is much simpler, only needs to read, and needs to be low footprint), you're typically going to re-implement things anyway for GRUB.

However, that "at a minimum" bit really is the minimum, and is only applicable to small changes. For large changes, GRUB, as an FSF project, requires that you assign the copyright to them. This require real contracts and such, and typically requires your employer to sign a copyright release too. It is a significant burden. (I have actually done this to contribute some ZFS patches to GRUB, though they were higher-level, not filesystem code.)