Hi,
Can someone give a “General” description of photon microkernel or OS
microkernel?
Mach? Hurd? QNX?
Thanks a lot.
–
Aquila Mining Systems Ltd.
Previously, WeiBing Tong wrote in qdn.public.qnx4.photon:
Hi,
Can someone give a “General” description of photon microkernel or OS
microkernel?
Photon is not an OS, rather it is just the GUI. The
similarity in architecture between the Photon kernel and the
QNX microkernel is very superficial. Both are very small pieces
of code that perform fundamental functions. Thats about
where the similarities stop.
The QNX OS microkernel supports a very limited number of
OS calls, most notably the message passing calls.
The Photon microkernel sits on top of the QNX OS and using
message communicates with additional Photon componets, such
as Input drivers, Output(graphic) drivers and applications.
The conceptual model for the Photon kernel is a 3D Photon
space where the X and Y dimensions coorespond with what
is visually displayed on a screen, and the Z direction is
one in which Photon events travel in either direction.
Mitchell Schoenbrun --------- maschoen@pobox.com
Previously, WeiBing Tong wrote in qdn.public.qnx4.photon:
An example, when a client “B” asks some services from a server “A”,
there should have some agreements between Server “A” and client “B”
so that server “A” knows what type service client “B” asks by
message ID.Later, when a client “C” is needed to develop, there also should
have some agreements between Server “A” and client “C”. But adding
the new agreements may affect the old agreements between Server “A”
and client “B”. A RECOMPILE of generating binary of client “B” is
needed. This is not good.
Normally you don’t have to recompile B because you added functionality
to A. This would only happen if you disturbed the existing message
IDs in order to add new ones. That is Not Good, but also entirely
avoidable.
Thus my question is how to manage those messages ( message ID ) to
avoid the above problem.
Start at a base ID, and increment with every new message type. Never
change the ID of an existing message type.
We actually make our client/server communication into a form of RPC by
expressing the messages in ASCII as parenthesized expressions,
effectively equivalent to simple LISP. A message from the client to
the server is essentially a command, and the response can be treated
as a command as well. Parsing this type of expression is very
inexpensive. Also the expressions are human readable, they can be
used in both messages and configuration files so you don’t need to
write two separate mechanisms, they are bounded by the parentheses so
you can concatenate them, and they are architecture-independent. The
other nice thing about them is that any process that can send an ASCII
message can invoke the behaviour, making the server into an automation
object as well.
Some client/server applications seems not to be configurable, There
are a definition of common message ID shared by servers and
clients. Once one of them is changed, this definition also be
changed, then affect all the system.
This is just a fact of life. If you change the interface that the
server presents, of course you have to change the client to agree with
that new interface. This is like changing the parameter list on a C
function. Don’t do it if you want to maintain backward compatibility.
There isn’t a cooperative system on the planet that can continue to do
its job in the face of arbitrary unilateral interface changes. The
best you can hope for is that you can detect certain foreseeable
changes to the interface, which is really equivalent to saying that
your interface includes optional components.
Cheers,
Andrew
Mitchell Schoenbrun wrote:
Previously, WeiBing Tong wrote in qdn.public.qnx4.photon:
Hi,Can someone give a “General” description of photon microkernel or OS
microkernel?Photon is not an OS, rather it is just the GUI. The
similarity in architecture between the Photon kernel and the
QNX microkernel is very superficial. Both are very small pieces
of code that perform fundamental functions. Thats about
where the similarities stop.The QNX OS microkernel supports a very limited number of
OS calls, most notably the message passing calls.The Photon microkernel sits on top of the QNX OS and using
message communicates with additional Photon componets, such
as Input drivers, Output(graphic) drivers and applications.The conceptual model for the Photon kernel is a 3D Photon
space where the X and Y dimensions coorespond with what
is visually displayed on a screen, and the Z direction is
one in which Photon events travel in either direction.Mitchell Schoenbrun --------- > maschoen@pobox.com
Thanks!
You mentioned message communications and message passing calls, I have a
question:
An example, when a client “B” asks some services from a server “A”, there
should have some
agreements between Server “A” and client “B” so that server “A” knows what
type service client
“B” asks by message ID.
Later, when a client “C” is needed to develop, there also should have some
agreements between
Server “A” and client “C”. But adding the new agreements may affect the
old agreements between
Server “A” and client “B”. A RECOMPILE of generating binary of client “B”
is needed.
This is not good.
Thus my question is how to manage those messages ( message ID ) to avoid
the above problem.
One feature of microkernel is for scalability, you can configure the
system. What I know
is that there are many, many messages between each parts ( message
communications, message
passing call, etc ). How does the system manage those messages?
Some client/server applications seems not to be configurable, There are a
definition
of common message ID shared by servers and clients. Once one of them is
changed,
this definition also be changed, then affect all the system.
Thanks