Folks,

I was looking at a change to mount_mfs that would result in a libc
routine calling malloc (a call to getpwnam), and it turns out there's an
"interesting" implementation of malloc in mkfs.c that doesn't work too
well in the general case.

The _ugly_ part is trying to figure out how much data memory is
available so that it can create as large a filesystem as possible
without busting the data limit.  The current scheme simply does not
work.  If effectively uses

        data_rlimit_max - sbrk(0)

to determine the amount of free data memory.  If the text segment
doesn't start anywhere near 0 (eg, alpha, i386 elf) this this heuristic
is just plain wrong - on an alpha, it thinks that there's -3759528288
bytes free.  One idea is to use something like

	data_rlimit_max - (sbrk(0) - &etext)

This is still nowhere near perfect, but I can't think of a better method
of working out how much data memory is available.  Other options are to
use the kern.proc sysctl to find out how many data pages are used by the
current process, or to do a binary search using sbrk to find the maximum
size.

A second option, suggested by Charles Hannum, is to just error if the
requested file system is too large.  The more I think about this, the
more I'm inclined to go in that direction...

Any thoughts?

Simon.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD Sales, Support and Service:  http://www.wasabisystems.com/