Note for those pulling in new ZFS feature flags

[Ben Morrow]

Quoth Chris Nehren <cnehren+freebsd-stable at pobox.com>:
> 
> Are you asking, in other words, what problems could come from
> fixing the bootcode automatically whenever it's needed?  The
> immediate, obvious concern is that maybe the bits sourced to do
> so aren't valid for the pool in question[0] or don't exist.  The
> latter is easy to check for of course.  I'm afraid I don't know
> enough to judge the former.
> 
> [0]: Although I can't imagine a situation when that'd be the
> case, that doesn't mean such a sitaution doesn't exist.

Upgrading a pool on a disk which happens to be attached to this machine
at the moment but which is supposed to boot a different architecture?
(Rather obscure, I know.)

More generally, is it possible to determine post-boot which disk the
bootloader actually ran from, and which of {gpt,}{zfs,}boot it was? It
would hardly be helpful to 'upgrade' a /boot-on-UFS machine to a ZFS
bootloader. Then there's the question of whether FreeBSD's bootstrap is in
use at all, rather than something like GRUB.

One possibility might be to put a Makefile in /boot which can be
customised as necessary; then zfs upgrade could just run 'make -C /boot
install' and assume it would DTRT.

Ben