Re: Networking stack into kernel Bill Frantz (frantz@netcom.com)
Thu, 30 Apr 1998 23:22:27 -0800

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