On Mon, Jul 12, 2021 at 1:15 PM Rich Felker <dalias@libc.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.