Top Level TWI's again was Re: [Haskell] Re: Parameterized Show

[Adrian Hey]

On Wednesday 24 Nov 2004 11:50 am, Keean Schupke wrote:
> There is no problem getting multiple copies of the channels... I take it
> you are not familiar with the internals of OSs

IME there is no uniformity wrt OS internals, and I can't claim to be
familiar with them all. It's also fairly safe to assume that I know
nothing about the internals of your OS.

In any case, this is irrelevant to the scenario I originally posited.
Remember I wrote:
> What if there is no OS or device driver?
-------------------^^^^^

I.E. A typicial embedded environment (though it's common to use OSs
here too, but the main reason for that is inadequacy of C). So all
you have to work with is one complete, type safe, Haskell program,
and "the metal". In this scenario the only initialisation that's
done prior to running main is initialisation of the Haskell rts.

That said, the approach you outline below is workable and AFAICS
immune to the problems I was talking about. But you've introduced
an artificial distinction between OS and application to do this
and as a result..

* Made comms between application and hardware really awkward IMO
* Sacrificed type safety in these comms I think.

> (I have written a small
> OS myself, complete with real device drivers)... The OS is started at
> boot, it initialises its own state, then it forks the device drivers, then
> it forks user processes (simplified but adequate).
>
> Lets design a small Haskell OS, the OS has the handles for the device
> driver.
> The program MUST be passed the channels to the OS (there is no other
> way)... These channels allow other channels to be opened, they would be
> like the master device.
>
>     main :: Chan CMD -> Chan RSP -> IO ()
>     main cmd rsp = do
>        writeChan cmd (OpenDevice "devname")
>        h <- readChan rsp
>        case h of
>           (OpenOK in out) -> do
>                 writeCan out  (DeviceWriteString "hello")
>                 status <- readChan in
>           _ -> error "could not open device"
>
> Here you can see that we could try and open the device again, however the
> OS would either multiplex or serialize the device depending on type.

So you've gone for the third approach I identified, but with a slight
variation. You've wrapped all the separate device drivers into a single
uber device driver (world driver?) and called it the "operating system".
I think this approach has it's pros and cons, but you're right that it
does solve the problem. But my original monosyllabic summary of MHO re.
this approach still applies I'm afraid.

Regards
--
Adrian Hey