#365 From: "Lynn H. Maxson" <lmaxson@...>
Date: Wed Mar 6, 2002 7:54 pm
Subject: Re: My point of view... lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
John Martin (JMA) writes:
"Sorry. The reason to have a CPAPI is to avoid kernel
dependancies.
I must change your phrase to: "Everything below the CPAPI and down
is part of the kernel"
Dont confuse that API with its implementation."
I'm trying to understand just where the confusion lies. API
stands for Application Programming Interface. CPAPI stands for
Control Program Application Programming Interface. Essentially we
have a "connection" through an interface, on the "calling" side of
which is the application and on the "responding" side, the control
program.
Like it or not the CPAPI is an implementation, a support
commitment allowing an application to communicate with (in this
instance) a control program. All portions of the control program
reside within the kernel as does the "responding" connection
portion of the interface.
In truth you cannot make the CPAPI independent of kernel as we
must have a path from the application layer interface, the CPAPI,
down to the lowest support layer in the kernel. That set of paths
represents an architecture, a kernel dependent architecture.
This does not change and only gets more complicated when
"layering" one OS's CPAPI (a guest) on top of another (the host).
All you have done is place an application layer with its lowest
level based on the host CPAPI with its highest level based on the
guest CPAPI. If this layering were such a done deal, then ODIN
would no longer remain essentially a "beta test" product, i.e. let
the user beware.
The microkernel takes a different approach. It regards a kernel
as something composed of two parts, the microkernel plus one or
more OS personalities. The microkernel, in effect, regards an OS
personality as an application, a buffered layer lying between it
and the applications written to its interface.
Thus the microkernel becomes the kernel-independent unit, as it
depends on no lower level of support. The OS personalities become
microkernel-dependent. However, this dependency now means that
they can co-reside as well as execute concurrently, in fact
multiple copies of each. This form of parallel "layering" of OS
personalities on top of a microkernel offers the best guarantee of
"shortest path" (thus maximum performance) over any vertical
layering approach.
Consider then that a specific kernel has a lowest API level, which
we will designate as a MKAPI, and a highest level, a CPAPI. Thus
you have three well-defined layers: (1) a microkernel layer, (2)
an OS personality layer, and (3) an application layer. We connect
them as follows:
<microkernel>[MKAPI]<os_personality>[CPAPI]<application>.
<*****************(((kernel)))*********><***(((application)))***>
Now the MKAPI has to support the sum of the CPAPIs of the various
personalities. This means that in general this sum is a
"superset" of any OS CPAPI, which in turn makes it a "proper"
subset. This superset capability of the MKAPI allows then for the
functional expansion and extension of any guest OS. In a sense it
is more important to define the MKAPI, as this defines the total
functionality (in terms of existing and future extensions) of any
guest OS personality.
In the FreeOS forum a division occurred on which was the easiest
and fastest means of implementation. Basically it came down to a
difference of opinion between Frank Griffin and myself, he
favoring a vertical layering approach on top of Linux and I, a
parallel layering on top of a microkernel. We each think that our
selection was the easiest and fastest to implement. Please
understand I say this with the greatest respect for Frank Griffin.
Just as we have multiple OS personalities to deal with we seem to
have an equal amount of microkernel choices, an equal number of
MKAPI sets to evaluate. As "No man is an island" no microkernel
decision is independent of a chosen OS personality, which in turn
is not independent its application possibilities. Thus we have an
architecture defined from the MKAPI level through the CPAPI level
to the desired set of APAPI levels. This says that what we want
to do in terms of applications drives what we must do in terms of
support.
While it is well and good to direct coding efforts at the CPAPI
level and above, replacing existing support with improved
replacements while maintaining functionality, in and off itself it
does nothing to preserve and extend OS/2 into a future beyond IBM
support. Making an exact OS/2 open source clone available some
five years after cessation of IBM support offers existing users no
more than what they have.
Why not then offer a better OS/2 than OS/2, a better Linux than
Linux, and a better Windows than Windows? Why not offer a
replacement product superior in terms of performance,
functionality, quality, reliability, security, and resource usage
to any of the others? At the same time protect users' application
investments?
Frankly doing all this is no harder, in fact easier, than going
around the barn trying to not do it.