English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] enumerations & ioctls
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-07-01 (03:18)
From: Jonathan Roewen <jonathan.roewen@g...>
Subject: Re: [Caml-list] enumerations & ioctls
> 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 = {
  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).