Re: Thoughts on the ADaOS user program interface

["Warren W. Gay VE3WWG" <ve3wwg@home.com>]

Kenneth Almquist wrote:

> I've been thinking about what the system call architecture for an
> Ada OS might look like.  I would want the interface to be specified
> in a collection of packages, all descendents of a package named
> AdaOS or somthing similar.


I like this idea.


> The Intel x86 architecture supports procedure calls across protection
> boundaries (so that user code can invoke procedures in the kernel),
> but the design is not secure if you have multiple tasks because the
> kernel mode procedure runs on the same stack as its caller, which
> allows another task running concurrently to alter the stack frame of
> the kernel mode procedure.  So calling a system procedure requires a
> trap to allow us to switch to a kernel stack.  We could generate a
> stub for each call which executes a trap instruction (that is what
> Linux does), or we could tell the linker that the system procedures
> are at addresses which are not actually mapped, and have the trap
> handler invoke the actual kernel routine.


I suspect that in the interest of portability, you'll want to use the
library technique to interface to the O/S. This way, you have a normal
procedure call to the library routine, and then the O/S specific
library routine can issue the trap or whatever is appropriate for the
current hardware. I personally like the idea of calling some address
directly, but for portability reasons and others that you have pointed
out may work against this idea.

The Prime-50 series used to "snap" links to O/S routines. The pointer
was initially set to point to the string name of the O/S service in
such a way that a fault would occur. The O/S then would patch the
pointer to another value that would directly invoke the ring-0
routine (this is "snapping" the link). Thereby only invoking the
name lookup the on the first call.  I don't know if this would
work well on an Intel machine (for stack reasons, it sounds doubtful).


...

> Error reporting should be done by throwing exceptions with a descriptive
> error message attached.  My experience is that more often than not,
> if a system call fails the program logic doesn't care why it fails.


I have to disagree here. This may often be the case in some class of
applications, but servers and other more system-level software _do_
indeed care, and often must take appropriate action. One issue that
comes up in UNIX/BSD is the EINTR/EAGAIN error, that occurs when
a system call is interrupted due to the handling of a signal. Now
this could be handled at the O/S level differently in AdaOS, but it
may not always be simple (i.e. do you proceed with the system call
that is in progress, save its interrupted state, or back out the
system call as UNIX often does - returining EINTR/EAGAIN?)

Other classes of errors that are often examined are EACCESS, ENOENT,
ECHLD, EEXIST, ENOSPC, ENAMETOOLONG to name a few.

I think the deciding point for exceptions may be the frequency/cost
of the exception, and the nature of the error. Then again, I'd
be inclined to probably side with exceptions even in the case
of overhead, only because CPU
hardware is getting so much faster each year.

I have wondered if errors should be classified into a few
major categories, and then the classification of the error be the
exception that is raised. Then after catching the error, you
then examine the error code and decide upon the specific action.
I havn't decided myself, if this is necessarily a good thing, but
perhaps something to consider.


> There should be a stub generator to create the linkage code to allow
> kernel subroutines to be called from user mode.  The linkage code
> needs to handle arguments as follows:


I still like package library support between the app and the kernel
better. Then there is no difference between calling a kernel service
or any other library routine.


> An initial implementation of these ideas could be done by adding
> code to Linux or BSD.  This would allow an initial implementation
> to be put together fairly quickly, allowing experience to be gained.
> 				Kenneth Almquist


Absolutely.

-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg