From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=46436 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PHzEd-0002Hp-VZ
	for qemu-devel@nongnu.org; Mon, 15 Nov 2010 08:36:41 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <gleb@redhat.com>) id 1PHzEa-0002Ow-3w
	for qemu-devel@nongnu.org; Mon, 15 Nov 2010 08:36:37 -0500
Received: from mx1.redhat.com ([209.132.183.28]:44773)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <gleb@redhat.com>) id 1PHzEZ-0002Oo-R7
	for qemu-devel@nongnu.org; Mon, 15 Nov 2010 08:36:36 -0500
Date: Mon, 15 Nov 2010 15:36:25 +0200
From: Gleb Natapov <gleb@redhat.com>
Message-ID: <20101115133625.GN7948@redhat.com>
References: <1289749181-12070-1-git-send-email-gleb@redhat.com>
	<1289749181-12070-16-git-send-email-gleb@redhat.com>
	<20101115034033.GA1309@morn.localdomain>
	<20101115074008.GF7948@redhat.com>
	<20101115132635.GA14119@morn.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20101115132635.GA14119@morn.localdomain>
Subject: [Qemu-devel] Re: [PATCHv4 15/15] Pass boot device list to firmware.
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Kevin O'Connor <kevin@koconnor.net>
Cc: kvm@vger.kernel.org, mst@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, blauwirbel@gmail.com, alex.williamson@redhat.com

On Mon, Nov 15, 2010 at 08:26:35AM -0500, Kevin O'Connor wrote:
> On Mon, Nov 15, 2010 at 09:40:08AM +0200, Gleb Natapov wrote:
> > On Sun, Nov 14, 2010 at 10:40:33PM -0500, Kevin O'Connor wrote:
> > > Why not just return a newline separated list that is null terminated?
> > > 
> > Doing it like this will needlessly complicate firmware side. How do you
> > know how much memory to allocate before reading device list?
> 
> My preference would be for the size to be exposed via the
> QEMU_CFG_FILE_DIR selector.  (My preference would be for all objects
> in fw_cfg to have entries in QEMU_CFG_FILE_DIR describing their size
> in a reliable manner.)
> 
Will interface suggested by Blue will be good for you? The one with two
fw_cfg ids. BOOTINDEX_LEN for len and BOOTINDEX_DATA for device list. I
already changed my implementation to this one. Using FILE_DIR requires
us to generate synthetic name. Hmm BTW I do not see proper endianness
handling in FILE_DIR.

--
			Gleb.