From: Earl Chew <earl_chew@agilent.com>
To: "Hans J. Koch" <hjk@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, gregkh@suse.de,
hugh <hugh@veritas.com>, linux-mm <linux-mm@kvack.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 1/1] Userspace I/O (UIO): Add support for userspace DMA
Date: Tue, 15 Dec 2009 05:34:19 -0800 [thread overview]
Message-ID: <4B27905B.4080006@agilent.com> (raw)
In-Reply-To: <20091214192322.GA3245@bluebox.local>
Hans,
Thanks for the considered reply.
Hans J. Koch wrote:
> The general thing is this: The UIO core supports only static mappings.
> The possible number of mappings is usually set at compile time or module
> load time and is currently limited to MAX_UIO_MAPS (== 5). This number
> is usually sufficient for devices like PCI cards, which have a limited
> number of mappings, too. All drivers currently in the kernel only need
> one or two.
I'd like to proceed by changing struct uio_mem [MAX_UIO_MAPS] to a
linked list.
The driver code in uio_find_mem_index(), uio_dev_add_attributes(), etc,
iterate through the (small) array anyway, and the list space and
performance overhead is not significant for the cases mentioned.
Such a change would make it easier to track dynamically allocated
regions as well as pre-allocated mapping regions in the same data
structure.
It also plays more nicely into the next part ...
> The current implementation of the UIO core is simply not made for
> dynamic allocation of an unlimited amount of new mappings at runtime. As
> we have seen in this patch, it needs raping of a documented kernel
> interface to userspace. This is not acceptable.
>
> So the easiest correct solution is to create a new device (e.g.
> /dev/uioN-dma, as Peter suggested). It should only be created for a UIO
> driver if it has a certain flag set, something like UIO_NEEDS_DYN_DMA_ALLOC.
An approach which would play better with our existing codebase would
be to introduce a two-step ioctl-mmap.
a. Use an ioctl() to allocate the DMA buffer. The ioctl returns two
things:
1. A mapping (page) number
2. A physical (bus) address
b. Use the existing mmap() interface to gain access to the
DMA buffer allocated in (a). Clients would invoke mmap()
and use the mapping (page) number returned in (a) to
obtain userspace access to the DMA buffer.
I think that the second step (b) would play nicely with the existing
mmap() interface exposed by the UIO driver.
Using an ioctl() provides a cleaner way to return the physical
(bus) address of the DMA buffer.
Existing client code that is not interested in DMA buffers do
not incur a penalty because it will not invoke the new ioctl().
Earl
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-12-15 13:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <43FC624C55D8C746A914570B66D642610367F29B@cos-us-mb03.cos.agilent.com>
2008-12-04 8:39 ` Peter Zijlstra
2008-12-04 10:27 ` Hugh Dickins
2008-12-23 21:32 ` Max Krasnyansky
2008-12-04 18:08 ` Hans J. Koch
2008-12-05 7:10 ` Peter Zijlstra
2008-12-05 9:44 ` Hans J. Koch
2008-12-06 0:32 ` Edward Estabrook
2008-12-12 17:25 ` Peter Zijlstra
2008-12-13 0:29 ` Hans J. Koch
2009-12-12 0:02 ` Earl Chew
2009-12-14 19:23 ` Hans J. Koch
2009-12-15 13:34 ` Earl Chew [this message]
2009-12-15 17:47 ` Earl Chew
2009-12-15 21:33 ` Hans J. Koch
2009-12-15 21:00 ` Hans J. Koch
2009-12-15 21:47 ` Earl Chew
2009-12-15 22:28 ` Hans J. Koch
2009-12-16 0:20 ` Earl Chew
2009-12-16 1:23 ` Hans J. Koch
2009-12-16 1:45 ` Earl Chew
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=4B27905B.4080006@agilent.com \
--to=earl_chew@agilent.com \
--cc=gregkh@suse.de \
--cc=hjk@linutronix.de \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterz@infradead.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox