From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-10.9 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15085 invoked from network); 7 Aug 2021 14:53:30 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 7 Aug 2021 14:53:30 -0000 Received: (qmail 14142 invoked by uid 550); 7 Aug 2021 14:53:27 -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 14124 invoked from network); 7 Aug 2021 14:53:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FNnmv6tIOjjFqRfSH+E9tc6EK1Jdrq3D9dTKG0GIN4E=; b=TGOS/6XDEv2t1t4qCpwuoSYEeUz7D969ipq/+CIPtsA7nrARe2MIjd+y8pd9IDKmiN yMqteTiIZ0Ch/hfzDkhuY6/rnUQyrlqECFWH99YU304IlRt/6p9rkfSgJfCkbhQeRgtS 4MChd1yO8M+nSkqIp6jtKEyXy8/yBjY7SWV7mmYzJXyi6SlEVUnSJ5+an3MEdIXxG0hY 9Emksm9AEvd3OhOaJ2N9nv8CTs1aNmaLm4NDXdwxrpS93egs2Ak0Bvxso4d5wmDPthWs PsMC+LHmvTa138wkizE0oP7Lr5G+mD9TfPzaKUToP4RdXI4ta2F33L6QBch6gGFoqXZy FaUA== 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=FNnmv6tIOjjFqRfSH+E9tc6EK1Jdrq3D9dTKG0GIN4E=; b=PNSNutWHPK6M4Dnn2lrBUTYWOzvrRG7oRzriYN/VrPcZbLpWxvU3pOIR95Bvvc+3te uMs5E0sZhd3VQsRul9YGhQYN0hRkq5nuX8MWciCZSiLpz0K7lwRvZwAteNmcWrdMeEnI TakyQFhZZWVo/jTWA4sPDMIWPHCX1102uMuRGNDmiwmjSGKyYgI+AdHzppyBlBoiP3uw plXkNUiz0y7ylTMnO4qD623p/h4ac9wLD02l8pDCTfvj1Em4evIXKTDXm9eJHQvcMDFq exSSrVwvVa6VCmuxx4oAxQcbdpDyvu1wgmdLVr9TxYkehMIQ+OM74PmphIUI8sJriEjs Zerg== X-Gm-Message-State: AOAM530r7nMZrwSHpRWG/BZJiNQvT7pLuyEEgeGKihURyZ6gyz75a5Hs hVNfc11udADyVk2O36BsTJZOzaVXeX04OVwdPQvRlQm2TSEhgA== X-Google-Smtp-Source: ABdhPJyOiEyph7jnxmOl039aQGQutjQg4zT/W1oXA72zrwhuBcpdk5lM5ErJA3T2tfIcE2XRaSdcpsZDo1CvzUk/l9U= X-Received: by 2002:a19:7017:: with SMTP id h23mr11977472lfc.532.1628347994751; Sat, 07 Aug 2021 07:53:14 -0700 (PDT) MIME-Version: 1.0 References: <20210710053157.4F16D22215EC@gateway02.insomnia247.nl> <20210710194450.GX13220@brightrain.aerifal.cx> <20210712130840.GA47550@e120877-lin.cambridge.arm.com> <20210712154134.GY13220@brightrain.aerifal.cx> <20210712163246.GA115682@e124901.cambridge.arm.com> <20210712171454.GZ13220@brightrain.aerifal.cx> In-Reply-To: <20210712171454.GZ13220@brightrain.aerifal.cx> From: James Y Knight Date: Sat, 7 Aug 2021 10:52:47 -0400 Message-ID: To: musl@lists.openwall.com Cc: Vincent Donnefort , Samuel Holland , jason Content-Type: multipart/alternative; boundary="000000000000ccf4c905c8f94fa1" Subject: Re: [musl] [PATCH v3] sysconf: add _SC_NPROCESSORS_CONF support --000000000000ccf4c905c8f94fa1 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 12, 2021 at 1:15 PM Rich Felker wrote: > It's not just a matter of age and de facto stability. Kernel policy is > that the procfs files are stable interfaces. Despite being "human > readable", they're also intended to be readable by, and actually read > by, utilities such as the procps suite of tools, "top"-type programs, > etc. > I agree the format isn't going to change. However, I'd be extremely wary of using the emergent property that /proc/softirqs contains an entry for every "possible" CPU on the system. Yes, linux has a no regressions policy, but that only applies if someone notices. So, when someone's making some future refactoring in the kernel, maybe that happens to modify /proc/softirqs to only emit data for online CPUs. The /proc/interrupts file already reports only online-cpus, and it seems a bit of a weird inconsistency that softirqs iterates the possible-cpus set. Since this file is a _very_ strange source from which to determine the set of possible CPU ids, I wouldn't be surprised if code review did not notice that the change would cause a userspace regression. So it probably makes it into a stable kernel release. And, sure, eventually someone may indeed notice that the change subtly broke musl's sysconf implementation, and report that. At which point the change would definitely be reverted. (And a series of annoyed "WTF did you people use _that_ to figure out the possible CPUs??? Userspace developers are crazy." emails would ensue). But, that's just a lot of pain to go through, for, it seems to me, not a whole lot of benefit. I think it'll just be better to use the kernel interface which was actually designed to report this data. And the proposed patch falls back to using sched_getaffinity if sysfs doesn't exist, which -- while incorrect -- is likely to suffice in practice for those users that fail to mount sysfs. --000000000000ccf4c905c8f94fa1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 12, 2021 at 1:15 PM Rich Felk= er <dalias@libc.org> wrote:
It's not just a matter of age and de facto stability. Kernel policy is<= br> that the procfs files are stable interfaces. Despite being "human
readable", they're also intended to be readable by, and actually r= ead
by, utilities such as the procps suite of tools, "top"-type progr= ams,
etc.

I agree the format isn't going= to change.=C2=A0 However, I'd be extremely wary of using the emergent = property that /proc/softirqs contains an entry for every "possible&quo= t; CPU on the system. Yes, linux has a no regressions policy, but that only= applies if someone notices.=C2=A0

So, when someon= e's making some future refactoring in the kernel, maybe that=C2=A0happe= ns to modify /proc/softirqs to only emit data for online CPUs. The /proc/in= terrupts file already reports only online-cpus, and it seems a bit of a wei= rd inconsistency that softirqs iterates the possible-cpus set. Since this f= ile is a _very_ strange source from which to determine the set of possible = CPU ids, I wouldn't be surprised if code review did not notice that the= change would=C2=A0cause a userspace regression. So it probably makes it in= to a stable kernel release.

And, sure, eventually = someone may indeed notice that the change subtly broke musl's sysconf i= mplementation, and report that. At which point the change would definitely = be reverted.=C2=A0(And a series of annoyed "WTF did you people use _th= at_ to figure out the possible CPUs??? Userspace developers are crazy."= ; emails would ensue). But, that's just a lot of pain to go through,=C2= =A0for, it seems to me,=C2=A0not a whole lot of benefit.

=
I think it'll just be better to use the kernel interface whi= ch was actually designed to report this data. And the proposed patch falls = back to using sched_getaffinity if sysfs doesn't exist,=C2=A0which -- w= hile incorrect -- is likely to suffice in practice for those users that=C2= =A0fail to mount sysfs.

--000000000000ccf4c905c8f94fa1--