gh-81925: Implement the native thread ids for KFreeBSD

[sthibaul]

• Issue: thread native id support for GNU/Hurd #81925

[pitrou]

Thanks for the update. Can you also update the docs here and here? The updated markup could be something like:

   .. availability:: Windows, FreeBSD, Linux, macOS, OpenBSD, NetBSD, AIX, DragonFlyBSD, GNU/kFreeBSD.

   .. versionadded:: 3.8

   .. versionchanged:: 3.13
      Added support for GNU/kFreeBSD.

[sthibaul]

Thanks for the update. Can you also update the docs here and here? The updated markup could be something like:

Done so!

[pitrou]

@encukou Does this seem ok to you?

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @pitrou for commit b74f76e 🤖

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

[encukou]

The code change looks OK to me, but I would not change the docs -- the mentions suggest that we'll keep GNU/kFreeBSD support working, which we currently can't promise as we (AFAIK) don't have a stable buildbot for it.

[encukou]

(Sorry, @sthibaul, for maintainers disagreeing with each other with you caught in the cross-fire. Don't change stuff until we agree what to do.)

[pitrou]

The code change looks OK to me, but I would not change the docs -- the mentions suggest that we'll keep GNU/kFreeBSD support working, which we currently can't promise as we (AFAIK) don't have a stable buildbot for it.

We're not promising anything even on other platforms, AFAICT. The tests for native_id / get_native_id don't check for specific platforms, so the feature could quietly be disabled on supposedly-supported platforms.

[pitrou]

The buildbot failures are unrelated, so I'll merge.

[malemburg]

Just saw this on the checkins ML and curious: why are we adding support for an officially terminated variant of Debian ?

[pitrou]

Oh, I was not aware of that. Given that support here requires minimal code and doesn't affect the rest of the (non-kFreeBSD-specific) code, I thought the PR was fine.

@sthibaul Is kFreeBSD actually unmaintained, or is it just maintained outside of Debian?

Also cc @gpshead for opinions.

[sthibaul]

GNU/kFreeBSD is not only about Debian. Python already has various places where the GNU/kFreeBSD __FreeBSD_kernel__ macro appears, so this is not a new thing for Python, just a missing bit here.
The support of GNU/kFreeBSD was indeed recently dropped in the Debian distribution, I haven't checked if it exists in other distributions, Arch for instance, probably. It doesn't hurt much to keep the macros in place (I have to say that python is very portable with very few such #ifdefs)

[malemburg]

So this is more about supporting FreeBSD, than specifically GNU/kFreeBSD ? That would make sense.

[sthibaul]

Yes, it's about supporting the FreeBSD kernel without the usual BSD userland. It's not actually specific to being GNU/kFreeBSD, it could be whatever/kFreeBSD

[gpshead]

The key part of this PR is just adding || defined(__FreeBSD_kernel__) to the C preprocessor checks. That's fine even if nobody can build or maintain anything on such an esoteric system.

I think the docs mentioning the never going to be used by any non-hobbyist GNU/kFreeBSD is the wrong terminology: just leave that as a more generic "FreeBSD kernel" statement (not even expecting anyone to understand the kFreeBSD term). If I were authoring this PR I'd have just updated "FreeBSD" in the existing list to "FreeBSD kernel" in the docs as that itself implies actual FreeBSD as far as most any reader is concerned.

[hugovk]

Triage: I've closed the issue for this PR. Please re-open or create a new issue if needed.