Declarative Device Driver

For over a year now, I've had rattling around in my head the idea that DeclarativeProgramming - in particular, ConstraintLogicProgramming or a strict form of GoalBasedProgramming, would make for some very interesting implementation of DeviceDrivers for computer OperatingSystems and bare-metal programming. This idea turns on its head the accepted 'fact' that low-level driver code ought to be written in low-level programming language.

A DeclarativeDeviceDriver is an instance of DeclarativeMetaprogramming.

The basic approach, given ConstraintLogicProgramming as the basis (since its use has been proven) is to: Mechanism: Using ConstraintLogicProgramming, the basic 'mechanism' is to attempt to unify these databases (mostly the latter two - mechanism and policy - but the second has references to the first) and produce a value that describes resource allocations, procedures for achieving these, procedures that implement the required interfaces, and so on. This will probably take a very long time to do, unfortunately, so a lesser form is to do it on a per-hardware-component rather than on the 'whole' system, and also to improve strategies and heuristics for getting stuff into a 'good enough' state fast (before optimization). Oh, and plus the general idea of an AssociativeMemory helper-agent that can at least reduce the cost of a edit-compile-test cycle by remembering critical branches when it came to previous proofs.

If one opted for the non-modular approach, the consequence is one gigantic value describing the system and its internal state and its interactions.

After building the initial kernel, parts of the kernel and hardware specifications continue to be used by the compiler and optimizer for UserSpace services. This allows the optimizer to (depending on modularity policy) possibly penetrate abstraction layers for extra optimizations, to eliminate security checks where capability can be proven, et cetera. Also, the same database about the processor is required for optimizations anyway.

Declarative programming would offer some very nice properties in this field: The disadvantage is also obvious: DeclarativeProgramming can be fast, but needs to be properly designed to take advantage of strategies and heuristics, and even then it is likely to waste a lot of time thinking about bad solutions... solutions we would know are bad based on our own AssociativeMemory (aka 'experience'). Thinking about bad solutions takes a while. Without a highly developed AssociativeMemory helper-agent that can provide 'learned' heuristics and strategies to the prover across edit-compile-test cycles, it is unlikely that the time required for this operation would ever reduce to a small enough period that tinkerers would join the crowd (running it on their home machines).

As a note, I have listed in my Nov/Dec 2006 composition books that I'm planning to attempt this path when building 'EiraOs?' - it's been a while, and I expect another five years before I'm even ready to really think about Eira seriously, but I suppose that if I'm going to have a VaporWare OperatingSystem I might as well have one with ALL the nice features and cool ideas (like the built-in WikiIde as the primary ObjectSystem ;-). Of course, I don't see much purpose in attempting to clone Linux's efforts, either - if I'm going to go for something new, I want something really new rather than another 'improved' clone of a bad OS.

See Also: DeviceDriver, ConstraintLogicProgramming, DeclarativeMetaprogramming

View edit of April 29, 2014 or FindPage with title or text search