ZFS support for EFI

[Eric McCorkle]

I've gotten the ZFS loader to the point where it successfully loads and
attempts to execute the next stage.

I wouldn't say boot1 is in its final state; there's going to have to be
some way to get information about zfs from boot1 to loader, but I
suspect that will fall into place when I'm working on loader itself.

Please try this out on both UFS and ZFS systems, and verify that it does
in fact successfully get all the way through the loading process.

There's also a couple of issues I want to fix before the end:

1) The Malloc implementation uses the EFI memory pool allocator.  This
may not be the best way to go.

2) The module interface probably ought to expose a function that tries
to load a file, returning its contents, rather than trying to load and
execute a file.  This would better support new filesystems, as well as
things like checking cryptographic signatures.

On 04/17/2015 10:50 AM, Eric McCorkle wrote:
> I did some work on this last weekend.  I've got the zfs-enabled boot1
> loading the ZFS uberblock, but it stops somewhere in the vdev_probe
> code, believing the block to be a log.
> 
> I've attached a patch if anyone wants to play around with it.
> 
> Also, if someone with a UFS system could test that the modularization
> didn't break UFS functionality, that'd be helpful.
> 
> On 03/29/2015 08:45 PM, Eric McCorkle wrote:
>> Hi folks,
>>
>> I've been messing around off and on for a while with adding ZFS support
>> to the EFI boot.  It's been mostly exploratory and self-contained up to
>> this point, but I've gotten to a point that warrants some discussion.
>>
>>
>> First, I've converted boot1.c (the EFI boot block) to use an FS module
>> framework.  This facilitates the addition of ZFS, and should also come
>> in handy if someone wants to add other functionality later (ie. crypto,
>> netboot, etc.)
>>
>>
>> More importantly, the EFI loader doesn't seem to make use of its
>> command-line arguments at all.  But a ZFS-enabled loader would really
>> need the ability to take arguments from boot1 (or grub, or whatever
>> else).  On the boot1 side, with ZFS you need to load and parse
>> /boot/loader.conf (which may cause you to switch pools), then hand off
>> the information to loader.  In the BIOS loader, that's done through a
>> binary data object that gets passed in.  Command-line strings seem like
>> the most sensible way to do it with EFI.
>>
>> Would this be the right way to go, and if so, what ought these
>> command-line strings look like?
>>
>>
>> Thanks,
>> Eric
>> _______________________________________________
>> freebsd-hackers at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>>
>>
>>
>> _______________________________________________
>> freebsd-hackers at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zfsefi.diff
Type: text/x-patch
Size: 30754 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20150419/72af4c03/attachment.bin>