Date:        Sun, 13 Jun 1999 19:47:43 -0400 (EDT)
    From:        woods@most.weird.com (Greg A. Woods)
    Message-ID:  <m10tJyZ-000gAAC@most.weird.com>

  | Well, OK, I agree for the most part *but* there's one important
  | distinction that is only recently being worked around:  Chapter 3
  | interfaces can mostly be replaced at will with incompatible
  | functionality in a program, but Chapter 2 interfaces cannot be replaced
  | without jeopardizing the correct functioning of some standard library
  | subroutines

Nonsense.   I doubt you'll have the slightest trouble in your average
program if you replace ktrace(2) or chflags(2) or unmount(2), or semctl(2).
On the other hand if you randomly replace printf(3), malloc(3), strcpy(3)
(etc) with incompatible functionality, half the world is liable to break.

Some library routines are called by others, and need to remain as they
are for the rest of the library to work.  Others don't.   That divides the
library into two distinct sets.   Some library routines are just stub
wrappers around sys calls, others aren't.   That also divides the library
into two distinct sets.   The two divisions aren't even similar.

  | From a documentation point of view I think the distinction is still
  | important too

Why?   As long as the correct behaviour is observed, why would you care
whether you are calling time(2), or a time(3) which calls either ftime(2)
or gettimeofday(2), or something else?    About the only use I can see for
being able to tell the difference is so you have a better hope of figuring
out what is happening in a sys call trace - but even there, if you see it
in the trace (today) then you know it was a sys call, it might all change
tomorrow.

kre