Very Computer

by **ada..** » Sun, 21 Apr 1996 04:00:00

If I want a big gob (up to a max. size of 256K, say) of physically
contiguous memory, it seems that I might use get_free_pages (of course
starting out with my req. size and degrading on failure). This gives
me a "physical" offset to the beginning of the area, right? The reason
I don't want to use kmalloc is that I'm not sure it isn't doing some sort
of mapping on top of the allocation (resulting in the possibility of
non-contiguous frames). I'm also unsure of whether or not the kernel's
memory space (it seems kmalloc returns a POINTER to kernel space) is identity
mapped (surely it isn't).
Assuming get_free_pages() returns a physical offset, how then might
the kernel access it (the frames' data)? I thought vremap() might, but it
seems to ignore frames below the end of physical mem. Obviously kmalloc
takes care of that somehow. vmalloc seems even scarier, and I know
for sure (waiting to stick foot in mouth) it creates a virtual mapping
from a set of discontiguous frames.

I realize that all of these questions could be answered upon close
study of the kmalloc/vmalloc, et cetera, sources, but I am officially
not 100% up to speed on Linux's memory system, and the code hurts my
head! ;)

I guess if you got this far you may be able to answer this:
I have driver source (working) and a few (very minor,ksym,etc.) kernel
source changes that I would like to propose. Is there protocol/FAQ
somewhere for this? In particular I can keep up with the current
kernel rev as a moduled driver. Thanks millions for your attention.

Ken Adams
[feverishly, possibly even frantically, pulling his hair out, and loving it]

by **Andreas Schw** » Tue, 23 Apr 1996 04:00:00

|> If I want a big gob (up to a max. size of 256K, say) of physically
|> contiguous memory, it seems that I might use get_free_pages (of course
|> starting out with my req. size and degrading on failure). This gives
|> me a "physical" offset to the beginning of the area, right? The reason
|> I don't want to use kmalloc is that I'm not sure it isn't doing some sort
|> of mapping on top of the allocation (resulting in the possibility of
|> non-contiguous frames).

kmalloc does not remap the memory it returns, rather it's just a
wrapper around get_free_pages, but can also handle small requests.
You're probably confusing it with vmalloc which *does* remap the
memory region and can return physically non-contiguous memory.

|> I'm also unsure of whether or not the kernel's
|> memory space (it seems kmalloc returns a POINTER to kernel space) is identity
|> mapped (surely it isn't).

On the x86 all physcal memory is identity mapped in the kernel address
space.

|> Assuming get_free_pages() returns a physical offset, how then might
|> the kernel access it (the frames' data)?

Just derefence the pointer, no magic required.
--
Andreas Schwab "And now for something

Very Computer

physically cont. mem. alloc/mapping

physically cont. mem. alloc/mapping

physically cont. mem. alloc/mapping