Re: lib/52842: Obsolete brk(2)/sbrk(2)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR lib/52842; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: lib/52842: Obsolete brk(2)/sbrk(2)
Date: Wed, 20 Dec 2017 11:08:52 +0700

     Date:        Wed, 20 Dec 2017 01:15:01 +0000 (UTC)
     From:        coypu%sdf.org@localhost
     Message-ID:  <20171220011501.9EED17A1E6%mollari.NetBSD.org@localhost>
 
   |  How many allocators do we need?
 
 We only need one, but they tend to have different characteristics, and
 different ones can be suited better for different applications.
 
 As long as they all provide the same basic API, so they are technically
 interchangeable, what does it really matter?
 
 To the subject of this message, I personally would prefer brk(2) to
 remain (forever).   There's no really good reason to delete it, its
 effects can be faked, at some cost, by simply including
 
 	char bigarray[1<<30];
 
 or something similar in the sources (the cost being the need to preallocate
 space that may never up never being needed - using brk() means that the BSS
 will be made large only on demand.)
 
 I have no problem with use of mmap() to allocate memory, if that someone
 seems useful - though to me it seems like a rather heavyweight interface,
 for what can be a very simple request.
 
 No problem deleting ssys() (never knew such a thing was even planned), and
 as far as I can recall, way back to the very early days, sbrk() was always
 really sbrk(3) and used brk(2) from libc to operate, it never was and never
 needed to be a sys call (sure, making it one could save some libc ugliness,
 but not enough to worry about.)
 
 I vaguely remember some purpose (at least intended) for vadvise() but I
 don't remember it ever being implemented, so I have no problem with that
 one going away either.
 
 That is, all that was removed in the past couple of days was fine, but
 at least in this area, it should stop here, leave brk() for the benefit of
 (perhaps old and simple) malloc() implementations that some application
 might prefer to use.
 
 kre