From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 30923 invoked from network); 15 Apr 2020 09:39:08 -0000 Received-SPF: pass (mother.openwall.net: domain of lists.openwall.com designates 195.42.179.200 as permitted sender) receiver=inbox.vuxu.org; client-ip=195.42.179.200 envelope-from= Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 15 Apr 2020 09:39:08 -0000 Received: (qmail 1173 invoked by uid 550); 15 Apr 2020 09:39:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1155 invoked from network); 15 Apr 2020 09:39:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XjfBD98tFn00h4WTj4el9aZIJk+wif/IbY1sfWeeItQ=; b=udQkfkdVq97UUMKBp0ueC9LFyJuzA7uoQosxyTxSy879dx31iFwF5egx0xydGMy2ea VyppoVjPvx8zQZ3VkvlpS/XfMPPqhWbYRCUz3BdL73xWqVPtVr+yUaPn/F5wYuUYGIUO D1hHKgxJwYYUkwSLHX5CRHiJVIle2+fHOG/eXrfFkPu046P6Cb0qzAkQ5hCzSk72kQ6i 9f9JNSQApDl28F12ZrNSluvPrV14dtxXWDQZtqI5LFDYbbJvdsCqdWolnOqG7ykq7LwQ ms5fhzFErLHWWf+GYXDpK6Ilj8WDLIybA4n7p1kvn4eIAfp2xwmcUHU6ofMcNtmDitXo OElA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XjfBD98tFn00h4WTj4el9aZIJk+wif/IbY1sfWeeItQ=; b=Mg++hk/p/wrTLvL1EUkEQXC1n9yEw6WxTSlh5yOH5x/MwZXt5hSB/G0o3q9s2WQ5C7 zgeW0UsO5NgGUn+aYL0VvrnQFnQGXis0ITSn3CYLNUad3QfmZg6cPKIXRNEGKYp1SSSP 9zJDjN6u3GwVg417e0wkYfapNKoL3agSIW+9UesQbquCsrpTKGSO09X9WtuAgQjY8H/Y K17ffj7LrX7dJOBYfEZzUMTMxhrMyO3rlKRM1XAzWAr/JhYepcL2SC4vZ+gyss5ShwUj ILEFGbg770SqewXbbjZSNj75mTCkUo4DxAP1bHBsShbHmROa7jg+EHMpP2J3llh1+Ndx lSJA== X-Gm-Message-State: AGi0Puby7E9UsZCD3PTvFvz18vkguumDEHKBkMohChU+ielb8Vpt2qgH DJj0NBWcgPZuJn9ceELb2DpDJNtgM1IwW4zz/UU= X-Google-Smtp-Source: APiQypJiDmOKwpjtiDs779rqStACbbsvNR3nYRbWGt/v10YNMb7zHjD1qpMxpMOs2g+3xzWHr72sohnSTWuFMm1w1H0= X-Received: by 2002:a05:6e02:886:: with SMTP id z6mr4695984ils.79.1586943533636; Wed, 15 Apr 2020 02:38:53 -0700 (PDT) MIME-Version: 1.0 References: <20200409181824.GD13749@port70.net> <87r1wwik8t.fsf@mid.deneb.enyo.de> <20200410010255.GN11469@brightrain.aerifal.cx> <877dyinzuz.fsf@mid.deneb.enyo.de> <20200414155522.GB11469@brightrain.aerifal.cx> <87wo6iknx1.fsf@mid.deneb.enyo.de> In-Reply-To: <87wo6iknx1.fsf@mid.deneb.enyo.de> From: Norbert Lange Date: Wed, 15 Apr 2020 11:38:42 +0200 Message-ID: To: Florian Weimer Cc: Rich Felker , musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] [BUG] sysconf implementing _SC_NPROCESSORS_(CONF|ONLN) incorrectly How should one deal with this? I understand that the semantics are vague, but given that musl now implements this function, it will make detection and fallback hard (especially as musl doesn't wants to be identified by the likes of macros). As it is now, just using the affinity mask definitely cant be useful, an application wanting that behavior should be patched to use that function directly. If musl would not define the _SC_NPROCESSORS_* macros (but still keep the implementation), this could be used for compile-time detection atleast. Enabling the current implementation would be just a matter of explicitly defining those macros. Norbert Am Di., 14. Apr. 2020 um 18:55 Uhr schrieb Florian Weimer : > > * Rich Felker: > > > On Tue, Apr 14, 2020 at 12:08:52PM +0200, Florian Weimer wrote: > >> * Rich Felker: > >> > >> >> For glibc, we had to change our logic to artificially inflate the CPU > >> >> to 2 if we cannot determine it, as the more conservative choice. > >> > > >> > Wait, you mean some software is abusing these interfaces to omit > >> > memory barriers or something? *facepalm* *sigh* > >> > >> Yes, indeed. glibc itself parses uname -v output for this purpose > >> (something we should probably remove, too). > > > > I don't understand. Certainly it's not executing a child process at > > runtime. Do you mean SYS_uname or are you talking about guessing > > number of cpus for parallel build at make time or something? > > I meant the string that is printed by uname -v. The internal > implementation is of course different.