Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!samsung!usc!ucsd!ucbvax!BEACH.CIS.UFL.EDU!pak
From: pak@BEACH.CIS.UFL.EDU ("Philip A. Kufeldt")
Newsgroups: comp.os.minix
Subject: Minix TCP/IP
Message-ID: <9005030137.AA28920@beach.cis.ufl.edu>
Date: 3 May 90 01:37:25 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 86

Ray,
 Originally I did not correctly estimate the degree of your interest
and that is why I did not give any real details of our implementation.  So let
me now go into our development. But, first let me say that we are committed to
Minix as a teaching tool and plan to have a complete Minix lab of *inexpensive*
PC's for students to tinker with.  This is why we are using Minix 1.3 as our
base for development.  This commitment will come back to haunt us.

 First we are following, as best we can, this model:

        +-------------------------------+
        |        Application Layer      |
        |            (Clients)          |
        +-------------------------------+
        |         Transport Layer       |
        |          (TCP,UDP,..          |
        +-------------------------------+
        |         Internet Layer        |
        |              (IP)             |
        +-------------------------------+
        |       Network Interface       |
        |           Upper Layer         |
        |           (ARP/RARP)          |
        |  ---------------------------  |
        |       Network Interface       |
        |          Lower Layer          |
        |           (Drivers)           |
        +-------------------------------+
        |         Hardware Layer       |
        +-------------------------------+

This loosely conforms to the OSI layered model.

 Now how does this all fit into Minix?  Our layout matches yours almost
exactly:

 +--------+-----------------------------------+
   4 |  INIT  |        Application layer          |
 +--------+-----+--------------+--------------+
   3 |      FS      |      MM      |      NM      | (Network Manager)
 +--------------+--------------+--------------+
   2 |  Disk  |  TTY  |  Clock  |  System  | .... |
 +--------+-------+---------+----------+------+
   1 |              Process Management            |
 +--------------------------------------------+

       Layout of NM server

 +--------------------------------------------+
   3    |                Socket Handler              |
 +-------+-------+----------------------------+
   2 |  TCP  |  UDP  |  ........................  |
 +-------+-------+----------------------------+
   1 |                 IP / Router                |
 +--------------------------------------------+

As you can see we don't have any hardware-specific support in our network
manager.  We feel as if those are the things that belong inside the kernel.
This includes ARP/RARP.  These two protocols are very hardware specific and
really don't belong anywhere besides the driver.  That is why we have put the
network interface within the kernel.  Realizing that the routines governing
the ethernet and the routines governing ARP/RARP are vastly ideologically
different, we split the driver into two halves.

 We at present are not making use of the FS for any reason.  But your
comments are making me rethink this position.  Also our scope has been narrow.
We have only been considering ethernet support, but you make a very good case
for generalizing that area.

 I understand your concern for a good version of TCP/IP written from
scratch.  That is one of the driving forces behind our development.  The other
is the Minix lab which *must* have decent performance or it is useless to the
students using it.  Unfortunately, the ultimate layered designs set forth by
OSI will cost too much in the final implementation, so minor concessions must
be made.

 One other goal I should let you know of is our commitment to the coding
style of the Minix operating system.  We want our final product to look like
it came from the hand of Andy himself.  So a close observance to the style of
servers and drivers is essential.

 I appreciate your comments and welcome them in the future.

Philip A. Kufeldt
Computer and Information Sciences
University of Florida