Re: HEADSUP: /etc/malloc.conf format change

On Wed, Apr 25, 2012 at 10:43:59AM -0700, Jason Evans wrote:
> On Apr 25, 2012, at 9:39 AM, Ruslan Ermilov wrote:
> > So you removed _malloc_options that was part of the documented
> > programming API, while some software made use of it.
[...]
> > Please explore the possibility to add backwards compatiblity for 
> > the documented API, or at the very least provide a mean to 
> > detect this otherwise disruptive and hard to detect change
> > for a programmer.
> 
> A __FreeBSD_version bump seems like a good idea to me, but
> adding backward compatibility for _malloc_options is
> questionable at best.  Of the 17 options that _malloc_options
> supported, only 6 have directly corresponding options in
> malloc_conf, plus another 3 that would present strange quirks
> (fragile and difficult to precisely document) if an attempt
> were made to provide compatibility.  In past iterations I was
> always careful to provide as much option compatibility as
> possible over the lifetime of each release (e.g., 'H' in
> RELENG_7), but individual options came and went  with major
> releases.
> 
> _malloc_options could only be pushed so far, and when it hit
> its breaking point I replaced it.  Creaky compatibility is IMO
> a liability rather than an asset.  In the case of nginx, it
> looks like a __FreeBSD_version bump is exactly what it needs.
> I'll try to get that done today.

Well, thanks for that, and for all your hard work with malloc().

> On a related note, is there any way to find all ports that
> refer to _malloc_options without extracting source for all of
> them?  I considered being proactive about finding software that
> depends on _malloc_options, but no tractable approaches came to
> mind.

That was already answered by Mark.


-- 
Ruslan Ermilov
ru_at_FreeBSD.org
FreeBSD committer