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.

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?

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.

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.

Cheers,
Darren