Haiku: Initial managed libraries support

[trungnt2910]

This contains the code required to build the first managed runtime libraries for Haiku, namely System.Private.CoreLib.

Part of #55803.

[Copilot]

Pull request overview

This PR adds initial managed libraries support for Haiku OS by implementing the necessary interop and environment code for System.Private.CoreLib. The changes enable basic Haiku platform detection and working set memory queries.

• Adds Haiku OS platform detection with TARGET_HAIKU constant
• Implements WorkingSet property for Haiku using native area_info API
• Provides comprehensive Haiku OS interop definitions (teams, threads, areas, system info)

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/libraries/System.Private.CoreLib/src/System/OperatingSystem.cs	Adds TARGET_HAIKU constant to platform name detection
src/libraries/System.Private.CoreLib/src/System/Environment.Haiku.cs	Implements WorkingSet property for Haiku by iterating process memory areas
src/libraries/System.Private.CoreLib/src/System.Private.CoreLib.Shared.projitems	Configures conditional compilation for Haiku and includes required interop files
src/libraries/Common/src/Interop/Haiku/Interop.OS.cs	Defines comprehensive Haiku OS interop structures, enums, and P/Invoke methods for process/thread/memory management
src/libraries/Common/src/Interop/Haiku/Interop.Libraries.cs	Defines libroot library constant for Haiku interop

Comments suppressed due to low confidence (3)

src/libraries/Common/src/Interop/Haiku/Interop.OS.cs:209

• The parameter documentation is incorrect. The who parameter is of type BTeamUsage (an enum specifying self or children), not "The thread ID". It should describe that this parameter specifies whether to get usage information for the team itself or its children.
  src/libraries/Common/src/Interop/Haiku/Interop.OS.cs:252
• The parameter documentation should use <see cref="system_info"/> instead of just "system_info" for consistency with other parameter documentation in this file (e.g., lines 159, 170, 181, 210, 230, 242).
  src/libraries/Common/src/Interop/Haiku/Interop.OS.cs:86
• The enum name thread_state uses snake_case which is inconsistent with C# naming conventions and the pattern used by other enums in this file (BTeamUsage, BPriority). It should be renamed to ThreadState to follow PascalCase naming convention.

[trungnt2910]

C/c @am11

Haiku's System.Diagnostics.Process depends on this so I will open that one later.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

[am11]

Haiku's System.Diagnostics.Process depends on this so I will open that one later.

Each library has its own review team, and they’ll use your tests as a measure of correctness while providing feedback mainly on efficiency and code style. The individual PRs don’t need to build (there’s no Haiku CI here).

You could open two or three PRs in parallel if you want to speed up the upstream process (since you already have these patches in your fork tested for a while).

[trungnt2910]

Haiku's System.Diagnostics.Process depends on this so I will open that one later.

What I meant was the two share a common file, Interop.OS.cs, so it will be hard to have both open concurrently.

[jkotas]

The comment on this in haiku header files says

https://github.com/haiku/haiku/blob/d39ce117e02d3d8aac966b1a46bd955a2b59c069/headers/os/kernel/OS.h#L111

Is it ok to be depending on "system private" surface here?

[trungnt2910]

@waddlesplash How likely are the _get_next_[*]_info functions going to break?

[huoyaoyuan]

Additionally, is ABI stability (beyond source compatibility) supported on Haiku?

[trungnt2910]

The alternative is to convert those macros into symbols in System.Native.* then LibraryImport those 🤔

[trungnt2910]

Additionally, is ABI stability (beyond source compatibility) supported on Haiku?

I am quite sure ABI compatibility within a major release is supported.

[am11]

git grep SystemNative_Sysctl will give you all the needed wiring.

[trungnt2910]

What I meant was that if we create shims, we might want to put them in new files (like pal_haiku_os.c and pal_haiku_image.c) for Haiku.

But with waddlesplash confirming that those LibraryImported functions are stable, should we just keep the current implementation instead?

[am11]

Going by that SystemNative_Sysctl (and many others) pattern, you would create a file called pal_area_info.c or something similar (filename is agnostic of OS) and then #ifdef HAVE_xx where #else case is (void)foo; // unsed for other platforms. This pattern keeps the internal entrypoint accounting same across platforms.

[trungnt2910]

The issue here would be _get_next_area_info is not the only API I need to pull in.

#121883 pulls in a bunch of other functions in a similar manner. Therefore, I think an OS-guarded file similar to src/native/libs/System.Native/pal_iossupportversion.m would be better?

Furthermore, sysctl is quite among the UNIX-like OSes, despite some differences among the flavors, while _get_next_area_info is Haiku-specific, so #ifdef TARGET_HAIKU would make more sense than #ifdef HAVE_xx.

Finally, with those functions being confirmed as public and ABI stable from the Haiku side, can't we just keep the current implementation and LibraryImport directly?

[am11]

Furthermore, sysctl is quite among the UNIX-like OSes, despite some differences among the flavors, while _get_next_area_info is Haiku-specific, so #ifdef TARGET_HAIKU would make more sense than #ifdef HAVE_xx.

We are only using sysctl on FreeBSD.

During the port work, try fitting into the most prevalent existing pattern especially when it has given pause to the reviewers and pointed out in docs #121880 (comment).