Subject: Re: Some notes on ktrace lwp changes.
To: Darren Reed <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 07/02/2003 11:03:04
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
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.