KER, obj (was Re: KER, win)

[Dennis Marer]

> Hi! 
> I've knocked up a sketch for a simple kernel.
> I've currently left out virtual memory and object support simply 
> because virtual memory seems to be dependant on how we do objects and
> we haven't reached a consensus (or even an understanding yet!) on objects.

Great - we'll be looking forward to seeing that!

Q: Why is virtual memory considered dependant on how we do objects?  Maybe I
   missed that discussion...

-------------------------------------------------------------------------------

I have some thoughts on objects:

I would like to see the kernel *support* objects.  (Now I have to define what
this means.)  The kernel does not consist of objects - all of the kernel 
functions will be standard function calls.  However, some of these calls take
objects as parameters, and some portions of the kernel use objects when they
are called.

For example, I was working up a method for handling hardware interrupts in an
OO evironment.  It's been driving me crazy trying to find a way to have an
interrupt pass control to a method within an object.  (Consider if a device
driver is an object, this is *exactly* what needs to be done.)  I've devised
such a way (implementation details are unnecessary right now) and the
interface to it is like so:


	These deal with regular interrupt handlers, cases where a function
	is called when the interrupt is generated.  No data is passed to the
	function.  The 'number' is the hardware interrupt number, the
	'handlerFunction' is the address of the function to call, and the
	'flags' parameter can be use to indicate that an interrupt can be
	shared by one or more handlers.  This is useful (for example) with
	the IBM PC's serial ports.

		status = IntrAddHandler(number,handlerFunction,flags);
		status = IntrRemoveHandler(number,handlerFunction,flags)

	Now for the fun stuff!  An interrupt handler can be added to generate
	an interrupt and call an object's method using the following functions.

		status = IntrAddObjectHandler(number,object,method,flags);
		status = IntrRemoveObjectHandler(number,object,method,flags);

Ok - this is just an example I've been tinkering with.  I think its something
that does need to go into the kernel (most CPUs implement interrupts in some
state and somebody needs to control access) but for now its just an example.

In this case, the kernel needs to know enough about objects to (1) determine
if the method passed is physical or virtual, as well as the structure of
objects in general to see if it's got multiple inheritance in its lineage, etc.
and (2) be able to call this method when the interrupt is generated.  Also,
interrupt handlers can't have any parameters.

Remember how I mentioned modules have detailed information about all functions
and objects, including full parameter info about methods?  The kernel can use
this information to satisfy requirement (1) and to perform parameter checking.
I guess the kernel will also need to know about the structure of an object,
how to call a virtual function, and so on.

The structure of an object needs to be clearly defined by the kernel: how it
stores the attributes (data) associated with an object, how polymorphism
affects the virtual method tables (VMT) of an object, especially in the case
of multiple inheritance, and so on.  Also, this definition of an object needs
to be useful to all languages...this is a tall order to fill!

I'm familiar with objects in terms of Ada and C++, which could both use pretty
much the same object structure with no problem.  (As far as I can tell, method
scoping is the only real difference.)  How about other OOP languages anyone
is familar with?  How are these different?

I'll do some probing around in the newsgroups too - someone should have some
ideas on this... :-)


		Dennis