On Wed, 7 Feb 1996 17:57:13 -0500 (EST) 
 kpneal@eos.ncsu.edu wrote:

 > > > Seems to me we should get something, anything, in to fix this, even if
 > > > it's a scavenger that's run once a minute to find these extra shadow
 > > > objects and nuke them.
 > > 
 > > Uhm, I think this is a serious problem which should be fixed ASAP.
 > 
 > But it's a big problem.

Yup.  And someone qualified to hack on the VM code should be the one to 
fix it.  If some qualified person wants to step forward to do it, by all 
means, please do.

 > > > But then, given how core has been resisting bounce buffers in the i386
 > > > port, we may have to either live with (yet another) brokenness in the
 > > > VM subsystem or keep private patches for it.  Not that private patches

I don't think that's a fair or even accurate statement.  Firstly, not 
every person in core is an i386 user; they may not have any experience 
with some of the problems being described.  Secondly, if it's an 
i386-specific fix, it's the job of the i386 port-master.  Thirdly, it 
*shouldn't* be an i386-specific fix, but rather something that will work 
equally well on the i386 and alpha, and scale well to future ISA ports.  
Gicen that, it should be the i386 and alpha port-masters that hash out 
the details of a bounce-buffer implementation.  Sure, the current ISA 
code is a bit from being MI, but it's *going* to be MI one day, and we 
should do everything possible to make that easier.

Regarding the VM brokenness, see above.

 > > Hmm, why doesn't core want problems to be solved?  What is their goal?
 > > To give us lots of bells and whistles while some of the basic functions
 > > of the OS are severely broken?

On the contrary, we *do* want problems to be solved!  Our goal is to 
provide a stable, freely-redistributble system for use by hobbyists, 
researchers, and professoinals alike.  We try very hard to make sure that 
things work properly.  In fact, it's been mentioned here before that 
we're :"behind" on bells and whistles.  This is largely because we try to 
take a conservative approach and get a good feel for how it fits into the 
system as a whole.  I think that the quality of the overall system 
improves when this approach is taken.

Also, some of these problems are just hard to fix.  Not everyone's an 
expert in everything (I know very few people who are...)  Personally, I'd 
love to fix the VM system, but I know that I'd only make it worse :-)

 > Because it seems the attitude on the mailing lists is of people looking
 > for the magic bullet. The "perfect" solution. Until that is found,
 > nothing will happen. Many people won't write code for a problem until
 > the mailing lists tend to agree on the solution, and if there is a
 > big debate and nobody sees a perfect solution, nothing happens.

Again, not true.  My original disk stats work wasn't a perfect solution 
at first (and it's probably still not :-), but the design evolved as the 
discussion took place.  Something happened.  I think the story's the same 
in many cases.  Just because someone isn't making noise about it, doesn't 
mean that nothing is happening.

 > FreeBSD has a solution to the VM system problem. But they don't have
 > a "perfect" solution, so there is no big movement to move their code
 > over to here.

What do you consider a "big movement"?  10 people quitting their day 
jobs, giving up being with their family/friends/SOs in their spare time?

Someone is working on porting FreeBSD's VM.  but, again, he's a volunteer 
who doesn it in his spare time, and isn't making a lot of noise about it.

Overall, I think statements like these only really serve to make people 
defensive.  I know how hard I work on NetBSD, and I know how hard others 
work, too.  I'm not trying to downplay your concerns or frustrations, but 
please understand that statements like "nothing happens" and "no big 
movement" and "core doesn't want problems solved" can be really 
frustating at times ... sometimes more than a slightly broken VM subsystem.

--------------------------------------------------------------------------
Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939