> >No, nobody moves anybody else's memory blocks under NetBSD, so
> >basically any block is always "locked".
> 
> Danger, Will Robinson!!  Paradigm shift ahead!
> 
> The Mac is a single-user machine so there *never* *was* anyone else to mess
> with memory (unless you were in an interrupt routine, in which case messing
> with memory was prohibited).

Ur... I was talking by personifying programs...  Mac was a single-task
environment but it is now a multi-task one (albeit non-preemptive).
However, even when it was a single-task environment, the OS had the
liberty to move around the application's memory blocks to perform
compaction.  From the application's point of view, the OS is
definitely a "somebody else".  I was talking in that kind of context.

> Anyway, my point is that some care should be taken in reimplimenting the
> *Handle routines.  They would go to excessive lengths to avoid memory
> fragmentation and driver code that allocated space in a
> fragmentation-inducing order could possibly stop working, or at least waste
> a lot of space, if we don't implement all the "features."

Hmmm, don't worry too much.  We're not implementing a MacOS emulator.
Video drivers typically allocate a few blocks of memory when it is
opened, and none after that.

> >Under MacOS, okay.  But under NetBSD, since nobody moves any allocated
> >memory blocks, do you need it?  I think not.
> 
> See above.

Not much if at all of NetBSD kernel is written using double pointers
(or handles), let alone moveable memory blocks.  If the kernel
suddenly started moving allocated memory blocks around to compact and
defragment its memory, it would break way too many things.

> >Yeah, because MacOS moves blocks around?  Which isn't the case for
> >NetBSD...
> 
> Yet.

See above.

> I shouldn't overstate the problem.  We only have a few driver routines
> doing stuff, not the full System 7 Finder.  By all means try a simple
> approach to replacing the *Handle routines first, but keep an eye on memory
> use and fragmentation as possible sources of problems.

If we were to write a MacOS emulator, we would allocate memory for
handles in the *user* space, not in the kernel space, which would
isolate the existing NewHandle routine from the fragmentation problem
and the stuff (it's not gonna be called anyway!).

> If any developer wants a copy of the memory manager chapter from Inside Mac
> I, let me know.  (I think that would be covered by the Fair Use doctrine.)
> It's pretty fundamental to how the old Mac stuff worked.

Thanks, but another copy is being sent to me :-)

ken