Re: buffer locking for DMA?

[Gus Koppel <gtk spamkiller bytechase cx>]

"Felix Kater" wrote:

> I use glib on windows to allocate memory for a camera. Its DLL then
> uses the memory and pass it to the kernel and fill it via DMA. I have
> to be sure that windows doesn't move my buffer(s) later since the
> kernel has built its allocation table using it.
>
> With windows there are functions to prevent that (VirtualAlloc with
> parameters for reserving and locking/unlocking), is there anything in
> glib?

It's unclear to me whether your program is supposed to be some sort of
hardware driver or an end user application. The terms "kernel" and "DMA"
in this context only make sense when referring to a (hardware) driver.
Hardware drivers are not supposed to deal with GTK+ / Glib at all.

On the other hand, if you're writing a GTK+ application to receive data
from a camera via an already existing driver then your application
should not need to care about memory locations and DMA at all. Your
application would rather receive prefilled buffers from the driver or
offer preallocated buffers to be filled by the driver. Whether, how and
where DMA is involved would be the sole business of the driver. Your
application would just receive results, without any need to worry about
special buffer treatment or precautions.

Also, you possibly have misunderstood the way VirtualAlloc() on Windows
works. It's not meant to allocate and lock memory at given *physical*
addresses, but at given *logical* addresses. Logical addresses are
process-specific, i.e. every process may have its own address 0x10000
with entirely different content. However, DMA works on physical memory
ranges only. In both Windows and Unix, applications can't allocate
buffers at particular physical addresses (or insist that a mapping
between logical and physical memory ranges stays unchanged). Only
drivers can.

This is even true if you use the AWE's MEM_physical flag of
VirtualAlloc(). It doesn't mean that you can allocate memory at a
particular physical memory address.

To answer your question: no, there isn't something like VirtualAlloc()
in Glib. However, in libc of Unices there is the mmap() function, which
is about the exact counterpart of standard VirtualAlloc(). However, some
Unices lack full implementation of all mmap() features so it may be a
bit precarious to use.

But again: for an application you don't have to care about DMA and
buffer locks. For a hardware driver you use neither Glib nor libc at all.