From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: linux-kernel@vger.kernel.org
Cc: Ralph Campbell <ralphc@pathscale.com>,
David Miller <davem@davemloft.net>,
muli@il.ibm.com, rdreier@cisco.com, openib-general@openib.org
Subject: Re: [openib-general] Suggestions for how to remove bus_to_virt()
Date: Sat, 15 Jul 2006 15:42:32 +0200 [thread overview]
Message-ID: <44B8F0C8.70103@s5r6.in-berlin.de> (raw)
In-Reply-To: <1152920719.4572.398.camel@brick.pathscale.com>
Ralph Campbell wrote:
> On Fri, 2006-07-14 at 15:35 -0700, David Miller wrote:
...
>> The dma_mapping_ops idea will never get accepted by folks like Linus,
>> for reasons I've outlined in previous emails in this thread. So, it's
>> best to look elsewhere for solutions to your problem, such as the
>> ideas used by the USB and IEE1394 device layers.
>
> The USB code won't work in my case because the USB system is
> the one doing the memory allocation and IOMMU setup so it
> can remember the kernel virtual address or physical pages used
> to create the mapping.
Side note: The same is true with the DMA stuff in the ieee1394
subsystem. And the SCSI subsystem doesn't allocate (all) buffers but
leaves DMA mapping and unmapping to the low-level drivers --- i.e. Ralph
can't rip bus_to_virt replacements from there either, because:
> In my case, the infiniband (SRP) code is doing the mapping and
> only passing the dma_addr_t to the device driver at which point
> I have no way to convert it back to a kernel virtual address.
> I need to either change the IB device API to include mapping functions
> or intercept the dma_* functions so I can save the inputs.
On the other hand, ieee1394/dma is the rather obvious example of a
generic layer which keeps book of virtual address and bus address of
mapped memory regions, for above or below layers to use as they need.
Ralph, do you think you can arrange your required API change as a pure
_extension_ of the IB API? I.e. add fields to data structs or add fields
to callback templates or add calls into the SRP layer... (I haven't
bothered to look at the API yet.)
--
Stefan Richter
-=====-=-==- -=== -====
http://arcgraph.de/sr/
next prev parent reply other threads:[~2006-07-15 13:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-12 23:29 Ralph Campbell
2006-07-12 23:40 ` David Miller
2006-07-13 0:11 ` Roland Dreier
2006-07-13 0:40 ` David Miller
2006-07-13 5:46 ` [openib-general] " Muli Ben-Yehuda
2006-07-14 22:27 ` Ralph Campbell
2006-07-14 22:35 ` David Miller
2006-07-14 23:45 ` Ralph Campbell
2006-07-15 13:42 ` Stefan Richter [this message]
2006-07-13 7:45 ` Stefan Richter
2006-07-13 16:02 ` Roland Dreier
2006-07-13 16:37 ` Ralph Campbell
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=44B8F0C8.70103@s5r6.in-berlin.de \
--to=stefanr@s5r6.in-berlin.de \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=muli@il.ibm.com \
--cc=openib-general@openib.org \
--cc=ralphc@pathscale.com \
--cc=rdreier@cisco.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
all inboxes | Powered by JetHome®