> 
> In the process I ported "ofiles" to NetBSD.  Well, what I thought
> would be a 5 minute compile turned into a 2 day job (and, no doubt,
> someone's already done this).
There's fstat which comes with the system.
> 
> (and what a eye-opener that was!  I would have thought the proc's maps
> would be a shadow of a "master" map which pages to the file - it
> appears I've got this backward - the file pager appears on a shadow of
> the proc's vm object; are their mach papers which describe the
> relationship between exec & vm objects? just curious)
> 
Do not mix up maps and vm objects; they are different things. Maps describe
chunks of virtual address space. Each such chunk can have a VM object
associated with it which handles things like copy-on-write. A VM object in
turn can rely on a pager to store/retrieve the actual bits that it is supposed
to manage.

VM objects can utilize a common store of (background) data, using the `shadow'
(and `copy') pointers. Eg. after a fork, the child process ends up referring
to its parent's address space by "cloning" VM objects that "shadow" the parent's
objects. On a page fault, the VM system follows the shadow chain to lay its
hands on the actual data repository (eg. a pager) to load the bits into a
physical memory page.

-pk

------------------------------------------------------------------------------