I have completed (locally), part 1 of getting ktrace to return LWP ids
into ktrace information: stuffing the lwpid into ktr_buf.  I don't plan
to stop here, but just getting this far has taken a lot of changes.
Why so many changes ?  There's a ktrace record type for namei() lookups
and wherever a path name needs to be used (Unix domain sockets, file
access, etc), there's a namei() call that eventually happens and that
now needs a 'struct lwp *' so it can hand it off to the ktrace hook.
Similarly, because of interface changes required to pass 'struct lwp *',
it will seem like it is being passed when 'struct proc *' could still
have been passed.  I assure you I haven't made more changes than were
necessary.

In some places, I decided to cut out a bunch of similar work (that is
converting from passing 'struct proc *' to 'struct lwp *') by using
LIST_FIRST(&p->p_lwps) to get the lwp id.  That's cheating, I know,
but I didn't really want to change all the ioctl handlers, too, with
the first patch for this.

No changes to ktrace(1) have been made, no ktruss(1) (yet).
I added -L to kdump to show LWP id's as pid/lwpid.

If anyone wants to review the patches, you can find them at:

http://coombs.anu.edu.au/~avalon/ktrace-lwp.diffs

Oh, just to finish off, I notice that neither pc532 nor sh5 kernels
could currently compile as they're without lwp support.  I hope I've
not broken any MD stuff on non-i386 platforms as I've only tried to
compile the kernel on i386. I did, however, go looking for places where
the system call (& return value) hooks for ktrace were and fixed those
for as many platforms as I could.

Oh, next phase will be to get rid of all LIST_FIRST()'s to get a
'struct lwp *'.  Once I start that ball rolling, I may well not stop
until I've done as much elimination of passing 'struct proc *' as
is makes reasonable sense O:-)

Anyway, if there are no emails saying "stop, you bloody idiot, you're
going to bring the house down" in the next day or so, I'll assume the
patches are fine and commit.

Darren