Subject: Re: curproc removal (NFS, ...)
To: YAMAMOTO Takashi <email@example.com>
From: Jonathan Stone <firstname.lastname@example.org>
Date: 05/24/2004 18:36:01
In message <email@example.com>YAMAMOTO Takashi write
[... snip quoted text...]
>I don't think a random proc pointer is better than NULL.
All I meant by ``nobody really knows'' is that the acutal dynamic
invariants on which values get used beneath any given socket-level
(sosend, soreceive, socreate, etc) are not docmented. Those
invariants also get willy-nilly without discussion here on tech-kern,
in ways which might be seen as pulling in different directions.
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?
There was one place in the pre-change code which was passing random
junk (an onstack struct uio, where the uio's uio_procp was never set)
down to sorecveive(). Now, I can see calling *that* random; but the
code in -current now no longer does this.
Instead, the code now in -current now (mostly) avoids using curproc.
All callers of socket "methods" (such as (*so->so_send)()) now pass
down a struct proc * p argument, or a uio->uio_procp field in a struct uio*
argument, obtained from:
a) the struct proc * received from an explicit struct proc * argument
from the l->l_proc argument to a syscall; or
b) saved by the NFS code, in the r_procp field in the struct nfsreq *
for that request; or
c) in a few rare instances, uses curproc.
I dont see how any of these can be called ``a random proc pointer''.
You might just as well call the struct proc * argument to socreate() a
``random pointer *''. Or call the value of a the uio_procp field of a
struct uio * argument to sorecvfrom() a ``random pointer''. Or call the
other fields in a struct nfsreq * argument to a sys/nfs function``random''.
If your point is that using `curproc' is somehow cleaner, then I
beleive a lot of NetBSD developers would disagree. Moreover, the time
to make that point was back around March, when these changes were
first aired on tech-kern.
Does that help, or are we we still talking past each other
in mutual confusion?