From: Avi Kivity <avi@qumranet.com>
To: Glauber Costa <gcosta@redhat.com>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
glommer@gmail.com, mingo@elte.hu, tglx@linutronix.de,
kvm-devel@lists.sourceforge.net, amit.shah@qumranet.com
Subject: Re: [PATCH 0/20] dma_ops for i386
Date: Wed, 26 Mar 2008 12:01:29 +0200 [thread overview]
Message-ID: <47EA1EF9.9080602@qumranet.com> (raw)
In-Reply-To: <1206480999-21767-1-git-send-email-gcosta@redhat.com>
Glauber Costa wrote:
> Hello,
>
> Here there is a series of 20 patches that lays the foundations for
> using dma_ops in i386 in the very same way x86_64, as well as many other
> architectures already do.
>
> The functions themselves for i386 are placed in a pci-base_32.c, but just
> a few among them are actually implemented. Most were no-ops anyway.
>
>
I see the headers are unified, but the .c files are duplicated. I
presume unifying the implementation is deferred to later patches?
> The motivation for that is the ongoing work for pci-passthrough in KVM.
> So ingo, avi, what do you think it's the best way to handle these patches through?
>
x86.git.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi@qumranet.com>
To: Glauber Costa <gcosta@redhat.com>
Cc: kvm-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org
Subject: Re: [PATCH 0/20] dma_ops for i386
Date: Wed, 26 Mar 2008 12:01:29 +0200 [thread overview]
Message-ID: <47EA1EF9.9080602@qumranet.com> (raw)
In-Reply-To: <1206480999-21767-1-git-send-email-gcosta@redhat.com>
Glauber Costa wrote:
> Hello,
>
> Here there is a series of 20 patches that lays the foundations for
> using dma_ops in i386 in the very same way x86_64, as well as many other
> architectures already do.
>
> The functions themselves for i386 are placed in a pci-base_32.c, but just
> a few among them are actually implemented. Most were no-ops anyway.
>
>
I see the headers are unified, but the .c files are duplicated. I
presume unifying the implementation is deferred to later patches?
> The motivation for that is the ongoing work for pci-passthrough in KVM.
> So ingo, avi, what do you think it's the best way to handle these patches through?
>
x86.git.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
next prev parent reply other threads:[~2008-03-26 10:05 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-25 21:36 [PATCH 0/20] dma_ops for i386 Glauber Costa
2008-03-25 21:36 ` Glauber Costa
2008-03-25 21:36 ` [PATCH 01/20] x86: move dma_ops struct definition to dma-mapping.h Glauber Costa
2008-03-25 21:36 ` Glauber Costa
2008-03-25 21:36 ` [PATCH 02/20] x86: implement dma_map_single through dma_ops Glauber Costa
2008-03-25 21:36 ` Glauber Costa
2008-03-25 21:36 ` [PATCH 03/20] x86: move dma_unmap_single to common header Glauber Costa
2008-03-25 21:36 ` Glauber Costa
2008-03-25 21:36 ` [PATCH 04/20] x86: move dma_map_sg " Glauber Costa
2008-03-25 21:36 ` Glauber Costa
2008-03-25 21:36 ` [PATCH 05/20] x86: move dma_unmap_sg " Glauber Costa
2008-03-25 21:36 ` Glauber Costa
2008-03-25 21:36 ` [PATCH 06/20] x86: move dma_sync_single_for_cpu " Glauber Costa
2008-03-25 21:36 ` Glauber Costa
2008-03-25 21:36 ` [PATCH 07/20] x86: move dma_sync_single_for_device " Glauber Costa
2008-03-25 21:36 ` Glauber Costa
2008-03-25 21:36 ` [PATCH 08/20] x86: move dma_sync_single_range_for_cpu " Glauber Costa
2008-03-25 21:36 ` Glauber Costa
2008-03-25 21:36 ` [PATCH 09/20] x86: move dma_sync_single_range_for_device " Glauber Costa
2008-03-25 21:36 ` Glauber Costa
2008-03-25 21:36 ` [PATCH 10/20] x86: move dma_sync_sg_for_cpu " Glauber Costa
2008-03-25 21:36 ` Glauber Costa
2008-03-25 21:36 ` [PATCH 11/20] x86: move dma_sync_sg_for_device " Glauber Costa
2008-03-25 21:36 ` Glauber Costa
2008-03-25 21:36 ` [PATCH 12/20] x86: move alloc and free coherent " Glauber Costa
2008-03-25 21:36 ` Glauber Costa
2008-03-25 21:36 ` [PATCH 13/20] x86: move dma_map_page and dma_unmap_page " Glauber Costa
2008-03-25 21:36 ` Glauber Costa
2008-03-25 21:36 ` [PATCH 14/20] x86: move dma_cache_sync " Glauber Costa
2008-03-25 21:36 ` Glauber Costa
2008-03-25 21:36 ` [PATCH 15/20] x86: move dma_supported and dma_set_mask to pci-dma_32.c Glauber Costa
2008-03-25 21:36 ` Glauber Costa
2008-03-25 21:36 ` [PATCH 16/20] x86: align to clflush size Glauber Costa
2008-03-25 21:36 ` Glauber Costa
2008-03-25 21:36 ` [PATCH 17/20] x86: provide a bad_dma_address symbol for i386 Glauber Costa
2008-03-25 21:36 ` Glauber Costa
2008-03-25 21:36 ` [PATCH 18/20] x86: unify dma_mapping_error Glauber Costa
2008-03-25 21:36 ` Glauber Costa
2008-03-25 21:36 ` [PATCH 19/20] x86: move ARCH_HAS_DMA_DECLARE_COHERENT_MEMORY to dma-mapping.h Glauber Costa
2008-03-25 21:36 ` Glauber Costa
2008-03-25 21:36 ` [PATCH 20/20] x86: delete the arch-specific dma-mapping headers Glauber Costa
2008-03-25 21:36 ` Glauber Costa
2008-03-26 7:09 ` [PATCH 16/20] x86: align to clflush size Ingo Molnar
2008-03-26 7:09 ` Ingo Molnar
2008-03-27 11:03 ` [PATCH 15/20] x86: move dma_supported and dma_set_mask to pci-dma_32.c Mark McLoughlin
2008-03-27 11:03 ` Mark McLoughlin
2008-03-27 11:54 ` Ingo Molnar
2008-03-27 11:54 ` Ingo Molnar
2008-03-26 7:06 ` [PATCH 0/20] dma_ops for i386 Ingo Molnar
2008-03-26 7:06 ` Ingo Molnar
2008-03-26 12:49 ` Ingo Molnar
2008-03-26 12:49 ` Ingo Molnar
2008-03-26 13:04 ` Ingo Molnar
2008-03-26 13:16 ` Glauber Costa
2008-03-26 13:16 ` Glauber Costa
2008-03-26 10:01 ` Avi Kivity [this message]
2008-03-26 10:01 ` Avi Kivity
2008-03-26 12:03 ` Glauber Costa
2008-03-26 12:03 ` Glauber Costa
2008-03-27 9:49 ` Amit Shah
2008-03-27 9:49 ` Amit Shah
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=47EA1EF9.9080602@qumranet.com \
--to=avi@qumranet.com \
--cc=akpm@linux-foundation.org \
--cc=amit.shah@qumranet.com \
--cc=gcosta@redhat.com \
--cc=glommer@gmail.com \
--cc=kvm-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.