> From: amiettin@trshp.trs.ntc.nokia.com
> Date: Fri, 17 Nov 95 10:12:11 +0200

> >Don't forget "rd" too! (src/sys/dev/ramdisk.c)
> 
> This brings to my mind a question..
> 
> I have been wondering how the loading of executables from mfs is
> handled? Or how about executables on a ramdisk? Will the text sections
> be copied to a new RAM location or will they be just mapped?

I've thought about this too.  Currently, our VM/FS interface can
only copy data from the FS into VM pages.  Therefore, with either
ramdisk or mfs, your data exist two places in memory.  (However,
mfs and ramdisk with "user-mode-server" config store the data in
paged virtual memory owned by the server process.)

If the VM/FS interface were redesigned, then each filesystem type
could control what paging services were used with its vnodes, and
then something like mfs could provide "special" pager functions
that remap pages instead of copying them.

There are other advantages to having the pager routines defined
by the FS module:  For example, NFS would like to refresh the
attributes of its underlying file-handle when pages of such
vnodes become re-activated.  Without some mechanism for NFS to
find out about page activations, the VM system might reactive
NFS pages that are WAY out of sync. with the server.  (This is
an existing problem with NetBSD, right?)

Doing this redesign of the VM/FS interface is a big job.  I've been
studying some existing VM systems (i.e. SunOS, SysVr4.2MP, Mach),
and I'm preparing to write a design proposal for NetBSD based on
this study.  I'll send it here first so it can get some review
by a (hopefully) sympathetic audience before real publication.
(Not sure how to get "real" publication though, but no need to
worry about that for a while...)

Gordon Ross