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

[Anthony Liguori]

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