Galchin Vasili wrote:

In any case, it seems like the GHC documentation allows "raw driver I/O"but when I look at the actual GHC 6.8.1 libraries I don't see low level driver functionailty.

On Unix, at least, you don't need anything special to write userspace device drivers. You normally open a special file in /dev, maybe memory map some of it into your address space, then use read, write, select, ioctl, and memory-mapped I/O. There isn't a direct Haskell interface to ioctl, but you can write an FFI wrapper for it and use hsc2hs to marshal Storable instances as necessary, based on their C definitions. Using the normal Unix read, write, and select functions is a bit tricky due to GHC's default of non-blocking I/O. Device drivers are often very tetchy about the exact mode in which they're accessed, and a driver written for blocking I/O can simply fall over if you try non-blocking access. The easiest thing to do is to rewrap them (and open, of course) using the FFI so that you can control the blocking behaviour. As for memory-mapped I/O for doing the likes of PIO or DMA, Data.ByteString has an mmap wrapper, but it's not currently built, and wouldn't be especially useful for the kind of super-low-level control you need if you're bit-banging a device directly. For that, you would do best to work in C, where it's more predictable what the compiler will and won't do with code around memory barriers and the like, and expose the code to Haskell in a controlled manner via the FFI.