From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KZlHp-0003JL-2Q for qemu-devel@nongnu.org; Sun, 31 Aug 2008 07:40:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KZlHm-0003HN-Di for qemu-devel@nongnu.org; Sun, 31 Aug 2008 07:40:04 -0400 Received: from [199.232.76.173] (port=35500 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZlHl-0003HF-W3 for qemu-devel@nongnu.org; Sun, 31 Aug 2008 07:40:02 -0400 Received: from wf-out-1314.google.com ([209.85.200.170]:43992) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KZlHl-0007tQ-IN for qemu-devel@nongnu.org; Sun, 31 Aug 2008 07:40:01 -0400 Received: by wf-out-1314.google.com with SMTP id 27so1451381wfd.4 for ; Sun, 31 Aug 2008 04:40:00 -0700 (PDT) Message-ID: Date: Sun, 31 Aug 2008 14:40:00 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] [PATCH v3 1/6] Use IO port for qemu<->guest BIOS communication. In-Reply-To: <20080831111206.GF6192@minantech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> <20080831111206.GF6192@minantech.com> 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 8/31/08, Gleb Natapov wrote: > 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. Okay, I'll make a new version.