In message <200406061444.QAA22759@father.ludd.luth.se>ragge@ludd.luth.se writes

>When frobbing the subject - what is happening in the splice() area?

do you have an application for it?

I still hope to implement splice(2) with kcont(9).  But we're still
pinning down an, um, an API (I'm avoiding the word "contract" here),
that specifies exactly when it's safe to call soreceive() from a
kcont-like context.

Then you can build a kcont that uses recvfrom() with a non-NULL struct
mbuf **mp to reads data out of one connected socket, and sendto() to
write it to another socket of the same type (SOCK_DGRAM, SOCK_STREAM,
SOCK_SEQPPACKET).  Register the kcont as the sbnotify callback
function of each socket.

It's a little more work than that, since:

   a) when a socket becomes readable, you need to check the
      peer's receive sbspace() before pulling data out;
      similarly, when a socket becomes writable, you need
      to check if the peer has ready data but was blocked waiting
      for the socket to become ready.
      DMR mentions the same underlying issue in the streams paper.

   b) NetBSD (4.4-Lite?) has a signle shared callback function
      for soreadable/sowritable/exceptions, so you need to fold
      all the tests into one monster continuation (callback).

but not really that much more.