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 _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
