From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 3355DBCAE for ; Fri, 1 Jul 2005 05:18:29 +0200 (CEST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j613ISJD011242 for ; Fri, 1 Jul 2005 05:18:28 +0200 Received: by rproxy.gmail.com with SMTP id a36so212672rnf for ; Thu, 30 Jun 2005 20:18:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LEE3bVbH2b0fgEGCO6TlmWqZmtMVj8w7tUWqYXkoQkBEM1ORkdA014yHq7mcFvhZYAAiQB4mdOGa6PpxRwGo8JEbDlpA7yX61OUr8XJnPbQ9dbrFOLdkYYAtgt94VCZTgQ8gSeQ6BX3zBBU2BxNFM34ROYOsyS+aC1w4BABdd9U= Received: by 10.38.92.36 with SMTP id p36mr937537rnb; Thu, 30 Jun 2005 20:18:28 -0700 (PDT) Received: by 10.38.209.44 with HTTP; Thu, 30 Jun 2005 20:18:27 -0700 (PDT) Message-ID: Date: Fri, 1 Jul 2005 15:18:27 +1200 From: Jonathan Roewen Reply-To: Jonathan Roewen To: Richard Jones Subject: Re: [Caml-list] enumerations & ioctls Cc: caml-list@yquem.inria.fr In-Reply-To: <20050630130647.GA27372@furbychan.cocan.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050630130647.GA27372@furbychan.cocan.org> X-Miltered: at nez-perce with ID 42C4B604.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 binary:01 ioctl:01 variants:01 asmdynlink:01 bytecode:01 ocaml:01 variants:01 model:01 char:01 char:01 ioctl:01 polymorphic:01 interfaces:01 functions:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_BY_IP autolearn=disabled version=3.0.2 X-Spam-Level: > A bigger worry is how this is all going to get linked together. Do > you link your device drivers, OS and programs together into a static > binary? Does the ioctl call cross over a memory/program boundary? Do > you want to add variants later, after the programs have been compiled, > or when you load new device drivers? That's a good point. I was thinking of either using a) Asmdynlink module (not sure how it completely works yet), or b) hacking the bytecode interpreter into the kernel (or trying that old JIT code). There's no memory bounds (basically, everything shall run in the kernel address space). Things I know I need to consider is a) preventing loaded code from calling functions in certain kernel interfaces, and b) verifying that loaded code hasn't been modified in any way, and c) there are no calls to ocaml external functions. I think I would want to load variants with the device driver. The model I'd imagine is something like: type 'a character_device =3D { read:unit -> char; write: char -> unit; ioctl: 'a -> unit; controls: 'a; } The problem I have is I don't know how I could have different types for 'a, and stick them all into a data structure. This is why I thought polymorphic variants could fit the bill (though the documentation on them is a bit complex to understand). Jonathan