Date: Sat, 7 Aug 2021 10:52:47 -0400 From: James Y Knight <jyknight@...gle.com> To: musl@...ts.openwall.com Cc: Vincent Donnefort <vincent.donnefort@....com>, Samuel Holland <samuel@...lland.org>, jason <jason@...omnia247.nl> Subject: Re: [PATCH v3] sysconf: add _SC_NPROCESSORS_CONF support On Mon, Jul 12, 2021 at 1:15 PM Rich Felker <dalias@...c.org> 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. Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.