[movitz-devel] Re: Drivers, standards and design

[Frode Vatvedt Fjeld]

M Bealby <mbealby at gmail.com> writes:

> Between attempting to code device drivers for movitz I have been
> thinking about how the drivers currently work.  Currently, the drivers
> are completely separate from one another.  However, I was wondering if
> anyone had thought about providing some higher level hardware
> information to any running applications.
> 
> By this I mean that during startup, movitz would probe for any
> hardware it understands and create information lists for each
> device.  I envision a list to be constructed of an identifier to
> explain what the device type is, followed by the parameters of that
> device.  One example (for a serial port) would be:
> 
> ([serial-port-key] [uart-address] [baud-rate])
> 
> Then, following this probe procedure, creating a list called
> something like hardware-info, which contains all of the lists for
> discovered hardware.

This is good and well, but I'd like to add one perspective to this
picture: Think of the list of device (-driver) descriptors as a
program, the probe procedure as an evaluator of that language, and the
list of detected hardware as the output of the program's
evaluation. Now, I suggest that plain Lisp (possibly augmentet by some
appropriate macros) would work very well in the role of this language
and evaluator. Or in other words, I suspect that the probing and
book-keeping of devices is one of the things that will turn out to be
entirely trivial in Movitz, even if it tends to be complicated in unix
and the like. At least so long as everything lives inside a single
address space and objects (i.e. driver instances) can be easily passed
around by reference. 

What I percieve to be more of a challenge, is shared resource
management in various forms. For example, how to express "call this
function in 10 milliseconds" (i.e. sharing the timer), etc.

> This would only require minor modifications to the current drivers
> (the add and remove hardware functions) while providing a framework
> to which new drivers could be built upon.

I'd like to note that the current "drivers" are mostly more or less
sketches, providing some bare essentials but usually nothing in the
way of resource management or anything else that requires some
overarching structure. Improvements and suggestions are welcome, of
course.

-- 
Frode Vatvedt Fjeld