OS design...

[Ray Dillinger]

On Fri, 16 Oct 1998, Damond Walker wrote:


>>2) a standard "language" for communicating dynamically typed
>>   objects via sockets, as well as raw bytes.
>>
>
>    Your saying that all services should commit to a standard interface of
>routines?  *OR* are you talking about actually scripting all this?
>

No, not routines per se, but a way of saying "such and such
service has been spawned as a process and is waiting for input 
in QQQ format on port XXX."  One of the points of the system is
that you are no longer required to communicate executable code
per se, just a method of interacting with the "service" that the
executable code (which your process has spawned) makes
available. So instead of sending executable code to something,
you can spawn the executable code as a separate, self-contained
process. 

For example, let's say you want a wakeup call when some
arbitrary condition becomes true and you have code that
calculates the arbitrary condition.  According to the exokernel,
you would send the code itself to the process scheduler which
would then link it in and call it whenever your timeslice came
around and wake you up if it returned true. 

According to the system I envision, you would have a
"waker-upper" daemon with instructions to restart you.  You
would start it by "exec"ing out to it, ceding your PID to it. 
(this gives it your credential to read the memory buffer where
the kernel keeps its data (corresponding to port zero or
somesuch)). The kernel never has to know about it at all -- it
just has to have its structures visible and in a consistent
state when the timeslice comes around; it starts the process
with your PID (now your waker-upper daemon) and the waker-upper
daemon would read the kernel data, perform its calculation, and
then either exec out to restart your process or just cede its
timeslice to the next item on the process list. 

I think you could even do this with multiple processors -- if
the kernel were pretty rigid about some consistency rules (such
as never updating a pointer until the thing it points at makes
sense, and never deallocating/corrupting something until there
are no remaining pointers to it and everybody has had at least
one timeslice since there were....


				Ray