Re: [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value instead of int.

[Anthony Liguori <anthony@codemonkey.ws>]

Isaku Yamahata wrote:
> On Fri, Jul 10, 2009 at 07:55:44AM -0500, Anthony Liguori wrote:
>   
>> Isaku Yamahata wrote:
>>     
>>> Then, the signatures should like the followings?
>>>
>>> void cpu_out[bwl](CPUState *env, int64_t addr, int{8, 16, 32}_t val);
>>> uint{8, 16, 32}_t cpu_inw(CPUState *env, int16_t addr);
>>>   
>>>       
>> If anything, it ought to be:
>>
>> void cpu_out[bwl](CPUState *env, uint16_t addr, int{8, 16, 32}_t val);
>>
>> But it's int today because the assumption is that most architectures can
>> more efficiently pass int than other types (because it's the native
>> type) and that int is adequate to contain all of the necessary types.
>>
>> But my original question still remains, what's the motivation for this
>> change?
>>     
>
> Yes, the patch description too terse.
> The motivation is to remove inconsistency with the other part of
> qemu.
>
> - Using int for cpu_{in, out}[bwl] is inconsistent with other part.
>   For address or value, uintN_t is used by other qemu part.
>   At least I can confirm, softmmu, CPU{Read, Write}MemoryFunc, pci,
>   target_phys_addr_t and the callers of cpu_{in, out}[bwl]().
>   

What does the PCI spec say about the size of PIO IO regions?  Can they 
be as large as MEM IO regions?

If so, I would think that we should use ram_addr_t for addr and then we 
can use the appropriate uintN_t type for value.  Switching value like 
that though could have some subtle consequences.  For instance, 
cpu_outb(env, ..., 128) would have worked properly before as would 
cpu_outb(env, ..., -32).

Regards,

Anthony Liguori