Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cwjcc!ukma!gatech!rutgers!cbmvax!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: syscall(2) function
Keywords: syscall, not system calls
Message-ID: <1090@auspex.UUCP>
Date: 28 Feb 89 20:56:30 GMT
References: <3740@ucdavis.ucdavis.edu> <11270@ulysses.homer.nj.att.com>
Reply-To: guy@auspex.UUCP (Guy Harris)
Distribution: usa
Organization: Auspex Systems, Santa Clara
Lines: 55

An omnibus reply:

> (Sorry for being so verbose.  I want to make sure that it is clear
> what I am asking--I've already received enough replies which go
> something like, "System calls are needed so that applications become
> independent of changes in the kernel....")

It's unfortunate that people believe that, because it's not true.  There
exist other mechanisms for dynamically binding code to a particular
procedure, which is what the person is *really* saying is needed here;
those other mechanisms work for functions *not* implemented in the
kernel, and that greater generality can be a big win.

It should be possible to make applications independent of changes to the
implementation of user-mode library routines, as well; that way, for
example, you can have the same application binary work, regardless of
whether "gethostbyname" reads "/etc/hosts", or talks to the Internet
name server, or talks to the Yellow Pages server, or talks to an Apollo
Registry server, or....  The application just binds to whatever the
local implementation of "gethostbyname" is.  (Sun has put a version of
its SunOS 4.0 "libc" shared library on "uunet" that contains a
"gethost*" that talks to the Internet name server rather than to the
Yellow Pages server, for example, so this isn't just a theoretical "this
could be done" argument - it *has* been done.)

> It still has uses...

> #include <stdio.h>

> /* 4.{2,3} reset UBA - BSD VAX */

It is useful there only because there's no library routine in the
4.{2,3}BSD C library that directly executes the appropriate trap, or
whatever.  Had they included such a routine, "syscall" wouldn't be
necessary in this case; nothing *prevented* them from including such a
routine, so the example does not at all demonstrate that "syscall" is an
absolute necessity, merely that a deficiency in the OS requires that
"syscall" be used to work around it.

>This user level library contains functions for all the system calls which
>take pathnames as arguments (like stat, open, link, etc.). We do some
>magic with the pathnames supplied to these functions and then call the *real*
>system calls with maybe different pathnames. The call to the real system
>call is accomplished through syscall().
>
>I could have done it without syscall(), but it would have required
>major kludges to do it in a portable way.

Again, this is a special-case solution to a more general problem; had a
more general mechanism for writing "wrappers" for existing procedure
calls existed - one that would, say, permit you to write "wrappers"
around routines that *aren't* just stubs that trap to the kernel - such
a mechanism could have been used.  So again, it doesn't demonstrate that
"syscall" is an absolute necessity, merely that it's required in some
cases to get around deficiencies in the OS.