Subject: Re: curproc removal (NFS, ...)
To: YAMAMOTO Takashi <>
From: Jonathan Stone <>
List: tech-kern
Date: 05/24/2004 18:36:01
In message <>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?