[Caml-list] enumerations & ioctls

[Caml-list] enumerations & ioctls

[Jonathan Roewen]

Hi,

I'm about to endeavour into designing a driver interface for my OS
project, and I have some questions about making a type-safe ioctl-like
function.

Since different device types have different sets of ioctl calls it can
accept, I need to be able to have a structure that I can put different
devices into, implying the enumerations aren't identical.

Is the best way to achieve this with those polymorphic variants? And
how much does this affect type safety?

Jon

Re: [Caml-list] enumerations & ioctls

[Richard Jones]

On Thu, Jun 30, 2005 at 11:14:07PM +1200, Jonathan Roewen wrote:
> Is the best way to achieve this with those polymorphic variants? And
> how much does this affect type safety?

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?

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] enumerations & ioctls

[Jonathan Roewen]

> 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).

Jonathan