Date: Thu, 26 Apr 2012 11:56:14 +0400 From: Ruslan Ermilov <ru@freebsd.org> To: Jason Evans <jasone@freebsd.org> Cc: current@freebsd.org Subject: Re: HEADSUP: /etc/malloc.conf format change Message-ID: <20120426075614.GB51611@lo0.su> In-Reply-To: <0D8D93F3-5919-4A48-9BB2-887E4420C162@freebsd.org> References: <7FC153A1-8815-4BAE-AB94-FED51DBFFEAA@freebsd.org> <20120425163949.GA53937@lo0.su> <0D8D93F3-5919-4A48-9BB2-887E4420C162@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.org FreeBSD committer
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120426075614.GB51611>