Chris Demtriou wites:

| Yes it is.  In fact, it's bloody stupid.
| 
| Why give random users using somebody else's box a ready-made
| perormance killer?

>However, I agree; the utility of this kind of tool is
>limited to, maybe, "do a memory check", and more likely,
>"run this program to see some VM bugs", or even, "run this
>program to simulate EMACS making a computer slow".   
>I doubt the last two things are very useful at this point, 
>and I'm sure that reaching out and dirtying lots of VM pages 
>certainly isn't a good way to check physical memory...

I thought this (admittedly stupid) piece of code would be useful for
two things: first, regression testing of the VM system, if and when it
gets fixed; and as a memory-tester-of-last resort.  More than one
person in the last three months has reported strange NetBSD
misbehaviour which turned out to be due to otherwise undiagnosed SIMM
errors.  Some NetBSD platforms have neither ECC nor a good boot-PROM
memory exerciser.

Yes, doing a memory tester in userspace is a dumb idea: it should
be somewhere where it can test physical memory pages, instead of
touching ``enough'' virtual pages to hope to catch bad bits. (Though
I've found it does well at that eventually:))

Note that building a memory tester into the kernel was also derided,
and we don't have a suitable standalone environment on all ports.  I'm
not sure what else is left.  Other operating systems (including DOS)
are not an  option for all installations.

Of course, even if we ship such a utility, there's no need for it
to be executable by anyone other than root. 

Chris, if a port doesn't have a standalone environment and an
in-memory tester is also objectionable, how would *you* implement a
memory tester, for those platforms where PROMs give false-positive
tests on bad memory?