Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Apr 2012 10:43:59 -0700
From:      Jason Evans <jasone@freebsd.org>
To:        Ruslan Ermilov <ru@FreeBSD.org>
Cc:        freebsd-current@freebsd.org
Subject:   Re: HEADSUP: /etc/malloc.conf format change
Message-ID:  <0D8D93F3-5919-4A48-9BB2-887E4420C162@freebsd.org>
In-Reply-To: <20120425163949.GA53937@lo0.su>
References:  <7FC153A1-8815-4BAE-AB94-FED51DBFFEAA@freebsd.org> <20120425163949.GA53937@lo0.su>

next in thread | previous in thread | raw e-mail | index | archive | help
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.
>=20
> While removing part of the documented API was definitely a bad
> idea, you didn't provide any mean to detect this change=20
> programmatically, neither through a macro test, nor by bumping
> __FreeBSD_version.  The only way now is to try and see if it
> compiles, which is far from perfect.
>=20
> The way how _malloc_options is handled for binary compatibility,
> by simply ignoring its value, is (ahem) questionable.
>=20
> Why do I care?  The developers of the nginx web server have=20
> been notified today that it could not be built on FreeBSD
> 10.0-CURRENT anymore, due to this change, when compiled with=20
> "nginx malloc debugging".  It's activated by the DEBUG option
> of the www/nginx-devel port, if you care to try it out.
>=20
> Please explore the possibility to add backwards compatiblity for=20
> the documented API, or at the very least provide a mean to=20
> 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.

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.

Thanks,
Jason=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0D8D93F3-5919-4A48-9BB2-887E4420C162>