From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KZkqq-0003tP-1F for qemu-devel@nongnu.org; Sun, 31 Aug 2008 07:12:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KZkqo-0003rx-8H for qemu-devel@nongnu.org; Sun, 31 Aug 2008 07:12:11 -0400 Received: from [199.232.76.173] (port=50063 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZkqn-0003rq-WA for qemu-devel@nongnu.org; Sun, 31 Aug 2008 07:12:10 -0400 Received: from il.qumranet.com ([212.179.150.194]:37355) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KZkqm-0003xO-H7 for qemu-devel@nongnu.org; Sun, 31 Aug 2008 07:12:09 -0400 Received: from gleb-debian.qumranet.com (gleb-debian.qumranet.com.qumranet.com [172.16.15.143]) by il.qumranet.com (Postfix) with ESMTP id 43521250EDA for ; Sun, 31 Aug 2008 14:12:06 +0300 (IDT) Date: Sun, 31 Aug 2008 14:12:06 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCH v3 1/6] Use IO port for qemu<->guest BIOS communication. Message-ID: <20080831111206.GF6192@minantech.com> References: <20080828165232.22851.77678.stgit@gleb-debian.qumranet.com.qumranet.com> <20080828165237.22851.1532.stgit@gleb-debian.qumranet.com.qumranet.com> <20080829190041.GA18301@minantech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Sat, Aug 30, 2008 at 10:57:34PM +0300, Blue Swirl wrote: > On 8/29/08, Gleb Natapov wrote: > > On Thu, Aug 28, 2008 at 09:04:11PM +0300, Blue Swirl wrote: > > > On 8/28/08, Gleb Natapov wrote: > > > > + fw_cfg_add(fw_cfg, FW_CFG_ID, (uint8_t *)&bios_cfg_id, > > > > + sizeof(bios_cfg_id)); > > > > > > On second thought, this is in host byte order, which is not a good idea. > > > > > > > Is there some function to convert from host byte order to target byte > > order? > > I made an updated version of the patch 1/6, with explicit little > endian conversions. I'm not very happy with that. Another way would be > to add functions just to put different size numbers into device and > they would hide the conversion. > So what approach we should go with? We can go with the second one (add functions for each type) and extend interface as needed. -- Gleb.