Subject: Some notes on ktrace lwp changes.
To: None <firstname.lastname@example.org>
From: Darren Reed <email@example.com>
Date: 07/02/2003 00:01:05
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
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.
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
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?
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
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.