Device drivers

[Fare Rideau]

>>>: Mike McDonald
>>: Fare Rideau
>: Ian Ross

NB: nobody pretends that device drivers in Lisp are a priority.

>>>   Eventually, I'd like to see everything except the device drivers be
>>> implemented in lisp. But that's a long, long term dream.
>> Why "except the device drivers"?
>>[C->Lisp translation; nicer semantics in Lisp]
>>[better debugging; better integration]
>
> Fare's right - there's no reason we can't translate device drivers
> into Lisp, and for developing new drivers, it would be very nice to be
> able to debug them in a Lisp environment where the machine doesn't go
> to pieces every time you do something wrong.
>
Before Linux, there were even people to pretend
that device drivers had to be written in ASM,
that C was a "High-Level Language" not suited to writing them!
[As an "excuse" for such people, we must admit that
cycles were more expensive and available compiler technology less efficient]

>[Oberon on PC w/o C]
Sure, good example. Oberon is not a much higher-level language than C, tho.

>[As the Utah OS toolkit, build layers to adapt foreign drivers to our OS]
>
Yeah, to me this means that we need a nice module/functor model,
like the SML/NJ stuff used in Fox.
   But the advantage of Lisp over ML is reflection.
So that starting from a straightforwardly C->Lisp'ed device driver version,
we could do static code transformations
instead of just doing stubborn slow run-time translation
that must deal with the conflicting assumptions made by various drivers.
   Through meta-programming,
we could achieve better performance and integration, and also
do such things as proving code correct or tracking bugs/deadlocks.
By making the translation and code transformations reversible,
we could even contribute corrected drivers back to the original OS,
and make drivers of some OSes automatically available to other OSes.
   When OS implementers see that, they'll rush to Lisp, and bye bye, C!

#f