> actually, doesn't kernel bcopy() not work for overlapping
> regions of memory, by design?  they are not exactly the same.

Depends what you mean by 'not work'....

I had a 'problem' scrolling a memory mapped screen on one system
(not netbsd).  Reading the uncached screen mamory was FAR too slow,
so I read from a cached alias and wrote to the uncached one (the
operation flushes itself from the cache quite nicely).  Now this
is a copy that has to be done in increasing memory addresses,
but the system memcpy (etc) routines all checked for overlapped
copies and, even though the areas didn't overlap, decided to
do this copy 'backwards' because the destination address was
lower than the source address.

The overlapped copy check is dangerous - because it can lead
to unexpeceted effects.  Very few copies actually overlap,
and, if they do, the writer normally knows whether a 'reverse'
copy is required.  Adding the check to all memory copies
will be a measurable performance penalty.

FWIW memmove() check for overlapped copies and memcpy()
should not (and would be expected to copy 'forwards').

	David

-- 
David Laight: david@l8s.co.uk