In message <1085451690.076023.1069.nullmailer@yamt.dyndns.org>,
YAMAMOTO Takashi writes:

>> that said -- I sincerely do not see the point you are trying to make,
>> because I cannot understand what you mean by `a random proc pointer'.
>> Could you please try to explain your point again, without the
>> reference to `a random proc pointer''? Or at least explain what you
>> mean by that?
>
>because a caller doesn't know for what so_send will use the proc pointer
>as Matthias pointed, it can't decide which proc pointer to pass.
>i called it as 'a random proc pointer'.
>(probably 'a pointer to a random proc' is more clear.)

Yamamoto-san,

thank you (sincerely) for the clarification.  Sorry if I wrote too much
in return; thats the easiest way for me to make a point very clear.

I'm still unsure if I am understanding your point.  How would you like
to see things change?

The way I see the problem, the `'method' (in ANSI C function-pointer
clothes) nature of the socket API calls makes it very difficult to
know what an argument might be used for.

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?''.

The answer to that question will, at best, be long and involved.
more, it will either be unheplfully general (if given as the set-union
of all possible options); or slightly more helful but even longer, if
broken down socket-by-socket, and probably protocol-by-protocol
(a PF_INET socket might have a slightly different answer for
SOCK_DGRAM versus SOCK_STREAM).

In either case NetBSD doesn't have a good, complete, up-to-date, reliable
answer, other than UTSL (which I fully agree is not very satisfactory).

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.

What would that picture look like in your ideal world?


>> If your point is that using `curproc' is somehow cleaner,
>
>no.

Thank goodness, at least we agree on that much.