From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 05:32:18 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6E209106566C; Wed, 16 May 2012 05:32:18 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mail.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by mx1.freebsd.org (Postfix) with ESMTP id 146448FC0C; Wed, 16 May 2012 05:32:17 +0000 (UTC) Received: from kas30pipe.localhost (localhost.kirov.so-ups.ru [127.0.0.1]) by mail.kirov.so-ups.ru (Postfix) with SMTP id 79848B801B; Wed, 16 May 2012 09:32:09 +0400 (MSK) Received: from kirov.so-ups.ru (unknown [172.21.81.1]) by mail.kirov.so-ups.ru (Postfix) with ESMTP id 7410CB8008; Wed, 16 May 2012 09:32:09 +0400 (MSK) Received: by ns.kirov.so-ups.ru (Postfix, from userid 1010) id 6E6C3BA03E; Wed, 16 May 2012 09:32:09 +0400 (MSK) Received: from [127.0.0.1] (unknown [10.118.3.52]) by ns.kirov.so-ups.ru (Postfix) with ESMTP id 3870DBA022; Wed, 16 May 2012 09:32:09 +0400 (MSK) Message-ID: <4FB33BD9.3030501@FreeBSD.org> Date: Wed, 16 May 2012 09:32:09 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: John Baldwin References: <4FA95960.7090908@shadowsun.net> <4FB17B85.9080701@shadowsun.net> <201205151144.38123.jhb@freebsd.org> In-Reply-To: <201205151144.38123.jhb@freebsd.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release X-SpamTest-Info: Not protected Cc: freebsd-hackers@freebsd.org, Eric McCorkle Subject: Re: GSoC Project: EFI on amd64/i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 05:32:18 -0000 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