From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14045 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: sysconf(_SC_NPROCESSORS_CONF) returns the wrong value Date: Tue, 2 Apr 2019 21:02:53 +0200 Message-ID: <20190402190253.GT26605@port70.net> References: <20190315210202.GD6994@joraj-alpa> <20190316022534.GN26605@port70.net> <20190326162334.GF17481@joraj-alpa> <20190326174540.GH26605@port70.net> <1391784430.9599.1553623268878.JavaMail.zimbra@efficios.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="71524"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: musl , Michael Jeanson , Richard Purdie , Jonathan Rajotte To: Mathieu Desnoyers Original-X-From: musl-return-14061-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 02 21:03:11 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hBOgg-000IR8-K2 for gllmg-musl@m.gmane.org; Tue, 02 Apr 2019 21:03:10 +0200 Original-Received: (qmail 3486 invoked by uid 550); 2 Apr 2019 19:03:08 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3457 invoked from network); 2 Apr 2019 19:03:07 -0000 Mail-Followup-To: Mathieu Desnoyers , musl , Michael Jeanson , Richard Purdie , Jonathan Rajotte Content-Disposition: inline In-Reply-To: <1391784430.9599.1553623268878.JavaMail.zimbra@efficios.com> Xref: news.gmane.org gmane.linux.lib.musl.general:14045 Archived-At: * Mathieu Desnoyers [2019-03-26 14:01:08 -0400]: > ----- On Mar 26, 2019, at 1:45 PM, Szabolcs Nagy nsz@port70.net wrote: > > i agree that the current behaviour is not ideal, but > > iterating over /sys/devices/system/cpu/cpu* may not > > be correct either.. based on current linux api docs. > > > > i don't understand why is that number different from the > > cpu set in /sys/devices/system/cpu/possible > > I suspect both iteration over /sys/devices/system/cpu/cpu* and > content of /sys/devices/system/cpu/possible should provide the > same result. However, looking at Linux > Documentation/ABI/testing/sysfs-devices-system-cpu , > it appears that /sys/devices/system/cpu/possible was introduced > in December 2008, whereas /sys/devices/system/cpu/cpu#/ was there > pre-git history. > > This could explain why glibc uses the iteration method. > > Thoughts ? as far as i can tell the cpu iteration method is valid, and that directory list cannot change after boot (is this guaranteed by the linux abi in the future?), so as long as /sys is mounted we can get the number, but it's fairly ugly.. does lttng have fallback code if sysconf returns -1? if it does maybe musl should just do that (or somebody has to write cancellation safe directory traversal code)