Hi Matt,

We seem to be at cross-purposes again. The whole point of this change
is to be able to call sosend() from outside of process context: from a
softint or (in my case) from a kcont.

For that, I beleive the sosend/so_send changes you describe as "not
needed" are actually essential.  Good thing I said I was happy to wait
for awhile :-/

I tried, and it just doesn't work to use the uio: for splice(),
particularly DGRAM-to-DGRAM, you really want to pass in a non-NULL
mbuf chain, and a NULL uio. You can't use the struct proc in a uio, if
you don't have a uio to start with.

For socreate(): sure, its reasonable, so I did it whilst I was in
there fixing sosend(). Last I looked, these changes still don't go far
enough to call socreate() from a kcont. I have tried; but creating a
PF_UNIX socket runs smack into uses of curproc down in the VFS layer,
when tying the socket into the filesystem namespace.

For splice() [and for the tee() Jeff Mogul suggested], one can mandate
that userspace do the socreate() and pass an open fd into the syscall
that sets up the kcont()-based splice()/tee() code.  For my own
private uses, I've used a kthread (tho' you have to be careful about
setting its filesystem context first).

There are several cases (nfs, etc) where you suggest passing a NULL
process to socreate() instead curproc.  I agree, these really
shouldn't be using curproc. But I've tried, and when last I tried
it[*], passing NULL would trigger kernel panics. Sure, I'd like to fix
those to not use curproc *and* not panic; but I can't guarantee to fix
them all right now.  Passing curproc is conservative and safe (in the
sense that the semantic end-result is exactly the same as what we have
now, where socreate() just uses curproc).

Again, this could wait for a day or two. Or I could commit part
(or all) now: whichever you prefer.

[*] What I was using wasn't exactly NetBSD, though.