Hey all,

I'm interested in trying to enable support for boot-time modification of
the grubenv file on ZFS and other non-standard filesystems that don't
necessarily work today. I have a proposed design, and I was wondering if
you all would be interested in it. I'd be implementing it and testing it
myself, my main goal was to try to make sure that after doing so, the
community would be interested in integrating it. This has the dual
advantage of allowing everyone using ZFS and other filesystems to benefit
from it, and also making it so I don't have to maintain a fork indefinitely.

The proposal is that rather than always opening the grubenv file and
reading it using the normal file API, we can add a function (or functions)
to the fs struct that allows a filesystem to advertise that it needs to use
special logic to handle writable files. Then the grubenv file can be stored
in a special location (probably one of that padding areas in the label,
which is where the FreeBSD loader stores some boot data in zfs) where it
can be written safely by the bootloader without harming the checksum tree
in ZFS. The GRUB code would need to change to invoke the special "Please
let the fs handle this writable file" logic (which would have open, read,
and write functions) for filesystems that have them available, but this
should be extensible to other CoW or sparse filesystems like BTRFS. If a
filesystem doesn't advertise that logic, GRUB would fall back to using the
currently file-based logic.

An alternative proposal that I found slightly less elegant but would
involve fewer invasive changes is to just modify the zfs grub logic to
check if it's opening the grubenv file, and if so divert to special read
and open logic that would access this padding area. This would involve
hardcoding the grubenv file name in the ZFS code, but I figured I would
mention it as a possibility in case it was preferred for other reasons.

Do people have thoughts or opinions about this concept and this design? I
would greatly appreciate any feedback or thoughts on alternative
approaches. Thank you for your time and attention!

-- 
Paul Dagnelie
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Reply via email to