[unios] Re: IPC in the current OO model

[Srikant Sharma (Chiku)]

From: "Srikant Sharma (Chiku)" <srikants@wipinfo.soft.net>

On Mon, 21 Dec 1998, OJ Hickman wrote:

> From: OJ Hickman <hickman1@peak.org>
> As I understand the current OO model each object has a set
> of methods that are accessed over the IPC channels. Correct?
> 
> Since you can't have direct calls between objects with
> different states they must use the IPC infrastructure to do
> interobject invocations.
> I can only come up with two ways of doing this:
> 
> 
> 1: Interpret method tokens.
> 
> Each message would be of the form of:
> ----------------------
> Token      - First byte or word in the message
> .
> .
> .
> Parameters and data
> .
> .
> .
> ----------------------
> 
> The receiving object would have to test the token with
> conditional logic and redispatch the call. About the same
> mechanism as old time BASIC interiptors.

This is the current way of doing *anything* in unix.

> 
> 
> 2: Setup a communication channel for each and every method.
> This would involve a system with thousands of open
> communication channels. The overhead would be monstrous!

obviously .. no one uses this ...

> Solution #1, which seems to be implied by the current model,
> is like sending a letter by putting each word on a separate
> post card. The postage cost would really add up! IPC is done
> with expensive calls to higher protection levels, it too
> would add up.

can you please elaborate on this?

> 
> Batching invocations, one of the main points of LOS, would
> mean multiple inexpensive iterations of the token decoder
> loop for each expensive call to the IPC system.

If my understanding is coreect ... here some invocations are 
grouped together and with a regular interval these grouped 
invocations are analysed (is that correct ?) and the required 
activity is carried out.

My doubt ...  what happens to the performance ...
Also in the worst case, if some entity (say a process) makes
successive ipc calls where each subsequent call format (nature) is
dependent on the previous call ... how is batching going to help ?


> The OO type inheritance system of Vocabularies and Jargons I
> outlined would provide a structured framework to define the
> reprensations of methods, that is, tokens.
> 
> For example:
> 
> Object X is a console.
> Object Y is a storage system.
> Object Z is a user program using A and B.
> 
> Both X and Y have some common methods such as READ and
> WRITE. Are these going to be represented by different tokens
> sent to X and Y? I don't think so.
> 
> However, X and Y need to extend their interfaces in a
> derivative way to add operations such as CURSOR_LOCATE to
> the console and OPEN_FILE to the storage system.
> 
> Object Z only needs to know the root vocabulary plus the
> jargonal extensions made by X and Y. This does reduce
> duplication of definitions.
> _______________________________________


Pardon me for being a little bit crude. 
What is new in this ?
In SVR4 unix there is a data structure  required to be written for 
each device driver. i.e. struct cb_ops.

This defines the entry points like read, write , ioctl .. etc...
e.g.
	static struct cb_ops tst_cb_ops = {
                nulldev,
                tst_close,      /* close */
                nodev,
                nodev,
                nodev,          /* dump */
                nodev,
                nodev,
                tst_ioctl,              /* ioctl */
                nodev,          /* devmap */
                nodev,          /* mmap */
                nodev,          /* segmap */
                nochpoll,       /* poll */
                ddi_prop_op,
                NULL,
                D_DEVMAP | D_NEW | D_MP
};

file : /usr/include/sys/devops.h 

take the same example of console & storage system.

the drivers for this will define the low level routines for read.
consider console ... : /dev/tty
consider disk......  : /dev/dsk/d01

I open the console .. the filesystem module calls up the open routine
from this console driver cb_ops which will do the initializations 
required for console ...

do a write ....   cb_ops for  console  driver will have a console specific
write routine which does the display manipulation part.
read ... will similarly  read the electrical signals from the keyboard.

same way I open the disk ...... cb_ops for disk driver will have the
disk specific open ... (will send some SCSI initialization .. or ide control
signals or whatever ...)

read/write will similarly branch off to the appropriate routines.

The basic objective of uniformity is followed.
This is the structured framework I have been seeing ....

we call this DDI/DKI (Device Driver Interface / Driver Kernel Interface)

Tell me the difference.

--
Srikant





------------------------------------------------------------------------
To unsubscribe from this mailing list, or to change your subscription
to digest, go to the ONElist web site, at http://www.onelist.com and
select the User Center link from the menu bar on the left.
------------------------------------------------------------------------
UniOS Group
http://members.xoom.com/unios