Subject: Re: LWP id into ktrace output - chapter 2.
To: Darren Reed <darrenr@reed.wattle.id.au>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 03/17/2003 11:07:53
On Mon, 17 Mar 2003, Darren Reed wrote:

> 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
> around 1.9MB.

Make it unified, -u. I found when I made the reference counting changes
way back when for ifnet's, that that shaved 30% off of a comparable class
of change.

> 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.

That probably sounds wise.

> 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.

At a first cut, I'd suggest cross-compiling it all. That way you at least
make sure it compiles... I'll try to help you do it, but I make no
promises about my time. Others should pitch in to help too, please!

> 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 ;)

Yeah, this'd be good. It also makes a lot of sense since the lwp is now
the scheduling primitive.

Take care,

Bill