From: Stuart Brady <sdbrady@ntlworld.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value instead of int.
Date: Mon, 13 Jul 2009 22:19:05 +0100 [thread overview]
Message-ID: <20090713211905.GA10557@miranda.arrow> (raw)
In-Reply-To: <4A5B8413.5080201@codemonkey.ws>
On Mon, Jul 13, 2009 at 01:59:31PM -0500, Anthony Liguori wrote:
> 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).
Isn't ram_addr_t solely for return values from (and internals of)
qemu_ram_alloc() and friends?
Perhaps port IO addresses should have their own type?
TBH, I'm not so sure that port IO is particularly 'special' in any way.
I suppose that generally speaking, code can't be executed from port IO
addresses (although that's not true on machines where 'port IO' is
actually memory mapped). I'm not sure how PCI fits into this, though.
Cheers,
--
Stuart Brady
next prev parent reply other threads:[~2009-07-13 21:19 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-02 10:32 [Qemu-devel] [PATCH 0/6] ioport related clean ups Isaku Yamahata
2009-07-02 10:32 ` [Qemu-devel] [PATCH 1/6] split out ioport related stuffs from vl.c into ioport.c Isaku Yamahata
2009-07-02 10:32 ` [Qemu-devel] [PATCH 2/6] use constant IOPORTS_MASK instead of 0xffff Isaku Yamahata
2009-07-02 10:32 ` [Qemu-devel] [PATCH 3/6] ioport: consolidate duplicated logic in register_ioport_{read, write}() Isaku Yamahata
2009-07-02 10:32 ` [Qemu-devel] [PATCH 4/6] ioport: remove some #ifdef DEBUG_UNUSED_IOPORT Isaku Yamahata
2009-07-02 10:32 ` [Qemu-devel] [PATCH 5/6] consolidate user cpu_{in, out}[bwl] into ioport-user.c Isaku Yamahata
2009-07-02 10:32 ` [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value instead of int Isaku Yamahata
2009-07-02 18:11 ` Stuart Brady
2009-07-02 18:30 ` Stuart Brady
2009-07-09 19:07 ` Anthony Liguori
2009-07-10 8:21 ` Samuel Thibault
2009-07-10 8:45 ` Isaku Yamahata
2009-07-10 8:54 ` Samuel Thibault
2009-07-10 9:09 ` Tristan Gingold
2009-07-10 12:59 ` Anthony Liguori
2009-07-10 13:12 ` Tristan Gingold
2009-07-10 13:16 ` Anthony Liguori
2009-07-10 13:28 ` Tristan Gingold
2009-07-10 12:55 ` Anthony Liguori
2009-07-13 3:14 ` Isaku Yamahata
2009-07-13 18:59 ` Anthony Liguori
2009-07-13 21:19 ` Stuart Brady [this message]
2009-07-13 21:28 ` Anthony Liguori
2009-07-14 1:58 ` Isaku Yamahata
2009-07-10 12:53 ` Anthony Liguori
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=20090713211905.GA10557@miranda.arrow \
--to=sdbrady@ntlworld.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).