From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,88c174f3c455ecdc X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-09-07 10:08:46 PST Path: archiver1.google.com!newsfeed.google.com!sn-xit-03!supernews.com!logbridge.uoregon.edu!newsfeed.direct.ca!look.ca!news1.tor.metronet.ca!nnrp1.tor.metronet.ca!not-for-mail Message-ID: <3B98FA64.4080907@home.com> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Thoughts on the ADaOS user program interface References: <9n8eks$qsp$1@shell.monmouth.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 07 Sep 2001 16:48:37 GMT NNTP-Posting-Host: 198.96.47.195 NNTP-Posting-Date: Fri, 07 Sep 2001 10:48:37 MDT Organization: MetroNet Communications Group Inc. Xref: archiver1.google.com comp.lang.ada:12907 Date: 2001-09-07T16:48:37+00:00 List-Id: 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