From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58104 invoked by alias); 17 Oct 2016 19:40:38 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 57996 invoked by uid 89); 17 Oct 2016 19:40:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.2 spammy=Hx-languages-length:2519, notion, implications, risk X-HELO: mail-qk0-f179.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=o8FDJtmUQXfQ84DjKfim8McxjDq71xdJVgUpykMovGo=; b=UcjlE3On131HJdBwmu8T4a8bnf9l1YZoPwhurbEtQMkarWNoRnkRNOm53U/bEL/ng4 BfBOM5kcyhxiQXj50c2R7GyZVH4cEcygwKiHYpMkTIUiV64mEuYQs2xrc2yuG0MXy1ap rU/6wYLFDS7V0E76PeiuigFDbqfIYMLlxO4tVhDcXSkpYmlij77ccrODNUwPOltHDCCJ iAQMbtz0CsG+U9Uc7swACbeEzeouElQ3JMN6aMzLNNKJ5PGcmJDkb1bgVTcJtzciG+v0 nBmgBgEYUFpUalx+c530/gMLoVDcLmqrDiyJazxlhZRW3s3UDE99lAzcV8++c2xSb3QA U+0A== X-Gm-Message-State: AA6/9RkSxNQfUVce8WuhctQb7GX9esB4O4GRHzBykJLUb//4/OWyClIFQI/HNNDK2Pppe9KV X-Received: by 10.55.105.130 with SMTP id e124mr24366740qkc.101.1476733224659; Mon, 17 Oct 2016 12:40:24 -0700 (PDT) Subject: Re: [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables To: Michael Kerrisk , DJ Delorie References: <1476120388-26662-1-git-send-email-siddhesh@sourceware.org> Cc: Siddhesh Poyarekar , libc-alpha From: Carlos O'Donell Message-ID: Date: Mon, 17 Oct 2016 19:40:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00273.txt.bz2 On 10/11/2016 02:20 AM, Michael Kerrisk wrote: > On Mon, Oct 10, 2016 at 7:33 PM, DJ Delorie wrote: >> >> These variables all end with "_", most likely the original intention is >> that they are not official and may be removed or changed at any time. >> >> By making them official, we lock in that ABI. Is that your intention? > > I think the notion that because one does not document something, it's > not an official part of the ABI is at best highly dubious. Especially > when so many "official" parts of the ABI are also not documented. > > The only way that documentation might be able to help in such > situations is where pieces are clearly and loudly documented right > from the beginning, in the official documentation, as "not supported, > may disappear at any moment in the future, use at your own risk", but > even then people are likely to ignore the documentation or be unaware > of it. > > And in any case, these environment vars have long been documented in > various "unofficial" places including (since 2012) > http://man7.org/linux/man-pages/man3/mallopt.3.html The things that DJ is worried about are the arena ones e.g. M_ARENA_MAX, and M_ARENA_TEST and their env vars. In 2013 I brought up the discussion about ABI implications: https://sourceware.org/ml/libc-alpha/2013-03/msg00376.html Only Siddhesh and I commented, and we both agreed it was a forgone conclusion that these were stable parts of the ABI/API. In 2015 I documented them in the linux man pages project: https://www.sourceware.org/ml/libc-alpha/2015-08/msg00991.html ~~~ Consensus among Siddhesh and myself was that they should be public, and in fact they were already in the public header. Therefore there may already be applications uses these constants and expecting them to work. At best we could limit mallopt's acceptance of the options, but that seems like a bad solution that could lead to unexpected behaviour for user applications. A quick google search shows that there are packages relying on these constants to tune the glibc malloc implementation. ~~~ They are part of the ABI and public, and should be documented in the manual as Siddhesh's patches do. We should however be very very circumspect about adding more of these mallopt tunables without first seeing that such tunables are stable and long-term useful as generic tunables (via the tunables interface). So go review Siddhesh's patches on tunables :-) -- Cheers, Carlos.