[unios] m-kernel

[OJ Hickman]

David Jeske wrote:
> 
> On Tue, Jan 12, 1999 at 11:12:30PM -0800, OJ Hickman wrote:
> > David Jeske wrote:
> > > Microkernel which are pure IPC are not fast. Witness Mach pulling
> > > device drivers into the kernel, NT pulling device drivers into the
> > > kernel, QNX resorting to shared memory for low-latency communication.
> >
> > I think that shared memory based systems show the most potential for
> > competitive performance. When ever posable services should be
> > implamented in shared class objects. These are both data and
> > code encapsulated in a shared object and so can serve as a form of IPC
> > or hardware driver. [Some process blocking may be needed]
> 
> Show the most potential for competitive performance? Lets just be
> clear, shared memory is faster than stream based IPC.

So you answered your own question?

Also, consider the benifits of implamenting seream IPC in shared
objects without any kernel intervention. Shared objects could
also be a powerful way to implament such things as display
contexts and GDIs.

> My problem is that the kinds of things I like to do involve plugging
> things together becased on their semantic intefaces, not based on
> whether or not they were put in the same process, or are using shared
> memory based IPC or stream based IPC.

So your main concern is JUST design philosophy?

However, semantic intefaces ARE the basis of my design. You have
one global interface, the kernel [IPC, time, sceduling, memory]
and many shared object interfaces. Shared Objects could be used
to implament most simple process communication as streams and use
the kernel services to eficiently move large blocks of data
between processes.

> If you are asking me why I don't want to do this.... The answer is:
> Because I don't like the idea of having to rigidly decide, and
> compile, a block of code as a 'shared object' or a 'server'. I want to
> compile a block of code which exports an interface. I want other
> blocks of code to talk to that interface. I want the system to decide
> whether to inline the two blocks of code together (i.e. for maximum
> speed) or to run the two blocks of code on two different machines via
> network IPC.

You imply taking control out of human hands and forcing us to
write to generic object interaction interfaces unable to take
advantage of the strengths of eather shared objects or IPC.

More then that, you imply giving control to an all wise
[and hypercomplex] 'reflector' or some other sort of optimizer.

> > I think a lot of IPC is avoidable without 'macro-ify' the over all
> > service.
> 
> You propose making 1 and 2 shared objects and 3 a storage
> server. Which means 1 and 2 do not get the same level of 'safe'
> protection that a separate process server does.

Safer than a macro-subsystem. Shared objects are fairly isolated
by the class interface and the debuger should be able to locate
errors to within the problem object. Yes this is a trade off -
one that should be made by the implamentor.

> However, in response, I think you are correct, and for me, the answer
> is, stop compiling the implementation details of the communication
> channel into the executable. I'd rather use a run-time
> binding/compiling solution to make target specific code which handles
> the specifics of IPC.

Thank you.

But, sorry, I think [most] humans are smarter then any operating
system will ever be. Control needs to kept be in human hands.

> As long as we limit ourselves to producing static binaries at compile
> time, the tradeoffs of existing kernel's and software systems will
> always exist. Namely, some kind of 'safety vs. run-time speed'
> tradeoff.

You seem to say that my ideas are good for real world
problems but don't fit into some philisophical framework.

As the QNX example you gave shows, design philosophy needs to fit
real world problems. You can't squeeze real problems into a rigid
way of doing things and expect it to be the best solution.

_______________________________________________
"Imagination is more important than knowledge."
- Albert Einstein

Omer James Hickman - hickman1@peak.org - ojh@hotmail.com
http://members.tripod.com/~OJ_Hickman - updated 12/28/98