On Thu, Feb 28, 2002 at 11:36:58AM -0500, Andrew Brown wrote:
> >>>> What about programs that dump themselves for later restart (like
> >>>> emacs, TeX etc.)?
> >>> Sendmail used to do that with its config file,
> >> Nonsense.  sendmail's fc file was a normal file, read/written like
> >> any other file, sendmail never did any undump nonsense.
> >
> >No, but what sendmail did was pretty close in many respects.  (The .fc
> >file was basically write(fd,&_etext,sbrk(0)-&_etext) - not dump/undump,
> >but definitely not a clean savefile format, and critically dependent on
> >the way the VM space was laid out.  The mmap-based malloc mentioned
> >upthread would have broken it instantly.)
> 
> why in the world are we arguing about something that sendmail hasn't
> done for years?  or...are you maintaining a really really old version
> somewhere?

Was just an example, there are loads of programs out there that
rely on features of old implementations that have been kept
'for compatibility'.

Does the netbsd malloc still support:
	x = malloc( 20 );
	free( x );
	x = realloc( x, 10 );

which is why it is called 'realloc'....

I don't actually see why there is a gain from using mmap() directly
for malloc()?  The program data area is (effectively) an extensible
area loaded from the program file (then zeros) that is written to
swap.  An mmap()ed piece of /dev/zeros will be exactly the same.
What you probably lose is address space fragmentation and memory
fragmentation...

	David

-- 
David Laight: david@l8s.co.uk