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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
