qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	liu ping fan <qemulist@gmail.com>,
	qemu-devel@nongnu.org, Blue Swirl <blauwirbel@gmail.com>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [RFC v1 19/22] memory: per-AddressSpace dispatch
Date: Sun, 07 Oct 2012 12:34:58 +0200	[thread overview]
Message-ID: <50715AD2.8010207@redhat.com> (raw)
In-Reply-To: <CAFEAcA-LgipRQQ1rn_WSaMXLh1V_LQh4VrESF1i1t2peRKyS+Q@mail.gmail.com>

On 10/04/2012 09:16 PM, Peter Maydell wrote:
> On 4 October 2012 20:05, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> Blue Swirl <blauwirbel@gmail.com> writes:
>>> They can all be 64 bits, I'm just considering types. Getting rid of
>>> target_phys_addr_t, pcibus_t, pio_addr_t and dma_addr_t (are there
>>> more?) may be also worthwhile.
>>
>> Where this breaks down is devices that are DMA capable but may exist on
>> multiple busses.
>>
>> So you either end up with a device-specific type and a layer of casting
>> or weird acrobatics.
>>
>> It makes more sense IMHO to just treat bus addresses as a fixed with.
>>
>> target_phys_addr_t is a bad name.  I'd be in favor of either just using
>> uint64_t directly or having a generic dma_addr_t.
> 
> I agree that we only need one type; I think it's helpful to
> have a type name rather than direct use of uint64_t. dma_addr_t
> doesn't seem right because most of the usage of it isn't going to
> be in DMA related contexts. addr_t ?

*_t is reserved.

Suggestions:

 phys
 Phys
 hwaddr
 hw_addr

there are some variables named 'phys' scattered in the source, so my
current favorite is hwaddr.  Short and to the point.

-- 
error compiling committee.c: too many arguments to function

  reply	other threads:[~2012-10-07 10:35 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-03 16:03 [Qemu-devel] [RFC v1 00/22] Integrate DMA into the memory API Avi Kivity
2012-10-03 16:03 ` [Qemu-devel] [RFC v1 01/22] memory: rename 'exec-obsolete.h' Avi Kivity
2012-10-04 13:58   ` Anthony Liguori
2012-10-03 16:03 ` [Qemu-devel] [RFC v1 02/22] vhost: use MemoryListener filtering to only monitor RAM address space Avi Kivity
2012-10-03 16:03 ` [Qemu-devel] [RFC v1 03/22] kvm: use separate MemoryListeners for memory and I/O Avi Kivity
2012-10-03 20:16   ` Blue Swirl
2012-10-04  6:33     ` Avi Kivity
2012-10-04 16:44       ` Blue Swirl
2012-10-04 16:58         ` Avi Kivity
2012-10-03 16:03 ` [Qemu-devel] [RFC v1 04/22] xen_pt: " Avi Kivity
2012-10-03 16:03 ` [Qemu-devel] [RFC v1 05/22] memory: prepare AddressSpace for exporting Avi Kivity
2012-10-04 14:01   ` Anthony Liguori
2012-10-03 16:03 ` [Qemu-devel] [RFC v1 06/22] memory: export AddressSpace Avi Kivity
2012-10-04 14:02   ` Anthony Liguori
2012-10-03 16:03 ` [Qemu-devel] [RFC v1 07/22] memory: maintain a list of address spaces Avi Kivity
2012-10-04 10:17   ` Gleb Natapov
2012-10-04 10:19     ` Avi Kivity
2012-10-04 14:03   ` Anthony Liguori
2012-10-03 16:03 ` [Qemu-devel] [RFC v1 08/22] memory: provide defaults for MemoryListener operations Avi Kivity
2012-10-04 14:05   ` Anthony Liguori
2012-10-04 14:29     ` Avi Kivity
2012-10-09 15:14       ` Anthony Liguori
2012-10-09 15:28         ` Avi Kivity
2012-10-09 18:34           ` Anthony Liguori
2012-10-03 16:03 ` [Qemu-devel] [RFC v1 09/22] memory: use new MEMORY_LISTENER_DEFAULT_OPS Avi Kivity
2012-10-03 16:03 ` [Qemu-devel] [RFC v1 10/22] vfio: " Avi Kivity
2012-10-04 15:45   ` Alex Williamson
2012-10-03 16:03 ` [Qemu-devel] [RFC v1 11/22] xen_pt: " Avi Kivity
2012-10-03 16:03 ` [Qemu-devel] [RFC v1 12/22] kvm: " Avi Kivity
2012-10-03 16:03 ` [Qemu-devel] [RFC v1 13/22] xen: " Avi Kivity
2012-10-03 16:03 ` [Qemu-devel] [RFC v1 14/22] memory: manage coalesced mmio via a MemoryListener Avi Kivity
2012-10-04 14:08   ` Anthony Liguori
2012-10-04 14:33     ` Avi Kivity
2012-10-03 16:03 ` [Qemu-devel] [RFC v1 15/22] memory: move address_space_memory and address_space_io out of memory core Avi Kivity
2012-10-04 14:08   ` Anthony Liguori
2012-10-03 16:03 ` [Qemu-devel] [RFC v1 16/22] memory: move tcg flush into a tcg memory listener Avi Kivity
2012-10-03 16:04 ` [Qemu-devel] [RFC v1 17/22] memory: use AddressSpace for MemoryListener filtering Avi Kivity
2012-10-03 20:16   ` Blue Swirl
2012-10-04 10:17     ` Avi Kivity
2012-10-04 16:57       ` Blue Swirl
2012-10-04 14:09   ` Anthony Liguori
2012-10-03 16:04 ` [Qemu-devel] [RFC v1 18/22] s390: avoid reaching into memory core internals Avi Kivity
2012-10-04  8:12   ` Christian Borntraeger
2012-10-03 16:04 ` [Qemu-devel] [RFC v1 19/22] memory: per-AddressSpace dispatch Avi Kivity
2012-10-03 20:24   ` Blue Swirl
2012-10-04  6:38     ` Avi Kivity
2012-10-04  8:47       ` Peter Maydell
2012-10-04 10:15         ` Avi Kivity
2012-10-04 10:29           ` Peter Maydell
2012-10-04 10:30             ` Avi Kivity
2012-10-04 17:13       ` Blue Swirl
2012-10-04 17:19         ` Avi Kivity
2012-10-04 17:42           ` Blue Swirl
2012-10-04 19:05             ` Anthony Liguori
2012-10-04 19:15               ` Blue Swirl
2012-10-04 19:16               ` Peter Maydell
2012-10-07 10:34                 ` Avi Kivity [this message]
2012-10-04 14:13   ` Anthony Liguori
2012-10-04 14:43     ` Avi Kivity
2012-10-09 15:17       ` Anthony Liguori
2012-10-03 16:04 ` [Qemu-devel] [RFC v1 20/22] dma: make dma access its own address space Avi Kivity
2012-10-04 14:15   ` Anthony Liguori
2012-10-03 16:04 ` [Qemu-devel] [RFC v1 21/22] pci: give each device " Avi Kivity
2012-10-03 16:04 ` [Qemu-devel] [RFC v1 22/22] pci: honor PCI_COMMAND_MASTER Avi Kivity
2012-10-03 20:26 ` [Qemu-devel] [RFC v1 00/22] Integrate DMA into the memory API Blue Swirl
2012-10-04 10:18   ` Avi Kivity
2012-10-04  6:41 ` Avi Kivity
2012-10-04  8:13 ` Paolo Bonzini
2012-10-04 14:16   ` Anthony Liguori
2012-10-04 14:36     ` Avi Kivity

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=50715AD2.8010207@redhat.com \
    --to=avi@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=blauwirbel@gmail.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemulist@gmail.com \
    /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).