> I am looking out for some information regarding moving TCP/IP stack
> to user area.  Right now what code we are using is largely dependent
> on Unix Kernel.

This could be done, but I have to ask: why bother?  The only advantage
I see is that it means that bugs in the stack don't crash the kernel,
but there aren't many bugs left in that code.  It gets pounded heavily
on millions of machines all over the world, thousands of them even
running the exact code that's in NetBSD.  And moving it out to
user-land is likely to incur a significant performance penalty.

> 1) Interrupts
> 2) memory allocation and deallocation.
> 3) timers.
> 4) [spl*()]

(1) is mostly a non-issue; you just need your network interface drivers
    to pass their packets out to user-land untouched.  For development,
    you could do this under a modern kernel with bpf (or moral
    equivalent, if not using NetBSD); for real use, you probably would
    want to create a special device corresponding to the network
    interface(s).

(2) basically goes away too; memory allocation in user-land is a
    much-addressed problem.

(3) is fairly straightforward as well; there are plenty of timer
    services available to user-land.

(4) becomes unnecessary when switching from an interrupt-driven
    paradigm to an event-loop paradigm.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B