From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36241 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PNd4L-0002MD-JS for qemu-devel@nongnu.org; Tue, 30 Nov 2010 22:09:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PNcpS-0007FJ-Mv for qemu-devel@nongnu.org; Tue, 30 Nov 2010 21:54:00 -0500 Received: from mail-vw0-f45.google.com ([209.85.212.45]:44107) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PNcpS-0006lW-Dt for qemu-devel@nongnu.org; Tue, 30 Nov 2010 21:53:58 -0500 Received: by vws12 with SMTP id 12so2401866vws.4 for ; Tue, 30 Nov 2010 18:53:36 -0800 (PST) Date: Tue, 30 Nov 2010 21:53:32 -0500 From: Kevin O'Connor Message-ID: <20101201025332.GA6877@morn.localdomain> References: <20101127174726.GA15238@morn.localdomain> <20101127181541.GC14385@redhat.com> <20101127184012.GA17455@morn.localdomain> <20101127190424.GD14385@redhat.com> <20101127210744.GA21727@morn.localdomain> <20101128074534.GE6897@redhat.com> <20101128171543.GA21987@morn.localdomain> <20101128184734.GE14385@redhat.com> <20101130013402.GB3488@morn.localdomain> <20101130140100.GH2187@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101130140100.GH2187@redhat.com> Subject: [Qemu-devel] Re: [PATCHv6 00/16] boot order specification List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: seabios@seabios.org, qemu-devel@nongnu.org, kvm@vger.kernel.org On Tue, Nov 30, 2010 at 04:01:00PM +0200, Gleb Natapov wrote: > On Mon, Nov 29, 2010 at 08:34:03PM -0500, Kevin O'Connor wrote: > > On Sun, Nov 28, 2010 at 08:47:34PM +0200, Gleb Natapov wrote: > > > If you let go to the idea of exact matching of string built by qemu in > > > Seabios it will be easy to see that /pci@i0cf8/ethernet@4/ethernet-phy@0 > > > provides everything that Seabios needs to know and even more. If > > > you ignore all the noise it just says "boot from pci device slot 4 fn > > > 0". Seabios may have native support for the card in the slot or it can > > > use option rom on the card. Qemu does not care. > > > > I'm having a hard time letting go of string matching. I understand > > all the info is there if SeaBIOS parses the string. However, I think > > parsing out openbios device strings is overkill in an x86 bios that > > just wants to order the boot objects it knows about. > > > > Is there an issue with qemu generating two strings for devices with > > roms? > > > I just do not see how I can justify this addition to qemu maintainers > given that the parsing code below is very simple. It doesn't look correct to me - it doesn't handle the case where the PCI device is on a bridge. BTW, what's the plan for handling SCSI adapters? Lets say a user has a scsi card with three drives (lun 1, lun 3, lun 5) that show up as 3 bcvs (lun1, lun3, lun5 in that order) and the user wishes to boot from lun3. I understand this use case may not be important for qemu, but I'd like to use the same code on coreboot. Being able to boot from any drive is important - it doesn't have to autodetect, but it should be possible. -Kevin