Date: Mon, 30 Mar 2015 18:57:23 -0400 From: Eric McCorkle <eric@metricspace.net> To: freebsd-hackers@freebsd.org Subject: Re: ZFS support for EFI Message-ID: <5519D4D3.6080707@metricspace.net> In-Reply-To: <543637C0-A4FF-4801-BE5C-859F2D968D48@me.com> References: <55189CBA.9040107@metricspace.net> <543637C0-A4FF-4801-BE5C-859F2D968D48@me.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/30/2015 12:28 AM, Rui Paulo wrote: >> 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.) > > Good. :-) Actually, would that be a good patch in its own right? I could certainly strip out the ZFS-related stuff for folks with UFS+EFI systems to test. (I only have ZFS drives myself) > I have a crazy idea: why not use getopt() in loader.efi ? getopt() is already part of libstand, so it should be easy to use it. > > Alternatively you can just use key value pairs. > I did a little more lookung. Turns out, I had it wrong. The old ZFS loader loads and parses /boot/config, not /boot/loader.conf. It appears that the existing EFI loader is ignoring /boot/config. Is that intentional, or just missing functionality? (It would probably make more sense to stash /boot/config or its analog on the ESP anyway.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5519D4D3.6080707>