From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NUTR6-0001U7-P7 for qemu-devel@nongnu.org; Mon, 11 Jan 2010 18:12:36 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NUTR2-0001RI-3z for qemu-devel@nongnu.org; Mon, 11 Jan 2010 18:12:36 -0500 Received: from [199.232.76.173] (port=44776 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NUTR1-0001R2-Re for qemu-devel@nongnu.org; Mon, 11 Jan 2010 18:12:31 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]:50860) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NUTR1-0004o3-Fl for qemu-devel@nongnu.org; Mon, 11 Jan 2010 18:12:31 -0500 Received: by yxe26 with SMTP id 26so21133092yxe.4 for ; Mon, 11 Jan 2010 15:12:28 -0800 (PST) Message-ID: <4B4BB059.9020200@codemonkey.ws> Date: Mon, 11 Jan 2010 17:12:25 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4B45C209.1030802@mail.berlios.de> <1262862925-5205-1-git-send-email-weil@mail.berlios.de> <20100107123400.GE599@redhat.com> <4B45F8AE.1050400@mail.berlios.de> <20100111183437.GA13712@redhat.com> <4B4B7E4D.5010101@mail.berlios.de> <20100111194053.GA15857@redhat.com> <4B4B87AB.10100@mail.berlios.de> <20100111203011.GC15944@redhat.com> <4B4B9D5A.9050805@codemonkey.ws> <4B4BA1C6.2040202@mail.berlios.de> In-Reply-To: <4B4BA1C6.2040202@mail.berlios.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC] API change for pci_set_word and related functions List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" On 01/11/2010 04:10 PM, Stefan Weil wrote: >> I haven't read this whole thread, but I really prefer things like >> >> pci_set_vendor_id(pci_dev, XXXX); >> >> A close alternative, would be some refactoring to allow PCI config >> space to be represented as a C structure. Gerd had some patches at >> one point for this. >> >> Regards, >> >> Anthony Liguori >> > This is a good solution for the standard configuration entries, > so most code could use such calls if they were complete. > > For entries above offset 0x40, I'm afraid that it won't work > (neither with individual functions nor with a C structure). > Which is fine. Device specific entries in the config space are uncommon compared to the standard entries. The same model could apply (devices write their own wrapper functions). The problem with the set_word interface is that quite a lot of important config space fields are stored in a byte or less. Regards, Anthony Liguori > Regards, > > Stefan Weil > >