Rob Thorpe (robert.thorpe@antenova.com) on 5/16/06 wrote:
---------------------------
>You could do something like this:
>
>* Have a kernel containing the most essential things, scheduler, start-up etc.
>* Have a small compiler hooked to the kernel capable of compiling from some simple
>intermediate language into machine code. (Maybe it need not be in the kernel)
>* Have less core things, like device drivers, and file systems held in intermediate code.
>
>When a sub-system is needed it is compiled. To compile it there is a function something like
>
>compiler (code_block, allowable_mem_accesses, allowable_io, etc);
>
>I.e. the compiler takes as argument what memory and IO the code is permitted to
>access. It then compiles the code with those limits. Anything it statically verifies
>are inside the limits is compiled directly, for anything it can't it inserts checks.
>
>The compilation could be done for device drivers etc when their memory spaces are
>known. Which may be boot time or build time or some other time later.
>
>
>This seems a complex way to go about the problem, the compiler would have to be
>good. But there again most kernels are fairly complex anyway.


I can see it now... Device drivers written in Java... ;-)

But seriously, that seems like overkill. Any trustworthy compiler for a type-safe language will do the trick. They just have to accept (well typed) pointers to the objects they reference. And I/O ports are mostly ignorable - since essentially nothing that's performance critical uses them, you can provide access though an (checked) API (at least on platforms that actually support I/O port instructions - implementations that fake PCI ports with memory mappings are obviously in the original scenario).