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.

AFAIK, ia64 loader works in that way.

--
WBR, Andrey V. Elsukov
_______________________________________________
freebsd-hackers@free... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@free..."