linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Hans J. Koch" <hjk@linutronix.de>
To: Earl Chew <earl_chew@agilent.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org, hjk@linutronix.de, 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: Mon, 14 Dec 2009 20:23:23 +0100	[thread overview]
Message-ID: <20091214192322.GA3245@bluebox.local> (raw)
In-Reply-To: <4B22DD89.2020901@agilent.com>

On Fri, Dec 11, 2009 at 04:02:17PM -0800, Earl Chew wrote:
> I'm taking another look at the changes that were submitted in
> 
> http://lkml.org/lkml/2008/12/3/453
> 
> to see if they can be made more palatable.
> 
> 
> In http://lkml.org/lkml/2008/12/4/64 you wrote:
> 
> > Why not create another special device that will give you DMA memory when
> > you mmap it? That would also allow you to obtain the physical address
> > without this utter horrid hack of writing it in the mmap'ed memory.
> > 
> > /dev/uioN-dma would seem like a fine name for that.
> 
> 
> I understand the main objection was the hack to return the physical
> address of the allocated DMA buffer within the buffer itself amongst
> some other things.

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.

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.

> 
> Your suggestion was to create /dev/uioN-dma for the purpose of
> allocating DMA memory.
> 
> I'm having trouble figuring out how this would help to return the
> physical (bus) address of the DMA memory in a more elegant manner.

If you create this new device, you can invent any (reasonable) interface you
like. It should probably be something in sysfs, where you can write to a
file to allocate a new buffer, and read the address from some other.
It should also be possible to free a buffer again.

Thanks,
Hans

--
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>

  reply	other threads:[~2009-12-14 19:23 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 [this message]
2009-12-15 13:34       ` Earl Chew
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=20091214192322.GA3245@bluebox.local \
    --to=hjk@linutronix.de \
    --cc=earl_chew@agilent.com \
    --cc=gregkh@suse.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