> Well, first of all, you absolutely want to put an upper bound on
> the size of the MFS.

yes.


> Secondly, this is more of an implementation issue than a design issue,
> and it's not clear that making MFS give memory back would really be
> all that hard.

piffle.  the way MFS is "designed" makes its implementation
necessarily "some file normal file system in RAM."  The problem is,
unless you design from the ground up with understanding that RAM is
your target, you _will_ make stupid and slow assumptions about how the
data should be spread out, how the control structures should look, etc.


> The way I understand MFS is that it allocates memory as necessary, i.e.
> getting faults on the pages, and then demand-filling them.  This
> would imply to me that, when an MFS block has been freed, its
> corresponding page can be given back to the system, for collection
> by the page daemon.
> 
> Am I missing something here?

Yes, quite a lot.  Quite frankly, you haven't a clue as to how MFS
works.  In a nutshell:

MFS works by having a program, mount_mfs, allocate a Really Big Chunk
of memory.  That process, and its memory space, sticks around for the
entire time that MFS is.  MFS reads and writes data via copyin from
and copyout to the process's address space.  (I'm sure it _could_ be
made more inefficient, but i'm not going to try...  8-)

There is no notion of freeing blocks in MFS.  It can't be added
easily, since what does it mean to free a block in a process's address
space when it's 'unused'?  You'd have to do something like automatic
GC of zero blocks, or something, and that sounds ... bad.

Note also that MFS has hooks for being used as a miniroot already
built in... (the ramdisk miniroot stuff may not be quite so
necessary...)

cgd