From owner-freebsd-current@FreeBSD.ORG Wed Apr 25 17:44:07 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E854D106566C; Wed, 25 Apr 2012 17:44:07 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from canonware.com (10140.x.rootbsd.net [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id C5F8A8FC0C; Wed, 25 Apr 2012 17:44:07 +0000 (UTC) Received: from [172.25.16.174] (unknown [173.252.71.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id E5E5A28418; Wed, 25 Apr 2012 10:44:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jason Evans In-Reply-To: <20120425163949.GA53937@lo0.su> Date: Wed, 25 Apr 2012 10:43:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0D8D93F3-5919-4A48-9BB2-887E4420C162@freebsd.org> References: <7FC153A1-8815-4BAE-AB94-FED51DBFFEAA@freebsd.org> <20120425163949.GA53937@lo0.su> To: Ruslan Ermilov X-Mailer: Apple Mail (2.1257) Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: /etc/malloc.conf format change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 17:44:08 -0000 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=