Networking stack into kernel

[Bill Frantz]

At 8:03 AM -0800 4/30/98, Jonathan S. Shapiro wrote:
>Enabling arguments: (why I think it is feasible to do it in the kernel)
>
>  1. Network connections must be non-persistent.  The timeout
>     and sequence number mechanisms in the standard protocols do not
>     appear to be robust in the face of the multi-minute time "gaps"
>     that can arise from checkpointing.

There are some interesting issues here:

One interesting option is to allow TCP sessions to survive reboots of the
system.  I think to do this, you probably need to journalize the sequence
numbers so you have knowledge of the "current state" of the connection.

If existing connections are to be torn down on reboot, the other end should
be notified.  Otherwise it may have a hanging connection.  I have seen
these connections persist for hours and require a restart of the remote
application to clear.

It is certainly possible to tear down the connections whether the
implementation is in the kernel or outside.  (It is also possible to keep
them.)  The question is where is it easier.

>...
>
>Other arguments (pro and con)
>
>Following is in the form of an IBIS outline, which tries to capture
>the decision tree.
>
>  P  == Proposition
>  AS == argument supporting
>  AO == argument oposing
>  I  == issue
>  >  == fact
>
>  +  == accepted
>  -  == rejected
>
>...
>
>     AS+ Leverage existing code.
>
>         > current design preserves most of the BSD networking stack
>           code, with some fairly hairy "wrappers" to deal with timers
>           and network interfaces
>
>	 > in-kernel approach would preserve most of the network driver
>           and timer logic as well, which would save time and increase
>	   the number of cards we can support.

How do you protect against Trojan horses in the network driver code?  Even
if you aren't trying to formally verify the kernel, you still want to get
informal assurance of correctness.  Making it larger won't help.  (But
being able to easily port existing code is damn attractive!)


>     AO- Implementing this requires introduction of dynamically
>	 allocated memory into the kernel.

This issue is not exactly dynamic memory allocation.  It is always being
able to proceed when memory is not available.  e.g. When a page frame is
not available, the process needing it waits for a page out operation to
complete.  So much code is written which assumes that it is OK to fail when
malloc fails, that the easy way to express the need to proceed is to say,
"No dynamic memory allocation".

In the KeyKOS kernel memory is allocated for page frames, node frames,
mapping tables, I/O request elements, etc.  In the C version memory is also
allocated for stack frames.  Because the C version is a translation of the
assembler version, and does not use recursion, there is a proof of finite
stack depth.


-------------------------------------------------------------------------
Bill Frantz       | If hate must be my prison  | Periwinkle -- Consulting
(408)356-8506     | lock, then love must be    | 16345 Englewood Ave.
frantz@netcom.com | the key.     - Phil Ochs   | Los Gatos, CA 95032, USA