Lennart Augustsson wrote:
I told you where to look at code. It's C code, mind you, but written in a decent way. No well written device driver ever accesses memory or IO ports directly, doing so would seriously hamper portability.
Well something must be accessing both. Dunno what you mean by "directly" I take it you must mean that the driver does not make use of global variables or "baked in" port addresses in it's source code.
Instead you use an abstraction layer to access to hardware, and the driver gets passed a "bus" (whatever that might be) access token (akin to a capability). I know you're not going to be convinced, so I won't even try. :)
I have actually spent the last 20 years or so writing both non-hosted and hosted device drivers for a few OS's. I'm perfectly convinced about the truth of what you say, but not at all convinced about the relevance. It's a red herring IMO as you've introduced a very complex and mysterious black box that itself cannot be implemented without making use of "global variables". You can find them easily enough in the Linux kernel source. I'm sure they'll be there in NetBSD too (never looked though). Regards -- Adrian Hey _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe