Kernel 0.1, Win

[Andreas Arff]

 > Kernel -- The Second Attempt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Idea 1
> ~~~~~~
> Consider now the form of such a server (which incidently bears a striking
> resemblence to the nameservers (or dictionaries)):
>
>     while (accept(request))
>         case request of
>             type1 : ... handle 1 ...
>             type2 : ... handle 2 ...
>
> This type of code will be very common in the system.
> It allready is in event based systems.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Those two sentences gives me the creeps. If I'll have to continue code that
way I'll stick to windows until moose 2.0!
Then we wouldn't have achieved the most important goal, simpleness!
It must be simple to program, or else noone ever will, except us!
Yes I see that we will need that type of structures in our code, but it can
be minimized using ROI-like devices as I suggested in my last mail.
Then that type of code will be neccesary only in the kernel and devices.

> Why then not have a process declare to the kernel that
> "I handle the following request:
>     req1 taking 4 parameters
>     req2 taking 3 parameters
> etc."

I must say I belive that is to give the kernel to much work.
I see 1 important goal for the kernel, to it keep efficient.
It must be small enough to be kept in physical memory all the time. Think of
a kernel, the most important (?) part in a system, that swaps itself out
because of its size!
I think this is to give the kernel to much work.
Why must a task go all the way down to the kernel to become familiar with
other objects floating around in the address space. I belive this could be
done in a higher level. Correct me if I'm wrong, I can take some flames!

> This is just an object.
> It has the concept of methods.
>
> [Note: It is open to discussion how much the kernel should know about the form
> of the parameters (Eg. number, type ...)]
>
> [note 2: Inheritance has been left out for the moment.
>  as have overloading and polymorphism]
>
> Definition 1
> ~~~~~~~~~~~~
> An object is a process with method declerations.
>
> 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)]

  (3) It has also been granted the privilege to launch certain processes in
  tasks that has asked for it.

>
> 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.
>
> Definition 4
> ~~~~~~~~~~~~~
> A Dictionary (Or Name Server) is an object which supports certain lookup
> operations and returns an OID.
>
> [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]
>
>
> 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 agree with the must.
>             (3) OIDs for the objects which the new object has
>                 access to
                  In addition it is presented to its own OID.

>         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.
>     * Invoking a method
>         This takes
>             (1) An OID
>             (2) The method "name"
>             (3) The arguments
I referr to my last mail where I have drawn a event-que with pointers to
functions. Maybe this way is somewhat better, that you supply the
OID, method name and arguments into the task-que.
>         Issues:
>             What is the type of the name?
>             An integer is the obvious.
>             When would the allocation of these be done?
The integers? At compile time. When you create an object, the object will
already contain numbers for its methods.
If the OID is distributed at runtime there wont be any OID.method crashes.
>             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]
>
>
>
> A comment on (very) small objects
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In a pure OO environment one could use an object to represent say an array
> (not to mention an integer)
>
> This is impracticle if we treat objects as processes since then a method
> invocation involves a context switch.
>
> This does not prohibit using small objects WITHIN a single larger object it's
> just that these small objects can't be exported to the rest of the system.
>
> I don't think that we can develop a system supporting small objects with
> reasonable efficiency in reasonable time. It involves too much research.

Sounds very wise.

> Some Other Issues
> ~~~~~~~~~~~~~~~~~~~~
>
> These are areas which bear further thought.
> I'll indicate my initial reactions to these issues.
> Rather then spend time filling out the details now (and spark a debate on them)
> I'd like to come to agreement on the basics first.
>
> (1) Memory Allocation
> (2) lolos -- how are they created, managed etc.
> (3) Virtual Memory  and Address Spaces
> (4) What are the semantics of persistance -- eg. what efficiency do we guarantee
> [Note: Efficiency is important in design in that a gross efficiency difference
> will influence the way a feature will be used.]
> (5) Semantics of invocation (Eg. do we have a single threaded or multi threaded
> semantics)
> (6) Inheritance
> (7) Polymorphism and Overloading
>
> ---------
> (1) Memory allocation:
>     What kernel calls, how and should we support higher level functionality.
>     (Eg. GC etc.)
> (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 look in the object dictionary at boot-time and just launch those
       objects that are listed under the device-index. Not that simple but
       almost. There must be information telling us what it needs.
       Maybe the standard devices should have their own dictionary (as I
       belive Dennis talked about in Januar) "hardcoded" in the kernels
       bootstrap code together with cpu ports lists for each device, and
       eventually other requirements.

> (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.
Yes.
>     Should we have an address space that is global or local to each object.
>     (Note: This IS an independant issue)
If you mean that the object can reach outside its own address space, I
belive the answer must be global. What if an object allocates memory and
it's pointer can't reach outside the object itself? Or did I missunderstand
something.

>     How should VM be done? I think paging is the simplest way.
Don't know if it's the simplest way, but probably the smartest. I belive
we are dumb if we only use segments.

> (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.

I would preferr alternative c, but there are some moments when you don't
want things to get qued.
Lets take a parallell to windows. Either you post a message, then it is
put into the que. Or you can send the message. Then windows just jumps
to the appropirate windows function (where the programmer has a 1000 lines
long switch-case to respond to all possible 70 messages; which is dirty
cumbersome and which I hate; and most important don't want to see in moose!)
and when that function returns it gives control back to the calling procedure.

> Of course we could (and probly will end up doing) provide more then one.
Probably yes.

> (7) Polymorphism and Overloading
>     So far I've only come across these as language design issues.
>      You have a "natural" polymorphism in some commands
>      (Eg. mv,rm,cp) when the contents of a file don't matter.
>
>      Could someone expound on their ideas -- how do YOU view the role
>      and function of polymorphism in an OS.
I don't think the OS should know anything about the data, if it isn't ment
for its own use.

> And of course, feel free to comment, correct, suggest, debate and/or flame.
The same to me.
> Michael
> Aka. Merlin son of Corwin and Dara, sorcerer and creator of Ghostwheel. :-)

Ha, Time Lord and Merlin son of Corwin and Dara, sorecerer and creator of
Ghostwheel, hah.
Me I laugh at your pettyness. Me, I am THE DUNGEON MASTER. Tremble you
weenie mortals, quiecheaters and lamers.
Me laugh at your pettyness. Your pride is only bullshit, me say as imortal.
You only live because of the GMs goodwill. So don't push your limits, then
you might get killed.

Arff :-)

sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--