From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA09139; Wed, 12 Jun 2002 18:20:47 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA09116 for ; Wed, 12 Jun 2002 18:20:46 +0200 (MET DST) Received: from madiran.inria.fr (madiran.inria.fr [128.93.8.77]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g5CGKbb11442; Wed, 12 Jun 2002 18:20:37 +0200 (MET DST) Received: from localhost (madiran.inria.fr [128.93.8.77]) by madiran.inria.fr (Postfix) with ESMTP id 92C6DA772F; Wed, 12 Jun 2002 18:20:37 +0200 (CEST) Date: Wed, 12 Jun 2002 18:20:37 +0200 (CEST) Message-Id: <20020612.182037.700403668.Jun.Furuse@inria.fr> To: xavier.leroy@inria.fr Cc: info@gerd-stolpmann.de, fernando@cc.gatech.edu, caml-list@inria.fr Subject: Re: [Caml-list] camlimages and kernel memory From: "Jun P.FURUSE" In-Reply-To: <20020608153614.A12902@pauillac.inria.fr> References: <20020605234852.GA4103@oso.local> <20020606230826.C616@ice.gerd-stolpmann.de> <20020608153614.A12902@pauillac.inria.fr> X-URL: http://pauillac.inria.fr/~furuse/ X-Face: %NBEt80q,?D$3WNc|UEDB(`B%4yRMn~m!-wQF`!QA@=cZ~?MZJwomF~)69N/W6e/n1),d X-Mailer: Mew version 2.2 on XEmacs 21.4.6 (Common Lisp) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Hello, > This is the hard way :-) A simpler way to memory map files or devices > in a Caml program is to use the function "map_file" from the Bigarray > library. However, it currently always map the file from offset 0, > which is probably not appropriate for /dev/kmem... I'll have to look > into this limitation. > > > The other problem is whether camlimages can handle data that is > > organized as ring. I don't have any ideas. > > The type Image.t is a relatively complex data structure, so some work > is definitely needed to go from a raw string or bigarray > (corresponding to the memory-mapped file) to a value of type Image.t. > I'll let the authors of CamlImages comment on that. If the kernel memory contains the same data structure as one of the camlimages internal image formats, the solution may be... Somehow (= I do not know) get the kernel memory as a raw string, then create an image using ???.create_with function. The kernel memory may use different pixel layout, I am afraid. In such case, you have to write your own version of module like Rgb24, Index8 and so on. I am sorry but they are not well documented... BTW, once I tried to implement Image.t using Bigarray, but it was too slow. It seemed to me that it performed the array boundary checks for each access. For image manipulation purposes, the unsafe versions of set and get are really required. -- jun ------------------- 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