On 15.05.2012 19:44, John Baldwin wrote:
>> It seems having the EFI boot service load the kernel directly is the
>> way to go, based on Andrey's reply, the existing code, and my own
>> intuition. I just wanted to ask, in case there was some compelling
>> reason to have the EFI boot service load loader(8) instead.
> So this means /boot/loader will be an EFI service, yes?
No, EFI services are things that EFI firmware provides. Our /boot/loader
will be an EFI application and it will use EFI services.
>> On the other hand, I think it's a good idea to use libstand/libi386
>> whenever possible, even if it ends up calling through to EFI
>> functions, as it keeps things standardized.
> Eh, not sure if we really want to do that. For example, we are probably
> better off using EFI's GPT parsing code than depending on all the gunk to do
> that in biosdisk.c.
As i see we already have sys/boot/efi/libefi/efipart.c that uses EFI BLOCK_IO_PROTOCOL
to make "part" devsw. EFI BLOCK_IO_PROTOCOL provides access to each disk and partition.
AFAIK it supports only GPT and MBR+EBR, so there might be some problems with ZFS
support, because we can use ZFS atop of BSD partition.
> Presumably the EFI boot loader wouldn't even use biosdisk.c or bioscd.c for
> example, but only libstand drivers that talk to EFI. Not sure if Rui's EFI
> loader already does this.