loader: create single zfs nextboot implementation

[tsoome]

Summary

We should have nextboot feature implemented in libsa zfs code.
To get there, I have created zfs_nextboot() implementation based on
two sources, our current simple textual string based approach with added
structured boot label PAD structure from OpenZFS.

Secondly, all nvlist details are moved to separate source file and
restructured a bit. This is done to provide base support to add nvlist
add/update feature in followup updates.

And finally, the zfsboot/gptzfsboot disk access functions are swapped to use
libi386 and libsa.

[allanjude]

stand/i386/gptzfsboot/Makefile

26

Do we want to build UFS support into gptzfsboot? I guess it doesn't hurt

[tsoome]

shield ufs with LOADER_UFS_SUPPORT and do not include ufs support
for gptzfsboot (for now). We still do provide ufs for zfsboot.

The gptzfsboot should fit in 128k and ufs bits will get us just above 128k.
zfsboot is not affected, because zfsboot is stored in zfs pool label bootblock
area and has size limit set to ~240k (area itself is 3.5MB).

[tsoome]

stand/i386/gptzfsboot/Makefile

26

Eventually yes, but removed for now. It is 14k and without it, we will stay below 128k.

[jhb]

FWIW, my hope had been to have a single gptboot that does both UFS + ZFS. I don't envy the logic to figure out which one to boot from if both are present though. :) What is the current size bsdinstall uses for freebsd-boot and how long ago has it been 128k?

[tsoome]

In D25324#559399, @jhb wrote:

FWIW, my hope had been to have a single gptboot that does both UFS + ZFS. I don't envy the logic to figure out which one to boot from if both are present though. :) What is the current size bsdinstall uses for freebsd-boot and how long ago has it been 128k?

merging those bits will take some time. The current freebsd-boot is created 512k and the zfsldr code is reading 256k, so with current code, we are actually well within the limits. The question is about old setups.

[imp]

In D25324#559405, @tsoome wrote:

In D25324#559399, @jhb wrote:

FWIW, my hope had been to have a single gptboot that does both UFS + ZFS. I don't envy the logic to figure out which one to boot from if both are present though. :) What is the current size bsdinstall uses for freebsd-boot and how long ago has it been 128k?

merging those bits will take some time. The current freebsd-boot is created 512k and the zfsldr code is reading 256k, so with current code, we are actually well within the limits. The question is about old setups.

Old setups aren't that relevant. People generally don't update these boot blocks. And if they do, they can steal space from swap space to create a new partition. It shouldn't be a blocking issue given the level of need and the easy workarounds in the default and typical installs having a swap partition from that era. 256k might be a harder limit. We should see when it was bumped to 512k, but I think it was in the run up to 10.0...

The logic for both on the same disk you are booting from likely can be the same as /boot/loader: zfs wins if it is bootable. Otherwise, the first UFS partition is fine....

[allanjude]

In D25324#559399, @jhb wrote:

FWIW, my hope had been to have a single gptboot that does both UFS + ZFS. I don't envy the logic to figure out which one to boot from if both are present though. :) What is the current size bsdinstall uses for freebsd-boot and how long ago has it been 128k?

bsdinstall creates the freebsd-boot partition as 512kb