Date: Sun, 29 Mar 2015 21:28:45 -0700 From: Rui Paulo <rpaulo@me.com> To: Eric McCorkle <eric@metricspace.net> Cc: freebsd-hackers@freebsd.org Subject: Re: ZFS support for EFI Message-ID: <543637C0-A4FF-4801-BE5C-859F2D968D48@me.com> In-Reply-To: <55189CBA.9040107@metricspace.net> References: <55189CBA.9040107@metricspace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > On Mar 29, 2015, at 17:45, Eric McCorkle <eric@metricspace.net> wrote: >=20 > Hi folks, >=20 > 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. >=20 >=20 > 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. :-) > 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. >=20 > Would this be the right way to go, and if so, what ought these > command-line strings look like? 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. -- Rui Paulo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?543637C0-A4FF-4801-BE5C-859F2D968D48>