lkml.org 
[lkml]   [2000]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectnopage() vs remap_page_range
Linus Torvalds wrote:
...snip...
>
> Anyway, I didn't realize you were talking about the sound drivers use of
> remap_page_range(). That's not the original reason for remap_page_range()
> at all, and in fact it's the _ugly_ way to do things. It's simple and it
> works, but it's not pretty.
>
> Quite frankly, the way I'd conceptually prefer people do these kinds of
> DMA buffers etc is to just have a "nopage()" function, and let that
> nopage() function just fill in the page from the DMA buffer directly. This
> would work fine, and would get rid of all the playing with PG_reserved
> etc.
>
> Obviously, such a page would never really get swapped out: you'd have a
> "swapout()" function that would be a no-op (as the page would not truly be
> swapped out: the page is actually held by the driver inside the kernel,
> and the user mapping is just a _window_ into that kernel buffer).
>
> Now, remap_page_range() ends up giving this same functionality without
> sound drivers needing to have nopage() or swapout() functions at all, and
> obviously it's trivial to do this way. But you should realize that this
> use of remap_page_range() is very much a hack - the whole point of
> remap_page_range() was always to do the PCI (and legacy ISA region)
> mapping for things like the X server etc that access hardware directly.
>
> I hated people mis-using it the way it's being done by the sound drivers,
> but because I also realize that it allows for some simplifications I do
> accept it - it's basically an ugly hack that doesn't really matter because
> the exact same code _is_ needed for the real IO mapping case anyway, and
> as far as the kernel is concerned the whole thing with PG_reserved is all
> just a game to make the kernel VM subsystem think that some real RAM is
> actually IO space and shouldn't be touched.

Slightly off topic (and a bit newbie too, but hey...). When I was
rewriting the bttv driver for v4l2, I used the v4l2 memory management,
which uses nopage() to increase page->count, and the return page (the
memory is vmalloc()ed. This worked, but there was occasional memory
corruption, as though the physical memory was being moved. Switching to
the old style bttv memory management (basically the same as the sound
drivers) fixed this problem. Is there any extra "catch" to using the
nopage method, or did I just make a stupid mistake somewhere. (If
anybody actually wants to look at the code, you can get it from
http://bttv-v4l2.sourceforge.net/download/driver091000.tgz - both
methods are there delimmited by #if(n)def BTTV_MM lines. When BTTV_MM
is defined, it works fine, otherwise I get occasional memory
corruption.)

If anybody could give a comment on why one works, and the other not, I
would appreciate it!

TIA

-justin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:41    [W:0.090 / U:0.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site