On Wed, 2 Jul 2003, Darren Reed wrote:

> I had a look at some of the changes I made, today and probably the
> biggest bringer of problems is putting the lwpid into read/write
> ktrace records.
>
> To do this requires that vn_rdwr() somehow gets the lwp and the
> usual way it ends up with it is via 'struct uio'.  In modifying
> 'struct uio', I replaced uio_proc with uio_lwp.  It didn't seem
> sensible, to me, to put both the lwp pointer and the proc pointer
> in there but the ramifications of that change were quite immense.

How much code really needed the proc, rather than the lwp? I think this
change is fine.

> This may have been why I ended up changing so much of the VFS code.
>
> Then there are other changes, such as ttioctl().  It needs a lwp
> to pass to NDINIT (TIOCCONS), so rather than pass in a proc pointer,
> it now gets an lwp pointer.  Seemed like the correct change, to me,
> even if it is an obscure reason.  (Can I hear you swearing from
> here, Jason ? :)
>
> As for selrecord(), I think I mentioned on icb the reason for this:
> just about everything calling it was now doing "selrecord(l->l_proc)"
> so the nature change, to me, was to push that dereference inside the
> function selrecord().
>
> Does someone want to comment on whether or not this is a good/bad
> idea and whether or not both proc & lwp should be in there?

I personally like it. If everything is doing selrecord(l->l_proc) already,
passing the l down doesn't hurt that much. And as of now (as I understand
it), LWPs are the fundamental things that actually sleep, not procs. So it
makes sense to note the sleeping LWP.

Also, I think that eventually we will want to change the select code so
that we can handle multiple LWPs sleeping on the same thing in a way that
isn't O(total # sleeping LWPs).

> Anyway, I am going back through my changes trying to weed out those
> that are not necessary but be warned - there may not be that many
> to remove, but I will try unless someone wants me to use curlwp or
> the function that tries to guess the correct lwp from a proc.
> Neither seem nearly as good as passing the lwp pointer all the way
> through.

I think it's better to pass the lwp around.

> If someone wants to provide me with instructions on how to put the
> changes on a branch of the kernel, I think I'll do that with the
> patch file I applied on the weekend and then people can more easily
> see what was changed, how, what ripples up/down, etc, more easily
> than trying to read the patch file.  There may be some gratuitous
> curproc removal, as well, but I suspect not much.

Take care,

Bill