Kernel 0.1 by win. djg5

[David Garfield]

"> " is from Michael David WINIKOFF

> Idea 1
> ~~~~~~
> We base the kernel on persistent processes.
>
> [Terminology: In a moment I'll modify this to persistent objects and explain
> the differences. By persistent I mean that it can be swapped out to storage,
> the machine turned off and on and then continued. In practice we would like
> to be able to have a large number of suspended processes on disk]

I would like to disagree at this stage.  Objects are not processes.
Object classes are processes.  I hate to say it, but I do think the
difference should exist.  This has the distinct advantage that you
don't have to store the code with the data, only a reference to it.
Ideally, for most classes, I would rather see one instance of the code
in virtual memory as well.

> This subsumes directories and files -- a directory is just a process that
> accepts queries and returns some identifier for the processes representing files

Change process to object due to the above objection and I agree
completely.

> Consider now the form of such a server (which incidently bears a striking
> resemblence to the nameservers (or dictionaries)):

Actually, I would argue that ALL objects should should be
nameservers/dictionaries/directories.  Some are just empty.


..

> Definition 1
> ~~~~~~~~~~~~
> An object is a process with method declerations.
An object is an area of data with a reference to a process or, in the
case of a suspended object, to a program.

> Definition 2
> ~~~~~~~~~~~~~
> A Device or "LOw Level Object" (lolo) is an object which
> either i
> (1) has been granted the privilege of being able to refer to certain hardware
> resources. (Eg. disk control registers, ethernet card)
> AND/OR
> (2) Has methods which are invoked upon the reciept of a particular interrupt.
> (Eg. data ready)
>
> [Note: Most lolo's will have (1) -- I think that few will have ONLY (2)]

Excellent definition.

> Definition 3
> ~~~~~~~~~~~~~
> An OID (Object IDentifier) is an atomic data item that is valid across processes
>
> (Note: In a distributed system it would be valid across machines too) and
> can be used to address an object.

I would have to counter that 1) an OID is only valid for non-suspended
objects and 2) In a network environment, aliases will exist for
objects on remote machines.  Any given OID is only valid on one
machine.

> Definition 4
> ~~~~~~~~~~~~~
> A Dictionary (Or Name Server) is an object which supports certain lookup
> operations and returns an OID.

As stated above, I argue that ALL objects are dictionaries/name
servers/directories.

> [Note: We see the concept of object classes by the type of the supported methods
> falling out. Whether  this should be enforced by the kernel or elsewhere
> or not at all is open to debate]

Actually, I think thats the class hierarchy.


> Discussion: As can be seen, so far we need system calls to
>         * Create new objects
>                 This must take in parameters describing
>                         (1) The code
>                         (2) The method declerations
>                 These two could (should?) be together in an executable
I think the correct phrase is MUST.

>                         (3) OIDs for the objects which the new object has
>                                 access to
>                 This is important -- it replaces the concept of a default
>                 name server. The only object that is not given an object by
>                 it's spawner is the initial object. Giving it a nameserver
>                 is part of the bootstrap process.
The new object has access to 1) itself, 2) any objects it (or its
class) creates, 3) any object whose OID is EVER passed to it, 4) any
object access from other dictionaries/name servers/directories.  I do
not believe that you can do away with a default name server/root
directory concept.  On the other hand, many objects have reasonable
cause to want to know the identity of there creater/parent directory.

>         * Destroy objects -- clearly this takes an OID as a parameter
My only argument here is that we may want it to be "Delete Myself",
with no parameters

>         * Invoking a method
>                 This takes
>                         (1) An OID
>                         (2) The method "name"
>                         (3) The arguments
>                 Issues:
>                         What is the type of the name?
>                         An integer is the obvious.
>                         When would the allocation of these be done?
I too would like to see method "name"s be integers.  I would also like
to see a large number of standard methods predefined, so we can use
switch statements as needed.

>                         The permissible type of the arguments?
>                         in a purely OO system we could just have OIDs and be
>                         done. In our system it is doubtful that representing
>                         (eg.) an array by an object would be practicle so we
>                         need to be able to pass large granularity data between
>                         objects.
>
>                         This is where IPC comes in.
>                         (I'm using the definition that IPC involves data
>                          copying between address space]

I would agree that we should not restrict ourselves to objects as
parameters.  After all, how does one read a block from disk into local
memory if an object can only write it into another object?  And how
could one even write it into said object?

..

> (2) lolos:
>         How do we set an object up as a lolo, how do we give it access to a
>         certain region of memory.
>         (Implementation: we might need to have the access traped and then redone
>          by the kernel after checking -- MMUs don't neccessarily support fine
>          grain protection.
>          (Eg. this object can read bytes 100-102 and write bytes 103-110 but
>          can't touch bytes 0-99 and 111-500)
>         )
We should not need to limit the granularity of memory access by LOLOs
(at least on the 386).  Most (if not all) hardware devices that
provide memory mapped I/O provide large blocks.  We do also have to
provide access to I/O ports on a restricted basis, and allow interrupt
callbacks.

I would say that the header of all executables will include what
hardware facilities it will require.  If an executable is
appropriately listed as 'trusted', the process resulting from this
executable will have access to the facilities listed.

> (3) Virtual Memory and Address Space
>         I think we can more or less agree that seperate objects should not
>         be able to read/write each others address space for robustness
>         reasons.
I would allow objects of the same class to co-exist in one allocation
unit if the class is well-developed, simply to conserve memory.

>         Should we have an address space that is global or local to each object.
>         (Note: This IS an independant issue)

IMHO each process should have it's own address space, and each object
should have a block of memory that is mapped into its class's address
space when a message is being processed.  The address of the objects
memory would then be passed to the code for processing.  For derived
class objects, the address of the classes data would (also) be passed.

>
>         How should VM be done? I think paging is the simplest way.
>         DEtails:
>                 User input to the process if any
>                 Existance of PHYS_MEM and it's management

Physical memory would be handled in the same way as I/O (see above).


..

> (5) Semantics of invocation
>         MOOSE is multitasking.
>         What happens in the following situation:
>
>         Object X        Object Y        Object Z
>         Invoke(Z,1)
>                                         Starts executing method 1
>                         Invoke(Z,2)
> The three obvious possibilities are
> (a) Z starts another method in parallel
> (b) Y is blocked until Z finishes
> (c) Y continues and the invocation is queued.
>
> (a) Gives us multithreading and requires us to have semaphores to co-ordinate
> access to shared data.
> (b) Is the simplest to implement but is less versatile
> (c) Makes invocation asynchronous -- this adds paralellism to the system.
>
> Notice that under (b) one could have the invoke call return a result.
> Under (c) though the invoke would not return anything (other then
> "this was succesfuly queued" OR "this failed") and the reciever would use
> it's own invoke to return an answer.
>
> Of course we could (and probly will end up doing) provide more then one.

IMHO we should have all three.  The difference between (a) and (b)
will be at the discression of the receiving process (=1 or more
classes).  The difference between (b) and (c) is that (b) is a send
and wait for reply, and (c) is send it now, tell me later.  Case (c)
is actually how new threads are started.

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com