Model

[Dwight Hughes]

| From: BRIAN SPILSBURY <zhivago@iglou.com>
| 
| LispOs: a Model
| 
| Base primitive is a 'byte-chunk'.

Works for me - I cannot really think of a simpler model. You might
want to also have 'aligned-byte-chunk' for accessing data that
is not actually structured as bytes and that needs to be accessed
efficiently.

| Byte-Chunk
|  begin - value at which the memory this chunk is responsible for starts.
|  end   - end of this chunk's memory.
| 
|  get-byte (index)       - sets a byte. relative to 'begin', limited by
'end'.
                            ^gets
|  set-byte (index value) - gets a byte. relative to 'begin', limited by
'end'.
                            ^sets
|  get-begin ()           - returns begin.
|  set-begin (value)      - sets the start.
|  set-end (index)        - sets the end.

how about:  
   set-chunk(value index) - sets start and end in one call
   get-position()         - gets present index into byte-chunk

|  merge-next ()          - arranges for this chunk to merge with the
following.
|  merge-prev ()          - arranges for this chunk to merge with the
previous.
| 
| At this point we have a memory system.
| Initially all of memory is covered by a single 'byte-chunk' with begin at
0
| end at 4 gig or whatever. This does not imply that the memory inside
exists.
| 
| We can allocate objects in by writing inside a byte-chunk. We can split
| byte chunks by allocating a byte-chunk inside a byte-chunk, and then
changing
| the begin or end positions so that the new byte-chunk is now outside the
| old.
| 
| Now we can implement other objects over this byte-layer interface.
| We can have 'free-memory' byte-chunks which are created when an object is
| gc'd, and when two free-memory chunks touch we can merge them together.
| 
| references to 'byte-chunks' should only be obtainable via a secure vendor
| as they will allow naughty things to happen, on the other hand we want
| access to the byte-layer to implement device drivers, etc.
| 
| 
| To implement the byte-chunk system you'll need to implement a
| callable-primitive, this doesn't need scope, etc, you can call it
directly
| via reference. If a typing convention is adopted then at this point
| we can also add type definitions, and we're well down the road to
reflection.
| 
| Note that using this system, we can at a later stage transparently adopt
a
| transparent POS system, such as disk-as-memory, ram-as-cache, or we can 
| do this initially.
| 
| -- now for a couple of whinges --
| 
| What is this scheme/CL debate? Neither langauge is appropriate as a core
| to an os. Write a micro-lisp with reflection and mop, and then if you
feel
| the need implement CL/CLOS/Scheme over the top, also add in security
| (preferable though something lispish like _capabilities_, rather than
| unix flavour silliness), and threads are a must.

I don't disagree - just not happy about the amount of work needed.

| 
| With the POS there is some amazing silliness.
| 
| a) Transparent POS _does not imply_ that your GC process will be
affected.
|    Transparent POS into an Object Store System Thingy might, and that
would
|    I agree be silly.
| 
|    For persistent objects all that it requires is that the system can
|    survive reboot without a loss of non-execution state. This can easily
|    be achieved by making the byte-layer of the memory system persistent,
|    and imho this is the logical, obvious solution.
| 
| b) If you do make the byte-layer persistent, this doesn't change a thing
|    as far as GC is concerned, if no-one's referencing an object it will
|    still go away.
| 
| c) You can implement an Object Store System Thingy under this system
|    as a database, although why you would want to except for putting
things
|    in a suitcase to take elsewhere I can't imagine.
| 
| d) To make the most of persistence, you might well want to make threads
|    persistent, which would be nice. If you don't have a persistent-byte
layer
|    to help here, good-luck. What this would mean is you could shut down
|    and restart and your programs won't notice, except that simultaneously
|    all their sockets to external machines may have closed, and the clock
|    might jump a couple of hours. This would be nice.
|

I have some concern over what happens if the power should go out
or the system should crash. How do we make this robust?
 
| --
| 
| Feel free to flame, anything will be better than the 'what name will we
call
| this os that we haven't even defined in any way more than an os that is
| lispy', or the 'I want Scheme! I want CL! I want GCC!' threads.
| 
| Lets at least get some models up of what's possible/desirable and have
them
| fight it out.
| 
| Brian Spilsbury
| 

-- Dwight