Is it even theoretically possible for a kernel thread (say, one
spawned around the same time as the pagedaemon) to construct a TCP
socket, or must there be a userland daemon present to handle this
kind of thing?

A little background: as part of an academic project, I am tinkering
with ways to make a machine use the physical RAM of another machine
as a device to page memory out to (instead of paging it to a swap
partition on the local disk). The principles are first that, though
network speeds are still slower than disk speeds now, they are
increasing at a greater rate than disk speeds are, so paging to
another machine could eventually be faster than paging to disk, and
second that an in-kernel ability to contact and transfer pages to a
remote machine is a good building block towards fast and seamless
networked shared memory. (I've also got some other questions about
how one would fit this into UVM, but it seems to me that they are
orthogonal to the socket issue, and should be resolved by my
rereading Chuck's dissertation and maybe emailing one or both Chucks
privately.)

After a little thinking about this logically, I fear the answer is
no, since network interfaces are initialized long after virtual
memory is allocated in the kernel boot process (in fact, networking
initialization is handled by rc, not by the kernel proper at all,
correct?).

How does nfs operate with regard to this? The components in the
kernel lie dormant until the userland nfsd is started, and it just
uses those components for file system-related operations and handles
its socket communication itself?

Is there any way for a kernel thread to have access to TCP sockets
at all?

(Yes, I'm aware there are some other technical problems in actually
having a thread wire memory, then sleep till it can open a socket,
but is dealing with sockets from within the kernel even possible?
Without options INSECURE?)

       ~ g r @ eclipsed.net