qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [RFC] API change for pci_set_word and related functions
Date: Mon, 11 Jan 2010 15:51:22 -0600	[thread overview]
Message-ID: <4B4B9D5A.9050805@codemonkey.ws> (raw)
In-Reply-To: <20100111203011.GC15944@redhat.com>

On 01/11/2010 02:30 PM, Michael S. Tsirkin wrote:
> On Mon, Jan 11, 2010 at 09:18:51PM +0100, Stefan Weil wrote:
>    
>> Michael S. Tsirkin schrieb:
>>      
>>> On Mon, Jan 11, 2010 at 08:38:53PM +0100, Stefan Weil wrote:
>>>        
>>>> Michael S. Tsirkin schrieb:
>>>>          
>>>>> On Thu, Jan 07, 2010 at 04:07:26PM +0100, Stefan Weil wrote:
>>>>>            
>>>>>> Michael S. Tsirkin schrieb:
>>>>>>              
>>>>>>> On Thu, Jan 07, 2010 at 12:15:25PM +0100, Stefan Weil wrote:
>>>>>>> ...
>>>>>>>                
>>>>>>>> - PCI_CONFIG_16(PCI_STATUS,
>>>>>>>> - PCI_STATUS_REC_MASTER_ABORT | PCI_STATUS_SIG_TARGET_ABORT);
>>>>>>>> + PCI_CONFIG_16(PCI_STATUS, PCI_STATUS_DEVSEL_MEDIUM |
>>>>>>>> PCI_STATUS_FAST_BACK);
>>>>>>>> /* PCI Revision ID */
>>>>>>>> PCI_CONFIG_8(PCI_REVISION_ID, 0x08);
>>>>>>>>                  
>>>>>>> BTW if you are not afraid of churn, there's no reason
>>>>>>> for PCI_CONFIG_8 and friends anymore, because pci.h
>>>>>>> has much nicer pci_set_byte etc.
>>>>>>>                
>>>>>> Hello Michael,
>>>>>>
>>>>>> I already noticed pci_set_byte, pci_set_word, pci_set_long and
>>>>>> the corresponding pci_get_xxx functions and thought about using them.
>>>>>>
>>>>>> I did not start it because I want to suggest a different API
>>>>>> for use in PCI device emulations:
>>>>>>
>>>>>> instead of
>>>>>>
>>>>>> pci_set_word(pci_conf + PCI_STATUS, PCI_STATUS_CAP_LIST);
>>>>>>
>>>>>> or
>>>>>>
>>>>>> pci_set_word(&pci_conf[PCI_STATUS], PCI_STATUS_CAP_LIST);
>>>>>>
>>>>>> it would be better to call
>>>>>>
>>>>>> pci_set_word(pci_conf, PCI_STATUS, PCI_STATUS_CAP_LIST);
>>>>>>
>>>>>>
>>>>>> The prototypes would look like this:
>>>>>>
>>>>>> /* Set PCI config value. */
>>>>>> void pci_set_word(PCIDevice *s, uint8_t offset, uint16_t val);
>>>>>>
>>>>>> /* Set PCI cmask value. */
>>>>>> void pci_set_cmask_word(PCIDevice *s, uint8_t offset, uint16_t val);
>>>>>>
>>>>>> /* Set PCI wmask value. */
>>>>>> void pci_set_wmask_word(PCIDevice *s, uint8_t offset, uint16_t val);
>>>>>>
>>>>>> What are the advantages?
>>>>>> * strict type checking (the old API takes any uint8_t *)
>>>>>>              
>>>>> So IMO it's easier to make mistakes with your proposed API because if
>>>>> you confuse offset and value compiler does not complain. More
>>>>> importantly, if you want to pass some other uint8_t pointer to e.g.
>>>>> pci_set_word, you can *and nothing unexpected will happen*
>>>>> it will set the word to the given value. So the current
>>>>> API is more type safe than what you propose.
>>>>>
>>>>>            
>>>> No. The current API takes any uint8_t pointer to read or write
>>>> a value. This is not safe.
>>>>          
>>> Why isn't it?
>>>        
>> It is not safe, because it allows programmers to write silly code
>> like these examples:
>>
>> pci_set_word(&gen_opc_cc_op[PCI_STATUS], PCI_STATUS_CAP_LIST);
>>      
> This might be valid and useful for all I know.
>
>    
>> pci_set_word(&pci_conf[UINT32_MAX], PCI_STATUS_CAP_LIST);
>>
>> for (i = 0; i<  sizeof(pci_conf); i++) {
>>      pci_set_long(&pci_conf[i], 0);
>> }
>>
>> All three will result in runtime failures which can be very
>> difficult to detect.
>>      
> In theory. In practice I expect pci_set_word(pci_dev, 0x0, PCI_STATUS)
> to be much more common with your proposed API. Just look how
> common swapping memset parameters is.
>
>    
>>>        
>>>> The proposed API only takes a PCIDevice pointer
>>>> and reads or writes only configuration (or cmask or
>>>> wmask) values. Yes, you can take offset for value.
>>>> If you are lucky and value is an uint16_t or uint32_t,
>>>> your compiler will complain.
>>>>          
>>> Such a compiler will also complain over most of qemu code.
>>>        
>> Yes, but it's good to see that QEMU's code is
>> improving.
>>
>> By the way, such a compiler is gcc when called with
>> -Wconversion, so it is easy to see how much code
>> is affected.
>>      
> Didn't try it. So it will warn on
> pci_set_word(pci_dev, 0x0, PCI_STATUS)
> but not
> pci_set_word(pci_dev, PCI_STATUS, 0x0)
> ?
>    

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

  reply	other threads:[~2010-01-11 21:51 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1260466626.git.mst@redhat.com>
2009-12-10 18:09 ` [Qemu-devel] [PATCH 01/17] e1000: switch to symbolic names for pci registers Michael S. Tsirkin
2009-12-10 18:09 ` [Qemu-devel] [PATCH 02/17] ne2000: " Michael S. Tsirkin
2009-12-10 18:09 ` [Qemu-devel] [PATCH 03/17] rtl: " Michael S. Tsirkin
2009-12-10 18:10 ` [Qemu-devel] [PATCH 04/17] pcnet: " Michael S. Tsirkin
2009-12-10 18:10 ` [Qemu-devel] [PATCH 05/17] pci: add more status bits Michael S. Tsirkin
2009-12-10 18:10 ` [Qemu-devel] [PATCH 06/17] eepro100: symbolic names for pci registers Michael S. Tsirkin
2010-01-07 11:14   ` Stefan Weil
2010-01-07 11:15     ` [Qemu-devel] [PATCH] eepro100: Fix initial value for PCI_STATUS Stefan Weil
2010-01-07 12:34       ` [Qemu-devel] " Michael S. Tsirkin
2010-01-07 15:07         ` [Qemu-devel] [RFC] API change for pci_set_word and related functions (was Re: [PATCH] eepro100: Fix initial value for PCI_STATUS) Stefan Weil
2010-01-11 18:34           ` [Qemu-devel] " Michael S. Tsirkin
2010-01-11 19:38             ` [Qemu-devel] Re: [RFC] API change for pci_set_word and related functions Stefan Weil
2010-01-11 19:40               ` Michael S. Tsirkin
2010-01-11 20:18                 ` Stefan Weil
2010-01-11 20:30                   ` Michael S. Tsirkin
2010-01-11 21:51                     ` Anthony Liguori [this message]
2010-01-11 22:10                       ` Stefan Weil
2010-01-11 23:12                         ` Anthony Liguori
2010-01-07 12:51     ` [Qemu-devel] [PATCH 06/17] eepro100: symbolic names for pci registers Michael S. Tsirkin
2010-01-07 13:41       ` Anthony Liguori
2010-01-07 13:32     ` Anthony Liguori
2010-01-07 14:26       ` Stefan Weil
2009-12-10 18:10 ` [Qemu-devel] [PATCH 07/17] piix: symbolic constants Michael S. Tsirkin
2009-12-10 18:10 ` [Qemu-devel] [PATCH 08/17] cmd646: symbolic names for pci registers Michael S. Tsirkin
2009-12-10 18:11 ` [Qemu-devel] [PATCH 09/17] vmware_vga: " Michael S. Tsirkin
2009-12-10 18:11 ` [Qemu-devel] [PATCH 10/17] lsi: " Michael S. Tsirkin
2009-12-10 18:11 ` [Qemu-devel] [PATCH 11/17] pci: add another devsel macro Michael S. Tsirkin
2009-12-10 18:11 ` [Qemu-devel] [PATCH 12/17] es1370: symbolic names for pci registers Michael S. Tsirkin
2009-12-10 18:11 ` [Qemu-devel] [PATCH 13/17] wdt_i6300esb: " Michael S. Tsirkin
2009-12-10 18:11 ` [Qemu-devel] [PATCH 14/17] ac97: " Michael S. Tsirkin
2009-12-10 18:11 ` [Qemu-devel] [PATCH 15/17] usb-uhci: " Michael S. Tsirkin
2009-12-10 18:11 ` [Qemu-devel] [PATCH 16/17] " Michael S. Tsirkin
     [not found]   ` <m3my1okxnw.fsf@neno.neno>
2009-12-12 20:34     ` [Qemu-devel] " Michael S. Tsirkin
2009-12-10 18:11 ` [Qemu-devel] [PATCH 17/17] pci: remove unused macro Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B4B9D5A.9050805@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).