In message <FFF15B15-8027-11D8-8447-000A957020BC@3am-software.com>,
Matt Thomas writes:

>
>On Mar 27, 2004, at 10:35 AM, Jonathan Stone wrote:
>
[... snip lots... ]

>Don't pass in a NULL uio. 

I've tried.  Passing NULL uios to sosend() is the only sane way to go.
The alternative is preallocating uios and wrapping mbufs chains you
just read from one socket, inside a UIO_SYSPACE uio before sending
them on another socket: thats a non-starter for performance reasons.
Also, last I looked, it still doeesn't guarantee the atomic-send,
record-boundary semantics needed for SOCK_DGRAM.

[ ... Explicit struct proc* to so_send().. ]

I never kept a list of what curproc gets used for, once sosend() grabs
it and passes it down. I'm willing to entertain making sosend() work
as you suggest -- or at least, to figure out if there are issues
significant enough (more than the message-send counters), that warrant
passing the struct proc *.

I do have dim memories of code somewhere grabbing process credentials;
but I've been using code that passes the explicit struct proc * to
sosend() for so long that I honestly don't remember.

FWIW, I originally tried a slightly different argument ordering, till
I noticed the netsmb code claims other *BSDs all pass sosend() and
so->so_send() a last argument that's the struct proc *.  The
argument-lists to sosend() are already so big they overflow RISC
in-register passing conventions, and dirty enough stack cache-lines,
that (once calling sosend() from kconts tripped over the curproc) I'm
willing to pass the process pointer, just for uniformity, for
consistency with the non-kcont case, and for ease-of-use reading and
porting other *BSD networking code.

Whatever's best, really. I see this as something gentlepersons can
agree to disagree in good faith :-/. As long as I can call sosend()
RSN from kcont-context where curproc is NULL or otherwise not valid or
not appropriate, I'll be content.