syscall(2) function (really: syscall(3))

[Mike Taylor]

In article <9757 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn (VLD/VMB)) writes:
>Quite possibly some of the application code opens files via calls to
>fopen() rather than directly using open().  The above trick has worked
>so far because UNIX fopen() eventually invokes the open() function in
>the C library.  In the near future, it is probable that UNIX fopen()
>will instead invoke a function called __open() or some such;

Am I missing something here, or is this a major disaster?  I always
thought that the beauty of UNIX was supposed be that everything went
through a simple, elegant and well-defined interface of system-calls,
that *all* reading was via read(2), that *all* writing was via
write(2), and so on.  I thought that UNIX was the operating system
where the user Knows Where He Stands?

It's kinda sad to see how the minimal set of low-level routines in
primitive UNICES has mushroomed to the incredible 178 distinct system
calls that our current UNIX (SunOS 4.3, in fact) seems to find
necessary.  But surely once you start saying that fopen() doesn't have
to use the system-calls at all, the whole ethos goes right out the
window?  I remember the quote from Ken Thompson: "The only thing I
would chnage if I designed UNIX now is that I would call the creat()
system call create()".  Ask yourself how *that* ties in with this
apalling move?
______________________________________________________________________________
Mike Taylor - {Christ,M{athemat,us}ic}ian ...  Email to: mirk at uk.ac.warwick.cs
"Can't say my name's well-known, you don't see my face in Rolling Stone (yet)"
------------------------------------------------------------------------------