Kernel 0.1, Win [arf2]

[Andreas Arff]

"> " is David
"> > " is Andreas Arff On 23 Mar 93 10:36:45 +0100
"> > > " is Michael WINIKOFF
>
> > > 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.
>
> This type of code should almost never be necessary.  The correct way
> to do this is something like a C++ Virtual Dispatch Table.  In other
> words, just go straight to the right function.

Cannot agree more, but just a couple of remarks, or what I should call it.
1) I have heard that VDTs are slow (ok - somewhat implementation dependant.)
2) VDTs could (should) be done with ROI
3) Each device object could (should) have its own VDT

> > 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!
>
> The kernel should NEVER be swapped.  Nor should any code/data the
> kernel is using to do swapping.

Good. But we can't have a kernel of the size of an elephant.

> > 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!
>
> The only other obvious choices are to ask the object itself or to have
> a centralized server(?) that every object (class?) introduces itself
> to.  But since the objects (classes) need to introduce themselves to
> the kernel for the purpose of inheritence anyway, why not allow
> outside processes to ask it as well?

Ok, if you can't beat them join them. Truly your argumentation, even though
it is very small, but clear as fresh mountain water, has convinced me.
You proposal will minimize the amount of communication done, because the
communication that is done, is necessary anyway.
IMHO an honorable idea!

> > > 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.
>
> Making callbacks to an invoker should not require any privilege.  Any
> object that is given something to call back to can do this.

Yes, but if you give it something to call back to, you _have_ given it
some sort of privilige. So by announcing your OID and a method number is
the same as saying, "please do something to me".
Lets take a parallell to real life. Say you are at a disco (don't know how old
you are, but if you don't like the idea, let's call it a pub) and there is a
girl that seems quite alright. Before the end of the night you have given her
you telephone number. Now does this mean you have given her the privilege to
call you later, or did you just do it for the fun of it?
Me not know you, but I know what I think it would mean.

> > >         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.
>
> I think I would rather see a set of numbers predefined for all objects
> (though objects need not respond to them), and other numbers be
> allocated at run-time, on a system-wide basis.  I will admit that this
> will require remapping some numbers in a networking environment, but I
> think we can live with this.  The name to number translation can also
> be reversible, which can simplify writing debuggers and similar
> functions.

How are these #predefine NUMBERS going to be distributed. By a central bureua?
Each task has its own number, within the task there are objects, within the
objects there are methods.
This gives use: TASKNUMBER, OBJECTNUMBER, METHODNUMBER.
In a networking system we will also have MACHINENUMBER.
With these four numbers you can identify everything down to a simple
method.
Machine number will be fixed (for long periods), the task number will be its
launching number and each object will get a sub-number. The method number
and the object number could now be distributed at compile-time. I could
address an object in your machine with this scheme via internet.

> This is startup, which is liable to be a very painful process.  We
> almost need to have the system come into being with lots of objects
> already built.  This is actually possible by loading a checkpoint, but
> we should have another way to do it.  Loading a checkpoint might be
> allowed as a quick boot technique.

Know what checkpoint means, but I don't understand what you mean with it.

> > > (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.
>
> IMHO, if an object allocates memory, nothing other than the object (or
> it's class depending on the allocation) should get access to the
> memory.  To give someone else access, either the data must be
> transfered through a method call, or a method call could initiate a
> shared memory access.

I agree with you about that.

> > 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 :-)
> >
> Campaign switch!  Now I'm THE DUNGEON MASTER.  I look, see some chaos,
> set everyone on the Moose development team up as a deity, but with
> power only as long as we all agree, and step down.  Chaos rules
> supreme.  Oh well, maybe we can build some law.  Maybe we can also
> achieve a certain amount of good, so the campaign will grow.
> Thoughts?
Is this a PBM?
With power as long as we agree. Gooood. The kernel spec's will be our law,
and we are eagerly awaiting Dennis new spec's -0.71.

> David :-)

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