All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guillermo Marcus Martinez <marcus@ti.uni-mannheim.de>
To: linux-kernel@vger.kernel.org
Subject: Re: mmaping a kernel buffer to user space
Date: Wed, 01 Nov 2006 13:58:17 +0100	[thread overview]
Message-ID: <454899E9.1090900@ti.uni-mannheim.de> (raw)
In-Reply-To: <loom.20061101T120846-320@post.gmane.org>

Rolf Offermanns schrieb:
> Guillermo Marcus <marcus <at> ti.uni-mannheim.de> writes:
>> Note: I am using kernel 2.6.9 for these tests, as it is required by my
>> current setup. Maybe this issue has already been addressed in newer
>> kernel. If that is the case, please let me know.
> 
> Have a look at this article:
> 
> "The evolution of driver page remapping"
> http://lwn.net/Articles/162860/
> 
> It should make things clearer. 
> 
> The "API changes in the 2.6 kernel series" page is also a very good read:
> http://lwn.net/Articles/2.6-kernel-api/
> 
> HTH,
> Rolf

Thanks for the links!

Yes, it looks like a step in the right direction. However, the article
says about vm_insert_page(): "...What it does require is that the page
be an order-zero allocation obtained for this purpose...", therefore
making it also unusable for this case (mmaping a pci_alloc_consistent).

I think the limitation (being order zero), is related to the page
counting, as I understand that for bigger order allocations, only the
first-page counter is incremented (not every page). If that is a
problem, I guess I would also see a problem with my workaround, and I
see none (yet). So I may try in a newer kernel and see if I can use it
to walk the pages on the mmap without using the nopage().

My suggestion would be to add two functions: pci_map_consistent() and
dma_map_coherent() to address this issue, and their corresponding
unmap's. That will make sure all that is needed is done, is a clean and
consistent with the pci_ and dma_ APIs, and fills a mmap requirement not
covered by the other functions.

Best wishes,
Guillermo


  reply	other threads:[~2006-11-01 12:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-31  9:19 mmaping a kernel buffer to user space Guillermo Marcus
2006-10-31 16:00 ` Jiri Slaby
2006-10-31 16:25   ` Guillermo Marcus
2006-10-31 16:49     ` Jiri Slaby
2006-10-31 17:08       ` Franck Bui-Huu
2006-10-31 19:44       ` Miguel Ojeda
2006-10-31 19:22   ` Russell King
2006-10-31 19:36     ` Jiri Slaby
2006-10-31 16:10 ` Rolf Offermanns
2006-10-31 16:33   ` Guillermo Marcus
2006-11-01 11:11 ` Rolf Offermanns
2006-11-01 12:58   ` Guillermo Marcus Martinez [this message]
2006-11-01 14:00     ` yogeshwar sonawane
2006-11-01 15:06       ` Guillermo Marcus Martinez
2006-11-02  8:31     ` Russell King
2006-11-02 11:31       ` Guillermo Marcus

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=454899E9.1090900@ti.uni-mannheim.de \
    --to=marcus@ti.uni-mannheim.de \
    --cc=linux-kernel@vger.kernel.org \
    /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.