Subject: LWP id into ktrace output - chapter 2.
To: None <firstname.lastname@example.org>
From: Darren Reed <email@example.com>
Date: 03/17/2003 22:51:01
Given Jason's comments on getting rid of LIST_FIRST(), I went back and
started work on making this a reality. This was a large amount of effort,
most of it relatively straight forward resulting in a context diff of
Why so big ?
Some of the changes required to get rid of LIST_FIRST() properly meant
that function headers for open/close/ioctl to device drivers had to
change to include a lwp pointer. Then there were the VOP_ and VFS_
macros that also needed to change and accompanying v*() routines and
their driver entry points, such as *_root(). This then meant touching
compat code as well. "ugh" some more - there was a lot of to'ing and
fro'ing as I worked out what had to have a 'struct lwp *' passed to it
and what I could get away with not changing. In some places I have
resorted to using proc_representative_lwp() where I'd prefer not to,
but the size of the changes I was making was getting too big and I
was getting tired of knocking down lead dominos.
The only changes I made that didn't work on first boot were to code
that fits in the bottom half of the NFS code, where I was assuming
the lwp pointer was non-NULL. Bad me. That's not to say I've tested
all the others (emulation, etc.)
Also, the changes I've made have been largely i386 specific, except
for the system call 'wrappings' for ktrace. This means, in their
current state, committing the patches as they exist will positively
break building for every other platform. I can reasonably handle
maybe doing sparc or sparc64 or even alpha but others I don't have
hardware or time or resources. What I'd like is for other developers
to think that this effort is a cool thing and that if they have the
time, they could help review my changes and/or help get it running
on other platforms. Again, the work required is generally mechanical
rather than thought intensive and yes, I could do some of it (I suppose)
but I can't test it.
I'd really like to get this done before the next release, as it should
not result in any significant change to performance or stability, except
for the occasional bottom half of a driver ;)
Well, I'd like to go further and nuke curlwp/curproc for the next
release too, but that might be just too ambitious at this stage.