LLL: Fat PIOS

[Mike Prince]

On Thu, 3 Nov 1994, Raul Deluth Miller wrote:

> I can see a usefulness for including machine executable binaries with
> PIOS.  However, I can see the usefulness of insisting that such
> binaries must be accompanied by LLL code -- both for validation work,
> and for portability.

I don't see how you could validate binary against it's LLL code, unless 
you could generate the binary from the LLL, thus negating the need for 
binary.  Please explain more about validating.

As I said before, we must allow binaries somewhere, lets just keep them 
very close to the kernel and away from everything else.  I see binaries;

On plug in cards in PC's.  Found early enough that the kernel can package 
them up and protect them.

On drivers for cards in PC's.  A necessary kludge for now, again loaded 
early by the kernel and then packaged up for safety.

On very specialized hardware.  A box that just provides one tool box 
(a rendering package for instance) that runs very fast.  The tool box 
would come as a fat binary to the kernel that spawned it, but look like a 
normal tool box to everyone else.

My holy war continues...  OK you got me to say FAT BINARIES.  But I would 
like it to be a PER kernel kludge, not a system wide one (or is there a 
difference). 

> Speaking of which, I can see allowing some kernels to support memory
> protection and some not.  Memory protection is just an efficient way
> of doing "array bounds checking".  If an agent is supposed to be
> migratable to another machine it sure shouldn't care about things that
> could be inaccessible.  The important thing is to nail down the
> semantics so that things can work properly.

Totally true.

Mike