At 03:33 PM 6/5/2004, Jonathan Stone wrote:
>In message <1086415885.842307.9406.nullmailer@yamt.dyndns.org>,
>YAMAMOTO Takashi writes:
>
> >> Several of the callers which pass soreceive a struct mbuf ** don't
> >> even set the uio_segflag. Heck, before the changes I commited last
> >> month, there was at least one call where the values of both
> >> uio_segflag and uio_procp passing were uninitalized garbage from prior
> >> on-stack contents.
> >>
> >> I guess the cleanest way to fix this is to add a new UIO segflag,
> >> UIO_NONE, meaning that only uio_resid is valid; and also uio_procp, if
> >> its value is non-NULL, but a NULL value is allowed).  Do you buy that?
> >
> >in that case, for what do you use uio_procp?
>
><Deep breath>.  Because Matt Thomas convinced me that was a better
>approach than adding a new, explicit struct proc * argument to
>soreceive(), for the cases where soreieve() had previously been using
>curproc.
>
>((The reason for that <deep breath> is, the discussion
>seems to've become circular.))

It's all my fault. :)

>Even so, I personally would hope soreceive() does not use the
>uio_procp when passed a non-NULL struct mbuf **mp argument.
>Regrettably, the soreceive() source code has evolved somewhat beyond
>the comment in soreceive() which says in that case, *only* the
>uio_resid is used, and only as a limit on how much data to
>return in the mbuf chain.
>
>soreceive() now has ifdef'ed out code which uses uio->uio_procp for
>process-based accounting of send/receive ops.  Plus the changes where
>I now pass that value downward.  (As I said a few days back, I think I
>should back those changes out.)

I figure you only do the process accounting if uio_procp is non-null.

> >internalize/externalize things only make sense for UIO_USERSPACE, i think.
>
>Almost goes without saying,, once you put it that way.  Unless,
>just possibly for moving open-fds between userspace and kthreads?
>Do kthreads have an per-process open-file table?
>
>How about KASSERT(uio->uio_segflag == UIO_USERSPACE), for externalize
>ops in soreceive()?

Sounds good to me.


-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.