"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. _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
