Add Linux compatibility support for `SC_NPROCESSORS_{CONF,ONLN}` as `_SC_NPROCESSORS_{CONF,ONLN}`

[ngie]

Summary

The goal of this change is to make it easier to use getconf to query
the number of available processors.

Sadly it's unclear per POSIX, which form (with a preceding _ or
lacking it) is correct. I will bring this up on the Austin Group list so
this point is clarified for implementors that might rely on this getconf
variable.

This is something I noticed when trying to import GoogleTest to FreeBSD
as one of the CI scripts uses this variable on Linux.

Test Plan

Setup:

$ make obj
$ make
$ cd $(make -V.OBJDIR)

• Old form:

$ ./getconf _NPROCESSORS_ONLN
4

• New (Linux compatible) form:

$ ./getconf NPROCESSORS_ONLN
4

[ngie]

@emaste, @jilles, @jtl: ping?

[emaste]

Did you bring it up on the Austin Group list?

I'm also unclear about this change - you add the _ form, but the non-_ form is Linux compatible and already exists? Or is the comment above backwards?

[ngie]

In D18640#401431, @emaste wrote:

Did you bring it up on the Austin Group list?

I'm also unclear about this change - you add the _ form, but the non-_ form is Linux compatible and already exists? Or is the comment above backwards?

FreeBSD supports SC_NPROCESSORS_CONF/SC_NPROCESSORS_ONLN (no leading underscore) prior to this change and Linux supports _SC_NPROCESSORS_CONF/_SC_NPROCESSORS_ONLN (leading underscore). Not having the latter form (for Linux) makes it trivially more difficult when porting software to FreeBSD today in bourne shell scripts.

I'm adding code to support the Linux way to remove that minor barrier, so people will be able to port to FreeBSD for free when using the right idiom on Linux.

The comment about the Austin Group list was to cause the committee to officially comment on (and make a decision) as to whether or not FreeBSD/Linux needs to support SC_NPROCESSORS_CONF or _SC_NPROCESSORS_CONF, etc.

[ngie]

@emaste: you're right though -- the summary was flip-flopped by accident :). Fixed!

[emaste]

the summary was flip-flopped by accident

Ah, makes sense now.

As for Austin Group I was just wondering if you brought it up there already (and if there's any response from them).

[ngie]

In D18640#401491, @emaste wrote:

As for Austin Group I was just wondering if you brought it up there already (and if there's any response from them).

I haven't yet. I will be starting that conversation this week/next week.

[jtl]

Regardless of what the group says, it seems like we'll probably want to support both for a transitional period. Given that, this change seems OK. @emaste , do you agree?

[emaste]

Agreed