Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version nyu B notes v1.5 12/10/84; site csd2.UUCP
Path: utzoo!linus!philabs!cmcl2!csd2!martillo
From: martillo@csd2.UUCP (Joachim Martillo)
Newsgroups: net.lan
Subject: Re: socket library under System V?
Message-ID: <3070002@csd2.UUCP>
Date: Thu, 8-Aug-85 11:39:00 EDT
Article-I.D.: csd2.3070002
Posted: Thu Aug  8 11:39:00 1985
Date-Received: Sun, 11-Aug-85 06:11:55 EDT
References: <284@SCIRTP.UUCP>
Organization: New York University
Lines: 40

/* csd2:net.lan / dfh@SCIRTP.UUCP (David F. Hinnant) / 12:05 pm  Aug  6, 1985 */

>  We've been talking with various Ethernet vendors (Interlan, CMC,
>Excelan, etc.) concerning implementing Ethernet on our 80286 Multibus
>box under UNIX System V.  Software-wise they'll give us a "socket
>library", TCP/IP, a driver, and the BSD applications.  All the pieces
>are there; it's the "socket library" that has me a bit confused.  4.2
>BSD implements sockets in the kernel. I presume the socket library gives
>the same functionality, but I don't see how.  Can anyone that has this
>kind of library tell me what it actually does?

There  is no need  to implement sockets in  the  kernel though this is
probably the  better  thing  to do.  Basically  all the driver does is
tell how to read  and write  the network interface  and possibly  send
control   information  via ioctl commands.   Presumably  a user  could
write to the /dev associated with  the ethernet interface directly via
read and  write system calls.  The library  will do this  for  you and
tag  on all the  appropriate headers and  what-not  that are currently
done in the 4.2BSD kernel.

Now why  is it   better to do  things  as are  done in  4.2  BSD?  The
Berkeley approach  makes it far easier to  approach  ipc in  a unified
fashion even though you have many domains and many  protocols and many
communications  devices  attacked to your machine.   In   4.2 you just
invoke socket,  bind, connect  (or listen)  for all  of  them.  With a
library approach  you  will have  to  rewrite your  library  and  then
probably relink your executables,  should you also  want to run   some
other protocol besides TCP/IP.  If you want to  do routing  you can do
this either  in  the application library or in  the  driver.   Neither
idea is good.

There are also lots of   minor  benefits from putting  all the  grunge
work    in the   kernel.     Port  allocation  is  simplified.  Binary
executables  tend  to  be smaller  (which can be  important since  ipc
programs tend to proliferate when it all becomes available).

Now why would you want to use the library/driver  approach?  Maybe you
are stuck with system 5 or perhaps  you are dealing with  some hostile
operating system supplier  which won't let you  see kernel source  but
will tell you how to write drivers.