EFI ZFS loader successful load and boot

[Eric McCorkle]

My work on ZFS support for EFI has now progressed to the point where I
have successfully loaded and booted a kernel.  The patch I have attached
includes modifications to both boot1 and loader.  The modified
loader.efi can be loaded and run by boot1 or an appropriately-configured
GRUB (I've tested with both).

The code is not ready for integration; however, it is at this point
ready for testing.  The following need to be done, IMO, before it can be
considered for integration:

* boot1 completely ignores partition type GUIDs and probes everything.
A notable effect of this are the "Not ufs" messages that show up.

* There is some commented-out code for looking at command-line arguments
in loader.  It turns out I didn't need to do that.

* I (ab)use the EFI pool allocator in a malloc-like fashion, allocating
single objects in boot1.  This might be OK, but someone with more EFI
knowledge should probably comment as to whether or not it is.

* A future refactoring project that might be useful would be to add a
payload field to the end of struct devdesc, similar to what is done with
struct sockaddr.  That way, extended devdesc structures (like
zfs_devdesc) could be handled in the same way that struct sockaddr_in,
etc are.  If you look at my code, there are a couple of places where I
explicitly check for ZFS, and have separate branches that create
zfs_devdesc's


Please apply and test my patch with both UFS and ZFS filesystems.



There is also one other issue, which I think is the fault of my hardware...

When I boot a kernel in EFI mode, it prints info about the EFI console,
then the screen freezes.  However, I can tell that the kernel and OS
finish booting, because functions like suspend-on-lid-close and the
power button work as normal after a while.  However, when waking from
suspend, the screen is just blank.

This resembles an issue I've had with this particular laptop, which I've
reported before on the ACPI list.  Given this as well as basic common
sense, I think it's extremely unlikely that this issue arises as a
result of my modifications to loader.

If anyone out there has a ZFS-based system and can confirm or deny this,
that would be extremely useful information.


Thanks,
Eric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zfsefi.diff
Type: text/x-patch
Size: 47707 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20150523/5cd1ea11/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20150523/5cd1ea11/attachment.sig>