Kernel 0.1, Win [djg7]

[David Garfield]

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

> > 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!

The kernel should NEVER be swapped.  Nor should any code/data the
kernel is using to do swapping.

> 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?

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

Making callbacks to an invoker should not require any privilege.  Any
object that is given something to call back to can do this.

> >
> > 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 skipped]
> >     * 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.

Since we want the object involved, adding the OID is obvious.  
Ideally, you might also be able to add entries without objects, but 
then you need to know a process and a location in the address space.  
Do-able.

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

[other issues skipped]
["A comment on (very) small objects" skipped]
["Some Other Issues" list skipped]
> > (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.

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.

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

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

If we are going to make this portable to something other than a
386/486/pentium, we can't use segments except for some very simple
stuff.

["(5) Semantics of invocation" skipped]
["(7) Polymorphism and Overloading" skipped]

> > And of course, feel free to comment, correct, suggest, debate and/or flame.
> The same to me.
And 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--

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?

David :-)

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