From owner-freebsd-current@FreeBSD.ORG Wed Apr 25 16:39:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from lo0.su (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by hub.freebsd.org (Postfix) with ESMTP id C73D2106564A; Wed, 25 Apr 2012 16:39:50 +0000 (UTC) (envelope-from ru@FreeBSD.org) Date: Wed, 25 Apr 2012 20:39:49 +0400 From: Ruslan Ermilov To: Jason Evans Message-ID: <20120425163949.GA53937@lo0.su> References: <7FC153A1-8815-4BAE-AB94-FED51DBFFEAA@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7FC153A1-8815-4BAE-AB94-FED51DBFFEAA@freebsd.org> 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 16:39:51 -0000 On Tue, Apr 17, 2012 at 12:34:20PM -0700, Jason Evans wrote: > As a result of the recent jemalloc update, the format for > /etc/malloc.conf has changed. If your system has an old-style > /etc/malloc.conf, you will want to delete it prior to > installworld, and optionally re-create it using the new format > after rebooting. See malloc.conf(5) for details (specifically > the TUNING section and the "opt.*" entries in the MALLCTL > NAMESPACE section). > > The MALLOC_OPTIONS environment variable and the _malloc_options > global do not pose the same headache, because their new > counterparts are named MALLOC_CONF and malloc_conf, > respectively. 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. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer