🚀 go-pugleaf

In article <11506@ulysses.homer.nj.att.com> andys@ulysses.homer.nj.att.com (Andy Sherman) writes:
: A system call is a subroutine documented in Chapter 2. :-)

Right you are. And that is the only definition that is meaningful to
a programmer.

: Actually, a system call is an entry point which is a one-for-one mapping to a
: particular kernel service.  Open(2) is a system call which returns a file
: descriptor, which is a kernel data structure.  Fopen(2) on the other hand
: returns a non-kernel data structure called a stream, which is typedefed as
: FILE in stdio.h.  One field in the structure is the file descriptor, and one
: piece of fopen is a call to open to get that file descriptor.  System functions
: are the primatives which are used either by themselves or implicitly by
: subroutines which add some value.  (For another example, compare the
: execve(2) system call with the various execxxx(3) subroutines.)

There isn't a thing in the world requiring fopen to be implemented in
user code. It could just as easily be implemented as a system call.
And in some Unix versions, the different exec calls *are* implemented
all as system calls or as minor variations on a small number of
system calls (that is to say, each is really a small subroutine which
diddles in a slightly different way its arguments and then does one
of a few system calls).

And then consider sleep(). I know of one system where sleep was
implemented as a system call (and documented in section 2) because
the standard version of sleep would hang occasionally. Consider:

	alarm(n);
	pause();

(the guts of sleep) and what happens if the process doesn't run for n
seconds. Have you ever had tail hang on a heavily loaded system? (I
have.) Guess why.

---
Bill                            { uunet | novavax } !twwells!bill