HEADSUP: /etc/malloc.conf format change
Jason Evans
jasone at freebsd.org
Wed Apr 25 17:44:08 UTC 2012
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.
>
> While removing part of the documented API was definitely a bad
> idea, you didn't provide any mean to detect this change
> 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.
>
> The way how _malloc_options is handled for binary compatibility,
> by simply ignoring its value, is (ahem) questionable.
>
> Why do I care? The developers of the nginx web server have
> been notified today that it could not be built on FreeBSD
> 10.0-CURRENT anymore, due to this change, when compiled with
> "nginx malloc debugging". It's activated by the DEBUG option
> of the www/nginx-devel port, if you care to try it out.
>
> 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.
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
More information about the freebsd-current
mailing list