> You can ask a different question:``what will sosend() use its struct
> curproc *p for when called on a TCP socket?''?), in which case I can
> give you a concise, accurate answer.
> 
> Or, you can ask ``What possible things might the struct proc * be used
> for, if sosend() is called with an arbitrary pointer?''.

ok, maybe i had to be more specific.

uio_procp was used to specify address space which iovecs belongs to.
and it was NULL in the case of UIO_SYSSPACE.  (see uiomove(9))
what's benefit of changing it?

for another example, in nfsrv_rcv,
you changed uio_procp from NULL to curproc.

	/* XXX: was NULL, soreceive() requires non-NULL uio->uio_procp */
	auio.uio_procp = curproc;       /* XXX curproc */

curproc here might be nfsd if it's called by nfssvc_nfsd.
and it might be a arbitrary process, or even NULL, if it's called
via so_upcall.
i don't understand what's the point of this change.
i think that NULL is fine.

i understand why you want to eliminate curproc.
but i don't understand why you want to eliminate (struct proc *)NULL
and (ab)use uio_procp.

> If what you want is to break down the usages of struct proc* arguments
> to a finger granularity, as Matthias Drochner suggested:
> 
> 	>> -scheduling (ultimatively to be passed to ltsleep())
> 	>> -access rights
> 	>> -accounting
> 	>> -address space for virtual addresses
> 
> then I am skeptical that can be done cleanly. Very briefly, all
> the socket layer knows is that it passes a struct proc * down
> to the protocol-specific entrypoint: a PRU_ATTACH message  to (*pr->pr_usrreq)().
> The protocol -specific function can do *whatever it wants* with that argument.
> 
> Longer answer: look at binding or connecting a socket. For PF_UNIX
> sockets, the struct proc * argument to socreate() is [implicitly] used
> for credentials for filesystem operations to create or lookup the
> filesystem name of the socket. [Yes, I know, right now the dynamic
> call-graph discards that argument and the FS layer picks curproc.
> That's a wart that imnso should be fixed.]
> 
> But for other protocol families, the struct proc * isn't used at all.
> 
> sosend() has a similar story. It used to pick up curproc, pass it down
> to the protocol's PR_SEND, which can do whatever it wants with it.
> Now, many (most?) protocols don't use the struct proc * at all.
> But if you do a sosend() to an unconnected PF_UNIX socket, uipc_usrreq()
> will gratuitously use the struct proc * to connect() the socket for the
> duration of the send (i.e,. pass it to NDINIT()!), then unbind it afterward.
> So you can't really tell, at the socket layer, what might or might not be
> done with the struct proc * argument.

do you mean, because proc pointer isn't used at all or is used in the
very protocol specific manner, a pointer to an arbitrary proc is good enough?

YAMAMOTO Takashi