From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCHv4 15/15] Pass boot device list to firmware. Date: Mon, 15 Nov 2010 09:53:50 +0200 Message-ID: <20101115075350.GC22248@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Kevin O'Connor" , qemu-devel@nongnu.org, kvm@vger.kernel.org, blauwirbel@gmail.com, armbru@redhat.com, alex.williamson@redhat.com To: Gleb Natapov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:10776 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752980Ab0KOHyE (ORCPT ); Mon, 15 Nov 2010 02:54:04 -0500 Content-Disposition: inline In-Reply-To: <20101115074008.GF7948@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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: > > On Sun, Nov 14, 2010 at 05:39:41PM +0200, Gleb Natapov wrote: > > > +/* > > > + * This function returns device list as an array in a below format: > > > + * +-----+-----+---------------+-----+---------------+-- > > > + * | n | l1 | devpath1 | l2 | devpath2 | ... > > > + * +-----+-----+---------------+-----+---------------+-- > > > + * where: > > > + * n - a number of devise pathes (one byte) > > > + * l - length of following device path string (one byte) > > > + * devpath - non-null terminated string of length l representing > > > + * one device path > > > + */ > > > > 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? Do a memory scan, count newlines until you reach 0? > Doing it > like Blue suggest (have BOOTINDEX_LEN and BOOTINDEX_STRING) solves this. > To create nice array from bootindex string you firmware will still have > to do additional pass on it though. Why is this a problem? Pass over memory is cheap, isn't it? > With format like above the code > would look like that: > > qemu_cfg_read(&n, 1); > arr = alloc(n); > for (i=0; i qemu_cfg_read(&l, 1); > arr[i] = zalloc(l+1); > qemu_cfg_read(arr[i], l); > } > > > -- > Gleb. At this point I don't care about format. But I would like one without 1-byte-length limitations, just so we can cover whatever pci can through at us. -- MST