On 2002.06.06 01:48 Fernando Alegre wrote:
> 
> Hi,
> 
> We would like to use some kernel memory buffers from the camlimages libraries
> without copying the data to userland. The data comes from digital cameras
> directly (using DMA) to a kernel ringbuffer. Caml does not own that memory,
> but we want Caml to use it as just another Image.t chunk (with a wrapper,
> of course.)
> 
> Our question is: is there a safe way to do this? We don't want the garbage
> collector to mess with the kernel memory, but we don't want to have
> to code separately for "userland" and "kernel" images...
> 
> Any suggestion will be appreciated.

One important information is missing: which operating system?

For example, Linux (but other OS, too) allow userland processes to access the
kernel memory by opening and mmapping the file /dev/kmem. This effects that
kernel memory is mapped into the userland address space. However, mmap is
usually restricted to 4k blocks, i.e. you can mmap only a whole number of
4k blocks.

O'Caml can handle pointers to blocks that are outside of the region that is
managed by its own routines. The blocks must have the right format, of course,
i.e. strings must have the right O'Caml header. I suppose this header is not
in the ringbuffer.

If the ringbuffer happens to begin at a 4k boundary, you have won, because you
can manage that there is such a header without modifying kernel memory, i.e.
if the mmaped buffer begins at address A, just allocate anonymous memory in the
4k block before A and write the needed header into it.

In all other cases, you must modify kernel memory to ensure that there is
a header. I don't know whether this is possible.

The other problem is whether camlimages can handle data that is organized as ring.
I don't have any ideas.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners