Haiku: Process/thread management functions

[trungnt2910]

Add support for process/thread management functions in System.Diagnostics.Process for Haiku.

This is required to build managed runtime libraries for Haiku as well as running a simple "Hello, World!" application.

Part of #55803.

[trungnt2910]

C/c @am11

I just added the relevant parts of the common files to both, then we can rebase stuff later.

[Copilot]

Pull request overview

This PR adds Haiku operating system support to the System.Diagnostics.Process library, enabling process and thread management functionality for Haiku. This is part of the broader effort to support Haiku as a platform (#55803).

• Implements Haiku-specific process/thread management APIs using native Haiku system calls
• Adds proper platform attribute annotations for API surface compatibility
• Integrates Haiku interop layer for process, thread, and image information

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
ProcessThread.cs	Adds [SupportedOSPlatform("haiku")] attributes to PriorityLevel property getter and setter
ProcessThread.Haiku.cs	Implements Haiku-specific thread priority management and processor time tracking using native BeOS-style priority values
ProcessManager.Haiku.cs	Implements process enumeration, module collection, and process information retrieval for Haiku using team and thread APIs
Process.cs	Adds [UnsupportedOSPlatform("haiku")] attributes to working set limit properties
Process.Haiku.cs	Implements Haiku-specific process properties including boot time caching, start time, processor time tracking, and platform-specific helper methods
System.Diagnostics.Process.csproj	Adds Haiku target framework and includes Haiku-specific source files and interop definitions
Interop.OS.cs	Defines Haiku native interop for OS-level APIs including team/thread/area/system information structures and P/Invoke declarations
Interop.Libraries.cs	Defines the libroot library constant for Haiku native library imports
Interop.Image.cs	Defines Haiku native interop for image (module) information APIs

[Copilot]

The setter is missing [SupportedOSPlatform("linux")] and [SupportedOSPlatform("freebsd")] attributes. While these platforms throw PlatformNotSupportedException in their implementations, the attributes on the public API should match the getter's attributes to maintain consistency and accuracy in the API surface declarations. The presence of the getter attribute for these platforms indicates the API should be callable, even if it throws at runtime.

Suggested change

	[SupportedOSPlatform("windows")]
	[SupportedOSPlatform("windows")]
	[SupportedOSPlatform("linux")]
	[SupportedOSPlatform("freebsd")]

[trungnt2910]

Ignoring since it's not related to Haiku.

[trungnt2910]

Still tracking, will take action soon.

[jeffhandley]

@trungnt2910 I pushed 0ee9ed3 to my fork; it merges main into your branch and resolves the conflict. Feel free to cherry-pick that commit if it's helpful.

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 7 comments.

[Copilot]

Interop.OS.TeamInfo is declared as an unsafe struct (due to the fixed buffer). Declaring/using it here (and calling GetNextTeamInfo) requires an unsafe context; as written this method will fail to compile for the Haiku TFM. Mark the method as unsafe (or refactor the interop type to avoid requiring unsafe at call sites).

[trungnt2910]

Haven't seen any build errors so far.

[Copilot]

CreateProcessInfo uses Interop.OS.TeamInfo (an unsafe struct because of the fixed buffer). This method needs to be in an unsafe context (e.g., mark it unsafe) or the interop needs to be reshaped so callers don't need unsafe; otherwise the Haiku build will fail to compile.

[trungnt2910]

Haven't seen any build errors so far.

[Copilot]

StartTimeCore uses Interop.OS.TeamInfo (an unsafe struct because of the fixed buffer). This getter must be in an unsafe context (e.g., mark the property/getter as unsafe) or the interop needs to be reshaped; otherwise the Haiku TFM will not compile.

[trungnt2910]

Haven't seen any build errors so far.

[trungnt2910]

Local builds are succeeding in both Release and Debug mode (with all my other open PRs on native components applied).

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

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

[am11]

LGTM!
cc @adamsitnik, PTAL.

[Copilot]

Pull request overview

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

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "4e26169766106d54cf582a095878d6d439763335",
"last_reviewed_commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "4e26169766106d54cf582a095878d6d439763335",
"last_recorded_worker_run_id": "29674636225",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"review_id": 4730182665
}
]
}

[github-actions]

Holistic Review

Motivation: Justified. This adds System.Diagnostics.Process support for Haiku (part of #55803), which is a real prerequisite for building and running managed libraries on that platform. The approach follows the established per-platform partial-class pattern already used for iOS, SunOS, etc.

Approach: Sound and consistent with the codebase. New PInvokes are added as SystemNative_* entrypoints wrapped in #if HAVE_OS_H/HAVE_IMAGE_H with ENOTSUP fallbacks, structs are marshalled through PAL shims, and the managed side reuses ArrayBuilder/ProcessModuleCollection. Public API surface changes are additive [SupportedOSPlatform("haiku")] annotations on existing members, so no new API approval is required.

Summary: ⚠️ Needs Human Review. The change is well-structured and platform-isolated, so it cannot regress existing platforms. My main concern is the UTF-8 vs. ANSI string decoding of process/module names (flagged inline). There is also a dead GetNextTeamId PInvoke. Neither blocks the platform bring-up goal, but a maintainer familiar with the Haiku work should confirm the name-decoding intent.

---

Detailed Findings

⚠️ Correctness — Process/module name decoding uses the default code page, not UTF-8

See the inline comment on ProcessManager.Haiku.cs. new string((sbyte*)ptr, 0, length) interprets the bytes using the current ANSI code page, whereas Haiku names are UTF-8. Non-ASCII process/module names will be mangled. Decoding via Encoding.UTF8 (over the computed length) would match both the platform encoding and the convention used elsewhere for native UTF-8 strings.

💡 Dead code — SystemNative_GetNextTeamId appears unused

GetNextTeamId is declared in Interop.OS.cs, exported in entrypoints.c, and implemented in pal_getosinfo.c, but I found no managed caller (GetProcessInfos iterates via GetNextTeamInfo, and there is no EnumerateProcessIds/GetProcessIds for Haiku). If it is not needed for the current bring-up, consider removing it to avoid unused surface; if a follow-up will consume it, a brief note would help.

✅ Native PAL layer — guards and fallbacks look correct

Each entrypoint null-checks its out-params, memsets native structs before use, returns status_t codes directly, and provides (void)-cast ENOTSUP stubs when HAVE_OS_H/HAVE_IMAGE_H are absent. c_static_assert(SYSTEMNATIVE_MAX_PATH >= MAXPATHLEN) guards the image-name buffer. The struct field layouts match the managed [StructLayout(LayoutKind.Sequential)] definitions.

✅ Boot-time caching — race-safe

Process.Haiku.cs caches s_bootTimeTicks with Interlocked.Read/CompareExchange and reconciles with the winning writer's value, so concurrent initialization is handled correctly.

✅ Test coverage — no new tests, but consistent with platform bring-up

No unit tests are added, which is consistent with other platform-enablement PRs in this project where cross-platform System.Diagnostics.Process tests provide coverage once the platform is buildable. A human reviewer should confirm this matches the project's expectations for Haiku enablement.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 181.6 AIC · ⌖ 11 AIC · ⊞ 10K

[github-actions]

⚠️new string((sbyte*)ptr, 0, length) decodes the bytes using the system default ANSI code page rather than UTF-8. Haiku uses UTF-8 for team and image names, so any process or module name containing non-ASCII characters will be misdecoded here. Consider Encoding.UTF8.GetString(new ReadOnlySpan<byte>(ptr, (length < 0) ? maxLength : length)) (you already compute the NUL-terminated length just above), which is the pattern used elsewhere in the codebase for UTF-8 native strings.

[trungnt2910]

Add support for process/thread management functions in System.Diagnostics.Process for Haiku.

This is required to build managed runtime libraries for Haiku as well as running a simple "Hello, World!" application.

Part of #55803.

[trungnt2910]

C/c @am11

I just added the relevant parts of the common files to both, then we can rebase stuff later.

[Copilot]

Pull request overview

This PR adds Haiku operating system support to the System.Diagnostics.Process library, enabling process and thread management functionality for Haiku. This is part of the broader effort to support Haiku as a platform (#55803).

• Implements Haiku-specific process/thread management APIs using native Haiku system calls
• Adds proper platform attribute annotations for API surface compatibility
• Integrates Haiku interop layer for process, thread, and image information

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
ProcessThread.cs	Adds [SupportedOSPlatform("haiku")] attributes to PriorityLevel property getter and setter
ProcessThread.Haiku.cs	Implements Haiku-specific thread priority management and processor time tracking using native BeOS-style priority values
ProcessManager.Haiku.cs	Implements process enumeration, module collection, and process information retrieval for Haiku using team and thread APIs
Process.cs	Adds [UnsupportedOSPlatform("haiku")] attributes to working set limit properties
Process.Haiku.cs	Implements Haiku-specific process properties including boot time caching, start time, processor time tracking, and platform-specific helper methods
System.Diagnostics.Process.csproj	Adds Haiku target framework and includes Haiku-specific source files and interop definitions
Interop.OS.cs	Defines Haiku native interop for OS-level APIs including team/thread/area/system information structures and P/Invoke declarations
Interop.Libraries.cs	Defines the libroot library constant for Haiku native library imports
Interop.Image.cs	Defines Haiku native interop for image (module) information APIs

[Copilot]

The setter is missing [SupportedOSPlatform("linux")] and [SupportedOSPlatform("freebsd")] attributes. While these platforms throw PlatformNotSupportedException in their implementations, the attributes on the public API should match the getter's attributes to maintain consistency and accuracy in the API surface declarations. The presence of the getter attribute for these platforms indicates the API should be callable, even if it throws at runtime.

Suggested change

	[SupportedOSPlatform("windows")]
	[SupportedOSPlatform("windows")]
	[SupportedOSPlatform("linux")]
	[SupportedOSPlatform("freebsd")]

[trungnt2910]

Ignoring since it's not related to Haiku.

[trungnt2910]

Still tracking, will take action soon.

[jeffhandley]

@trungnt2910 I pushed 0ee9ed3 to my fork; it merges main into your branch and resolves the conflict. Feel free to cherry-pick that commit if it's helpful.

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 7 comments.

[Copilot]

Interop.OS.TeamInfo is declared as an unsafe struct (due to the fixed buffer). Declaring/using it here (and calling GetNextTeamInfo) requires an unsafe context; as written this method will fail to compile for the Haiku TFM. Mark the method as unsafe (or refactor the interop type to avoid requiring unsafe at call sites).

[trungnt2910]

Haven't seen any build errors so far.

[Copilot]

CreateProcessInfo uses Interop.OS.TeamInfo (an unsafe struct because of the fixed buffer). This method needs to be in an unsafe context (e.g., mark it unsafe) or the interop needs to be reshaped so callers don't need unsafe; otherwise the Haiku build will fail to compile.

[trungnt2910]

Haven't seen any build errors so far.

[Copilot]

StartTimeCore uses Interop.OS.TeamInfo (an unsafe struct because of the fixed buffer). This getter must be in an unsafe context (e.g., mark the property/getter as unsafe) or the interop needs to be reshaped; otherwise the Haiku TFM will not compile.

[trungnt2910]

Haven't seen any build errors so far.

[trungnt2910]

Local builds are succeeding in both Release and Debug mode (with all my other open PRs on native components applied).

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

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

[am11]

LGTM!
cc @adamsitnik, PTAL.

[Copilot]

Pull request overview

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

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "4e26169766106d54cf582a095878d6d439763335",
"last_reviewed_commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "4e26169766106d54cf582a095878d6d439763335",
"last_recorded_worker_run_id": "29674636225",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"review_id": 4730182665
}
]
}

[github-actions]

Holistic Review

Motivation: Justified. This adds System.Diagnostics.Process support for Haiku (part of #55803), which is a real prerequisite for building and running managed libraries on that platform. The approach follows the established per-platform partial-class pattern already used for iOS, SunOS, etc.

Approach: Sound and consistent with the codebase. New PInvokes are added as SystemNative_* entrypoints wrapped in #if HAVE_OS_H/HAVE_IMAGE_H with ENOTSUP fallbacks, structs are marshalled through PAL shims, and the managed side reuses ArrayBuilder/ProcessModuleCollection. Public API surface changes are additive [SupportedOSPlatform("haiku")] annotations on existing members, so no new API approval is required.

Summary: ⚠️ Needs Human Review. The change is well-structured and platform-isolated, so it cannot regress existing platforms. My main concern is the UTF-8 vs. ANSI string decoding of process/module names (flagged inline). There is also a dead GetNextTeamId PInvoke. Neither blocks the platform bring-up goal, but a maintainer familiar with the Haiku work should confirm the name-decoding intent.

---

Detailed Findings

⚠️ Correctness — Process/module name decoding uses the default code page, not UTF-8

See the inline comment on ProcessManager.Haiku.cs. new string((sbyte*)ptr, 0, length) interprets the bytes using the current ANSI code page, whereas Haiku names are UTF-8. Non-ASCII process/module names will be mangled. Decoding via Encoding.UTF8 (over the computed length) would match both the platform encoding and the convention used elsewhere for native UTF-8 strings.

💡 Dead code — SystemNative_GetNextTeamId appears unused

GetNextTeamId is declared in Interop.OS.cs, exported in entrypoints.c, and implemented in pal_getosinfo.c, but I found no managed caller (GetProcessInfos iterates via GetNextTeamInfo, and there is no EnumerateProcessIds/GetProcessIds for Haiku). If it is not needed for the current bring-up, consider removing it to avoid unused surface; if a follow-up will consume it, a brief note would help.

✅ Native PAL layer — guards and fallbacks look correct

Each entrypoint null-checks its out-params, memsets native structs before use, returns status_t codes directly, and provides (void)-cast ENOTSUP stubs when HAVE_OS_H/HAVE_IMAGE_H are absent. c_static_assert(SYSTEMNATIVE_MAX_PATH >= MAXPATHLEN) guards the image-name buffer. The struct field layouts match the managed [StructLayout(LayoutKind.Sequential)] definitions.

✅ Boot-time caching — race-safe

Process.Haiku.cs caches s_bootTimeTicks with Interlocked.Read/CompareExchange and reconciles with the winning writer's value, so concurrent initialization is handled correctly.

✅ Test coverage — no new tests, but consistent with platform bring-up

No unit tests are added, which is consistent with other platform-enablement PRs in this project where cross-platform System.Diagnostics.Process tests provide coverage once the platform is buildable. A human reviewer should confirm this matches the project's expectations for Haiku enablement.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 181.6 AIC · ⌖ 11 AIC · ⊞ 10K

[github-actions]

⚠️new string((sbyte*)ptr, 0, length) decodes the bytes using the system default ANSI code page rather than UTF-8. Haiku uses UTF-8 for team and image names, so any process or module name containing non-ASCII characters will be misdecoded here. Consider Encoding.UTF8.GetString(new ReadOnlySpan<byte>(ptr, (length < 0) ? maxLength : length)) (you already compute the NUL-terminated length just above), which is the pattern used elsewhere in the codebase for UTF-8 native strings.

[trungnt2910]

Add support for process/thread management functions in System.Diagnostics.Process for Haiku.

This is required to build managed runtime libraries for Haiku as well as running a simple "Hello, World!" application.

Part of #55803.

[trungnt2910]

C/c @am11

I just added the relevant parts of the common files to both, then we can rebase stuff later.

[Copilot]

Pull request overview

This PR adds Haiku operating system support to the System.Diagnostics.Process library, enabling process and thread management functionality for Haiku. This is part of the broader effort to support Haiku as a platform (#55803).

• Implements Haiku-specific process/thread management APIs using native Haiku system calls
• Adds proper platform attribute annotations for API surface compatibility
• Integrates Haiku interop layer for process, thread, and image information

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
ProcessThread.cs	Adds [SupportedOSPlatform("haiku")] attributes to PriorityLevel property getter and setter
ProcessThread.Haiku.cs	Implements Haiku-specific thread priority management and processor time tracking using native BeOS-style priority values
ProcessManager.Haiku.cs	Implements process enumeration, module collection, and process information retrieval for Haiku using team and thread APIs
Process.cs	Adds [UnsupportedOSPlatform("haiku")] attributes to working set limit properties
Process.Haiku.cs	Implements Haiku-specific process properties including boot time caching, start time, processor time tracking, and platform-specific helper methods
System.Diagnostics.Process.csproj	Adds Haiku target framework and includes Haiku-specific source files and interop definitions
Interop.OS.cs	Defines Haiku native interop for OS-level APIs including team/thread/area/system information structures and P/Invoke declarations
Interop.Libraries.cs	Defines the libroot library constant for Haiku native library imports
Interop.Image.cs	Defines Haiku native interop for image (module) information APIs

[Copilot]

The setter is missing [SupportedOSPlatform("linux")] and [SupportedOSPlatform("freebsd")] attributes. While these platforms throw PlatformNotSupportedException in their implementations, the attributes on the public API should match the getter's attributes to maintain consistency and accuracy in the API surface declarations. The presence of the getter attribute for these platforms indicates the API should be callable, even if it throws at runtime.

Suggested change

	[SupportedOSPlatform("windows")]
	[SupportedOSPlatform("windows")]
	[SupportedOSPlatform("linux")]
	[SupportedOSPlatform("freebsd")]

[trungnt2910]

Ignoring since it's not related to Haiku.

[trungnt2910]

Still tracking, will take action soon.

[jeffhandley]

@trungnt2910 I pushed 0ee9ed3 to my fork; it merges main into your branch and resolves the conflict. Feel free to cherry-pick that commit if it's helpful.

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 7 comments.

[Copilot]

Interop.OS.TeamInfo is declared as an unsafe struct (due to the fixed buffer). Declaring/using it here (and calling GetNextTeamInfo) requires an unsafe context; as written this method will fail to compile for the Haiku TFM. Mark the method as unsafe (or refactor the interop type to avoid requiring unsafe at call sites).

[trungnt2910]

Haven't seen any build errors so far.

[Copilot]

CreateProcessInfo uses Interop.OS.TeamInfo (an unsafe struct because of the fixed buffer). This method needs to be in an unsafe context (e.g., mark it unsafe) or the interop needs to be reshaped so callers don't need unsafe; otherwise the Haiku build will fail to compile.

[trungnt2910]

Haven't seen any build errors so far.

[Copilot]

StartTimeCore uses Interop.OS.TeamInfo (an unsafe struct because of the fixed buffer). This getter must be in an unsafe context (e.g., mark the property/getter as unsafe) or the interop needs to be reshaped; otherwise the Haiku TFM will not compile.

[trungnt2910]

Haven't seen any build errors so far.

[trungnt2910]

Local builds are succeeding in both Release and Debug mode (with all my other open PRs on native components applied).

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

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

[am11]

LGTM!
cc @adamsitnik, PTAL.

[Copilot]

Pull request overview

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

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "4e26169766106d54cf582a095878d6d439763335",
"last_reviewed_commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "4e26169766106d54cf582a095878d6d439763335",
"last_recorded_worker_run_id": "29674636225",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"review_id": 4730182665
}
]
}

[github-actions]

Holistic Review

Motivation: Justified. This adds System.Diagnostics.Process support for Haiku (part of #55803), which is a real prerequisite for building and running managed libraries on that platform. The approach follows the established per-platform partial-class pattern already used for iOS, SunOS, etc.

Approach: Sound and consistent with the codebase. New PInvokes are added as SystemNative_* entrypoints wrapped in #if HAVE_OS_H/HAVE_IMAGE_H with ENOTSUP fallbacks, structs are marshalled through PAL shims, and the managed side reuses ArrayBuilder/ProcessModuleCollection. Public API surface changes are additive [SupportedOSPlatform("haiku")] annotations on existing members, so no new API approval is required.

Summary: ⚠️ Needs Human Review. The change is well-structured and platform-isolated, so it cannot regress existing platforms. My main concern is the UTF-8 vs. ANSI string decoding of process/module names (flagged inline). There is also a dead GetNextTeamId PInvoke. Neither blocks the platform bring-up goal, but a maintainer familiar with the Haiku work should confirm the name-decoding intent.

---

Detailed Findings

⚠️ Correctness — Process/module name decoding uses the default code page, not UTF-8

See the inline comment on ProcessManager.Haiku.cs. new string((sbyte*)ptr, 0, length) interprets the bytes using the current ANSI code page, whereas Haiku names are UTF-8. Non-ASCII process/module names will be mangled. Decoding via Encoding.UTF8 (over the computed length) would match both the platform encoding and the convention used elsewhere for native UTF-8 strings.

💡 Dead code — SystemNative_GetNextTeamId appears unused

GetNextTeamId is declared in Interop.OS.cs, exported in entrypoints.c, and implemented in pal_getosinfo.c, but I found no managed caller (GetProcessInfos iterates via GetNextTeamInfo, and there is no EnumerateProcessIds/GetProcessIds for Haiku). If it is not needed for the current bring-up, consider removing it to avoid unused surface; if a follow-up will consume it, a brief note would help.

✅ Native PAL layer — guards and fallbacks look correct

Each entrypoint null-checks its out-params, memsets native structs before use, returns status_t codes directly, and provides (void)-cast ENOTSUP stubs when HAVE_OS_H/HAVE_IMAGE_H are absent. c_static_assert(SYSTEMNATIVE_MAX_PATH >= MAXPATHLEN) guards the image-name buffer. The struct field layouts match the managed [StructLayout(LayoutKind.Sequential)] definitions.

✅ Boot-time caching — race-safe

Process.Haiku.cs caches s_bootTimeTicks with Interlocked.Read/CompareExchange and reconciles with the winning writer's value, so concurrent initialization is handled correctly.

✅ Test coverage — no new tests, but consistent with platform bring-up

No unit tests are added, which is consistent with other platform-enablement PRs in this project where cross-platform System.Diagnostics.Process tests provide coverage once the platform is buildable. A human reviewer should confirm this matches the project's expectations for Haiku enablement.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 181.6 AIC · ⌖ 11 AIC · ⊞ 10K

[github-actions]

⚠️new string((sbyte*)ptr, 0, length) decodes the bytes using the system default ANSI code page rather than UTF-8. Haiku uses UTF-8 for team and image names, so any process or module name containing non-ASCII characters will be misdecoded here. Consider Encoding.UTF8.GetString(new ReadOnlySpan<byte>(ptr, (length < 0) ? maxLength : length)) (you already compute the NUL-terminated length just above), which is the pattern used elsewhere in the codebase for UTF-8 native strings.

[trungnt2910]

Add support for process/thread management functions in System.Diagnostics.Process for Haiku.

This is required to build managed runtime libraries for Haiku as well as running a simple "Hello, World!" application.

Part of #55803.

[trungnt2910]

C/c @am11

I just added the relevant parts of the common files to both, then we can rebase stuff later.

[Copilot]

Pull request overview

This PR adds Haiku operating system support to the System.Diagnostics.Process library, enabling process and thread management functionality for Haiku. This is part of the broader effort to support Haiku as a platform (#55803).

• Implements Haiku-specific process/thread management APIs using native Haiku system calls
• Adds proper platform attribute annotations for API surface compatibility
• Integrates Haiku interop layer for process, thread, and image information

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
ProcessThread.cs	Adds [SupportedOSPlatform("haiku")] attributes to PriorityLevel property getter and setter
ProcessThread.Haiku.cs	Implements Haiku-specific thread priority management and processor time tracking using native BeOS-style priority values
ProcessManager.Haiku.cs	Implements process enumeration, module collection, and process information retrieval for Haiku using team and thread APIs
Process.cs	Adds [UnsupportedOSPlatform("haiku")] attributes to working set limit properties
Process.Haiku.cs	Implements Haiku-specific process properties including boot time caching, start time, processor time tracking, and platform-specific helper methods
System.Diagnostics.Process.csproj	Adds Haiku target framework and includes Haiku-specific source files and interop definitions
Interop.OS.cs	Defines Haiku native interop for OS-level APIs including team/thread/area/system information structures and P/Invoke declarations
Interop.Libraries.cs	Defines the libroot library constant for Haiku native library imports
Interop.Image.cs	Defines Haiku native interop for image (module) information APIs

[Copilot]

The setter is missing [SupportedOSPlatform("linux")] and [SupportedOSPlatform("freebsd")] attributes. While these platforms throw PlatformNotSupportedException in their implementations, the attributes on the public API should match the getter's attributes to maintain consistency and accuracy in the API surface declarations. The presence of the getter attribute for these platforms indicates the API should be callable, even if it throws at runtime.

Suggested change

	[SupportedOSPlatform("windows")]
	[SupportedOSPlatform("windows")]
	[SupportedOSPlatform("linux")]
	[SupportedOSPlatform("freebsd")]

[trungnt2910]

Ignoring since it's not related to Haiku.

[trungnt2910]

Still tracking, will take action soon.

[jeffhandley]

@trungnt2910 I pushed 0ee9ed3 to my fork; it merges main into your branch and resolves the conflict. Feel free to cherry-pick that commit if it's helpful.

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 7 comments.

[Copilot]

Interop.OS.TeamInfo is declared as an unsafe struct (due to the fixed buffer). Declaring/using it here (and calling GetNextTeamInfo) requires an unsafe context; as written this method will fail to compile for the Haiku TFM. Mark the method as unsafe (or refactor the interop type to avoid requiring unsafe at call sites).

[trungnt2910]

Haven't seen any build errors so far.

[Copilot]

CreateProcessInfo uses Interop.OS.TeamInfo (an unsafe struct because of the fixed buffer). This method needs to be in an unsafe context (e.g., mark it unsafe) or the interop needs to be reshaped so callers don't need unsafe; otherwise the Haiku build will fail to compile.

[trungnt2910]

Haven't seen any build errors so far.

[Copilot]

StartTimeCore uses Interop.OS.TeamInfo (an unsafe struct because of the fixed buffer). This getter must be in an unsafe context (e.g., mark the property/getter as unsafe) or the interop needs to be reshaped; otherwise the Haiku TFM will not compile.

[trungnt2910]

Haven't seen any build errors so far.

[trungnt2910]

Local builds are succeeding in both Release and Debug mode (with all my other open PRs on native components applied).

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

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

[am11]

LGTM!
cc @adamsitnik, PTAL.

[Copilot]

Pull request overview

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

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "4e26169766106d54cf582a095878d6d439763335",
"last_reviewed_commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "4e26169766106d54cf582a095878d6d439763335",
"last_recorded_worker_run_id": "29674636225",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"review_id": 4730182665
}
]
}

[github-actions]

Holistic Review

Motivation: Justified. This adds System.Diagnostics.Process support for Haiku (part of #55803), which is a real prerequisite for building and running managed libraries on that platform. The approach follows the established per-platform partial-class pattern already used for iOS, SunOS, etc.

Approach: Sound and consistent with the codebase. New PInvokes are added as SystemNative_* entrypoints wrapped in #if HAVE_OS_H/HAVE_IMAGE_H with ENOTSUP fallbacks, structs are marshalled through PAL shims, and the managed side reuses ArrayBuilder/ProcessModuleCollection. Public API surface changes are additive [SupportedOSPlatform("haiku")] annotations on existing members, so no new API approval is required.

Summary: ⚠️ Needs Human Review. The change is well-structured and platform-isolated, so it cannot regress existing platforms. My main concern is the UTF-8 vs. ANSI string decoding of process/module names (flagged inline). There is also a dead GetNextTeamId PInvoke. Neither blocks the platform bring-up goal, but a maintainer familiar with the Haiku work should confirm the name-decoding intent.

---

Detailed Findings

⚠️ Correctness — Process/module name decoding uses the default code page, not UTF-8

See the inline comment on ProcessManager.Haiku.cs. new string((sbyte*)ptr, 0, length) interprets the bytes using the current ANSI code page, whereas Haiku names are UTF-8. Non-ASCII process/module names will be mangled. Decoding via Encoding.UTF8 (over the computed length) would match both the platform encoding and the convention used elsewhere for native UTF-8 strings.

💡 Dead code — SystemNative_GetNextTeamId appears unused

GetNextTeamId is declared in Interop.OS.cs, exported in entrypoints.c, and implemented in pal_getosinfo.c, but I found no managed caller (GetProcessInfos iterates via GetNextTeamInfo, and there is no EnumerateProcessIds/GetProcessIds for Haiku). If it is not needed for the current bring-up, consider removing it to avoid unused surface; if a follow-up will consume it, a brief note would help.

✅ Native PAL layer — guards and fallbacks look correct

Each entrypoint null-checks its out-params, memsets native structs before use, returns status_t codes directly, and provides (void)-cast ENOTSUP stubs when HAVE_OS_H/HAVE_IMAGE_H are absent. c_static_assert(SYSTEMNATIVE_MAX_PATH >= MAXPATHLEN) guards the image-name buffer. The struct field layouts match the managed [StructLayout(LayoutKind.Sequential)] definitions.

✅ Boot-time caching — race-safe

Process.Haiku.cs caches s_bootTimeTicks with Interlocked.Read/CompareExchange and reconciles with the winning writer's value, so concurrent initialization is handled correctly.

✅ Test coverage — no new tests, but consistent with platform bring-up

No unit tests are added, which is consistent with other platform-enablement PRs in this project where cross-platform System.Diagnostics.Process tests provide coverage once the platform is buildable. A human reviewer should confirm this matches the project's expectations for Haiku enablement.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 181.6 AIC · ⌖ 11 AIC · ⊞ 10K

[github-actions]

⚠️new string((sbyte*)ptr, 0, length) decodes the bytes using the system default ANSI code page rather than UTF-8. Haiku uses UTF-8 for team and image names, so any process or module name containing non-ASCII characters will be misdecoded here. Consider Encoding.UTF8.GetString(new ReadOnlySpan<byte>(ptr, (length < 0) ? maxLength : length)) (you already compute the NUL-terminated length just above), which is the pattern used elsewhere in the codebase for UTF-8 native strings.

[trungnt2910]

Add support for process/thread management functions in System.Diagnostics.Process for Haiku.

This is required to build managed runtime libraries for Haiku as well as running a simple "Hello, World!" application.

Part of #55803.

[trungnt2910]

C/c @am11

I just added the relevant parts of the common files to both, then we can rebase stuff later.

[Copilot]

Pull request overview

This PR adds Haiku operating system support to the System.Diagnostics.Process library, enabling process and thread management functionality for Haiku. This is part of the broader effort to support Haiku as a platform (#55803).

• Implements Haiku-specific process/thread management APIs using native Haiku system calls
• Adds proper platform attribute annotations for API surface compatibility
• Integrates Haiku interop layer for process, thread, and image information

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
ProcessThread.cs	Adds [SupportedOSPlatform("haiku")] attributes to PriorityLevel property getter and setter
ProcessThread.Haiku.cs	Implements Haiku-specific thread priority management and processor time tracking using native BeOS-style priority values
ProcessManager.Haiku.cs	Implements process enumeration, module collection, and process information retrieval for Haiku using team and thread APIs
Process.cs	Adds [UnsupportedOSPlatform("haiku")] attributes to working set limit properties
Process.Haiku.cs	Implements Haiku-specific process properties including boot time caching, start time, processor time tracking, and platform-specific helper methods
System.Diagnostics.Process.csproj	Adds Haiku target framework and includes Haiku-specific source files and interop definitions
Interop.OS.cs	Defines Haiku native interop for OS-level APIs including team/thread/area/system information structures and P/Invoke declarations
Interop.Libraries.cs	Defines the libroot library constant for Haiku native library imports
Interop.Image.cs	Defines Haiku native interop for image (module) information APIs

[Copilot]

The setter is missing [SupportedOSPlatform("linux")] and [SupportedOSPlatform("freebsd")] attributes. While these platforms throw PlatformNotSupportedException in their implementations, the attributes on the public API should match the getter's attributes to maintain consistency and accuracy in the API surface declarations. The presence of the getter attribute for these platforms indicates the API should be callable, even if it throws at runtime.

Suggested change

	[SupportedOSPlatform("windows")]
	[SupportedOSPlatform("windows")]
	[SupportedOSPlatform("linux")]
	[SupportedOSPlatform("freebsd")]

[trungnt2910]

Ignoring since it's not related to Haiku.

[trungnt2910]

Still tracking, will take action soon.

[jeffhandley]

@trungnt2910 I pushed 0ee9ed3 to my fork; it merges main into your branch and resolves the conflict. Feel free to cherry-pick that commit if it's helpful.

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 7 comments.

[Copilot]

Interop.OS.TeamInfo is declared as an unsafe struct (due to the fixed buffer). Declaring/using it here (and calling GetNextTeamInfo) requires an unsafe context; as written this method will fail to compile for the Haiku TFM. Mark the method as unsafe (or refactor the interop type to avoid requiring unsafe at call sites).

[trungnt2910]

Haven't seen any build errors so far.

[Copilot]

CreateProcessInfo uses Interop.OS.TeamInfo (an unsafe struct because of the fixed buffer). This method needs to be in an unsafe context (e.g., mark it unsafe) or the interop needs to be reshaped so callers don't need unsafe; otherwise the Haiku build will fail to compile.

[trungnt2910]

Haven't seen any build errors so far.

[Copilot]

StartTimeCore uses Interop.OS.TeamInfo (an unsafe struct because of the fixed buffer). This getter must be in an unsafe context (e.g., mark the property/getter as unsafe) or the interop needs to be reshaped; otherwise the Haiku TFM will not compile.

[trungnt2910]

Haven't seen any build errors so far.

[trungnt2910]

Local builds are succeeding in both Release and Debug mode (with all my other open PRs on native components applied).

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

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

[am11]

LGTM!
cc @adamsitnik, PTAL.

[Copilot]

Pull request overview

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

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "4e26169766106d54cf582a095878d6d439763335",
"last_reviewed_commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "4e26169766106d54cf582a095878d6d439763335",
"last_recorded_worker_run_id": "29674636225",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"review_id": 4730182665
}
]
}

[github-actions]

Holistic Review

Motivation: Justified. This adds System.Diagnostics.Process support for Haiku (part of #55803), which is a real prerequisite for building and running managed libraries on that platform. The approach follows the established per-platform partial-class pattern already used for iOS, SunOS, etc.

Approach: Sound and consistent with the codebase. New PInvokes are added as SystemNative_* entrypoints wrapped in #if HAVE_OS_H/HAVE_IMAGE_H with ENOTSUP fallbacks, structs are marshalled through PAL shims, and the managed side reuses ArrayBuilder/ProcessModuleCollection. Public API surface changes are additive [SupportedOSPlatform("haiku")] annotations on existing members, so no new API approval is required.

Summary: ⚠️ Needs Human Review. The change is well-structured and platform-isolated, so it cannot regress existing platforms. My main concern is the UTF-8 vs. ANSI string decoding of process/module names (flagged inline). There is also a dead GetNextTeamId PInvoke. Neither blocks the platform bring-up goal, but a maintainer familiar with the Haiku work should confirm the name-decoding intent.

---

Detailed Findings

⚠️ Correctness — Process/module name decoding uses the default code page, not UTF-8

See the inline comment on ProcessManager.Haiku.cs. new string((sbyte*)ptr, 0, length) interprets the bytes using the current ANSI code page, whereas Haiku names are UTF-8. Non-ASCII process/module names will be mangled. Decoding via Encoding.UTF8 (over the computed length) would match both the platform encoding and the convention used elsewhere for native UTF-8 strings.

💡 Dead code — SystemNative_GetNextTeamId appears unused

GetNextTeamId is declared in Interop.OS.cs, exported in entrypoints.c, and implemented in pal_getosinfo.c, but I found no managed caller (GetProcessInfos iterates via GetNextTeamInfo, and there is no EnumerateProcessIds/GetProcessIds for Haiku). If it is not needed for the current bring-up, consider removing it to avoid unused surface; if a follow-up will consume it, a brief note would help.

✅ Native PAL layer — guards and fallbacks look correct

Each entrypoint null-checks its out-params, memsets native structs before use, returns status_t codes directly, and provides (void)-cast ENOTSUP stubs when HAVE_OS_H/HAVE_IMAGE_H are absent. c_static_assert(SYSTEMNATIVE_MAX_PATH >= MAXPATHLEN) guards the image-name buffer. The struct field layouts match the managed [StructLayout(LayoutKind.Sequential)] definitions.

✅ Boot-time caching — race-safe

Process.Haiku.cs caches s_bootTimeTicks with Interlocked.Read/CompareExchange and reconciles with the winning writer's value, so concurrent initialization is handled correctly.

✅ Test coverage — no new tests, but consistent with platform bring-up

No unit tests are added, which is consistent with other platform-enablement PRs in this project where cross-platform System.Diagnostics.Process tests provide coverage once the platform is buildable. A human reviewer should confirm this matches the project's expectations for Haiku enablement.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 181.6 AIC · ⌖ 11 AIC · ⊞ 10K

[github-actions]

⚠️new string((sbyte*)ptr, 0, length) decodes the bytes using the system default ANSI code page rather than UTF-8. Haiku uses UTF-8 for team and image names, so any process or module name containing non-ASCII characters will be misdecoded here. Consider Encoding.UTF8.GetString(new ReadOnlySpan<byte>(ptr, (length < 0) ? maxLength : length)) (you already compute the NUL-terminated length just above), which is the pattern used elsewhere in the codebase for UTF-8 native strings.

[trungnt2910]

Add support for process/thread management functions in System.Diagnostics.Process for Haiku.

This is required to build managed runtime libraries for Haiku as well as running a simple "Hello, World!" application.

Part of #55803.

[trungnt2910]

C/c @am11

I just added the relevant parts of the common files to both, then we can rebase stuff later.

[Copilot]

Pull request overview

This PR adds Haiku operating system support to the System.Diagnostics.Process library, enabling process and thread management functionality for Haiku. This is part of the broader effort to support Haiku as a platform (#55803).

• Implements Haiku-specific process/thread management APIs using native Haiku system calls
• Adds proper platform attribute annotations for API surface compatibility
• Integrates Haiku interop layer for process, thread, and image information

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
ProcessThread.cs	Adds [SupportedOSPlatform("haiku")] attributes to PriorityLevel property getter and setter
ProcessThread.Haiku.cs	Implements Haiku-specific thread priority management and processor time tracking using native BeOS-style priority values
ProcessManager.Haiku.cs	Implements process enumeration, module collection, and process information retrieval for Haiku using team and thread APIs
Process.cs	Adds [UnsupportedOSPlatform("haiku")] attributes to working set limit properties
Process.Haiku.cs	Implements Haiku-specific process properties including boot time caching, start time, processor time tracking, and platform-specific helper methods
System.Diagnostics.Process.csproj	Adds Haiku target framework and includes Haiku-specific source files and interop definitions
Interop.OS.cs	Defines Haiku native interop for OS-level APIs including team/thread/area/system information structures and P/Invoke declarations
Interop.Libraries.cs	Defines the libroot library constant for Haiku native library imports
Interop.Image.cs	Defines Haiku native interop for image (module) information APIs

[Copilot]

The setter is missing [SupportedOSPlatform("linux")] and [SupportedOSPlatform("freebsd")] attributes. While these platforms throw PlatformNotSupportedException in their implementations, the attributes on the public API should match the getter's attributes to maintain consistency and accuracy in the API surface declarations. The presence of the getter attribute for these platforms indicates the API should be callable, even if it throws at runtime.

Suggested change

	[SupportedOSPlatform("windows")]
	[SupportedOSPlatform("windows")]
	[SupportedOSPlatform("linux")]
	[SupportedOSPlatform("freebsd")]

[trungnt2910]

Ignoring since it's not related to Haiku.

[trungnt2910]

Still tracking, will take action soon.

[jeffhandley]

@trungnt2910 I pushed 0ee9ed3 to my fork; it merges main into your branch and resolves the conflict. Feel free to cherry-pick that commit if it's helpful.

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 7 comments.

[Copilot]

Interop.OS.TeamInfo is declared as an unsafe struct (due to the fixed buffer). Declaring/using it here (and calling GetNextTeamInfo) requires an unsafe context; as written this method will fail to compile for the Haiku TFM. Mark the method as unsafe (or refactor the interop type to avoid requiring unsafe at call sites).

[trungnt2910]

Haven't seen any build errors so far.

[Copilot]

CreateProcessInfo uses Interop.OS.TeamInfo (an unsafe struct because of the fixed buffer). This method needs to be in an unsafe context (e.g., mark it unsafe) or the interop needs to be reshaped so callers don't need unsafe; otherwise the Haiku build will fail to compile.

[trungnt2910]

Haven't seen any build errors so far.

[Copilot]

StartTimeCore uses Interop.OS.TeamInfo (an unsafe struct because of the fixed buffer). This getter must be in an unsafe context (e.g., mark the property/getter as unsafe) or the interop needs to be reshaped; otherwise the Haiku TFM will not compile.

[trungnt2910]

Haven't seen any build errors so far.

[trungnt2910]

Local builds are succeeding in both Release and Debug mode (with all my other open PRs on native components applied).

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

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

[am11]

LGTM!
cc @adamsitnik, PTAL.

[Copilot]

Pull request overview

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

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "4e26169766106d54cf582a095878d6d439763335",
"last_reviewed_commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "4e26169766106d54cf582a095878d6d439763335",
"last_recorded_worker_run_id": "29674636225",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"review_id": 4730182665
}
]
}

[github-actions]

Holistic Review

Motivation: Justified. This adds System.Diagnostics.Process support for Haiku (part of #55803), which is a real prerequisite for building and running managed libraries on that platform. The approach follows the established per-platform partial-class pattern already used for iOS, SunOS, etc.

Approach: Sound and consistent with the codebase. New PInvokes are added as SystemNative_* entrypoints wrapped in #if HAVE_OS_H/HAVE_IMAGE_H with ENOTSUP fallbacks, structs are marshalled through PAL shims, and the managed side reuses ArrayBuilder/ProcessModuleCollection. Public API surface changes are additive [SupportedOSPlatform("haiku")] annotations on existing members, so no new API approval is required.

Summary: ⚠️ Needs Human Review. The change is well-structured and platform-isolated, so it cannot regress existing platforms. My main concern is the UTF-8 vs. ANSI string decoding of process/module names (flagged inline). There is also a dead GetNextTeamId PInvoke. Neither blocks the platform bring-up goal, but a maintainer familiar with the Haiku work should confirm the name-decoding intent.

---

Detailed Findings

⚠️ Correctness — Process/module name decoding uses the default code page, not UTF-8

See the inline comment on ProcessManager.Haiku.cs. new string((sbyte*)ptr, 0, length) interprets the bytes using the current ANSI code page, whereas Haiku names are UTF-8. Non-ASCII process/module names will be mangled. Decoding via Encoding.UTF8 (over the computed length) would match both the platform encoding and the convention used elsewhere for native UTF-8 strings.

💡 Dead code — SystemNative_GetNextTeamId appears unused

GetNextTeamId is declared in Interop.OS.cs, exported in entrypoints.c, and implemented in pal_getosinfo.c, but I found no managed caller (GetProcessInfos iterates via GetNextTeamInfo, and there is no EnumerateProcessIds/GetProcessIds for Haiku). If it is not needed for the current bring-up, consider removing it to avoid unused surface; if a follow-up will consume it, a brief note would help.

✅ Native PAL layer — guards and fallbacks look correct

Each entrypoint null-checks its out-params, memsets native structs before use, returns status_t codes directly, and provides (void)-cast ENOTSUP stubs when HAVE_OS_H/HAVE_IMAGE_H are absent. c_static_assert(SYSTEMNATIVE_MAX_PATH >= MAXPATHLEN) guards the image-name buffer. The struct field layouts match the managed [StructLayout(LayoutKind.Sequential)] definitions.

✅ Boot-time caching — race-safe

Process.Haiku.cs caches s_bootTimeTicks with Interlocked.Read/CompareExchange and reconciles with the winning writer's value, so concurrent initialization is handled correctly.

✅ Test coverage — no new tests, but consistent with platform bring-up

No unit tests are added, which is consistent with other platform-enablement PRs in this project where cross-platform System.Diagnostics.Process tests provide coverage once the platform is buildable. A human reviewer should confirm this matches the project's expectations for Haiku enablement.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 181.6 AIC · ⌖ 11 AIC · ⊞ 10K

[github-actions]

⚠️new string((sbyte*)ptr, 0, length) decodes the bytes using the system default ANSI code page rather than UTF-8. Haiku uses UTF-8 for team and image names, so any process or module name containing non-ASCII characters will be misdecoded here. Consider Encoding.UTF8.GetString(new ReadOnlySpan<byte>(ptr, (length < 0) ? maxLength : length)) (you already compute the NUL-terminated length just above), which is the pattern used elsewhere in the codebase for UTF-8 native strings.

[trungnt2910]

Add support for process/thread management functions in System.Diagnostics.Process for Haiku.

This is required to build managed runtime libraries for Haiku as well as running a simple "Hello, World!" application.

Part of #55803.

[trungnt2910]

C/c @am11

I just added the relevant parts of the common files to both, then we can rebase stuff later.

[Copilot]

Pull request overview

This PR adds Haiku operating system support to the System.Diagnostics.Process library, enabling process and thread management functionality for Haiku. This is part of the broader effort to support Haiku as a platform (#55803).

• Implements Haiku-specific process/thread management APIs using native Haiku system calls
• Adds proper platform attribute annotations for API surface compatibility
• Integrates Haiku interop layer for process, thread, and image information

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
ProcessThread.cs	Adds [SupportedOSPlatform("haiku")] attributes to PriorityLevel property getter and setter
ProcessThread.Haiku.cs	Implements Haiku-specific thread priority management and processor time tracking using native BeOS-style priority values
ProcessManager.Haiku.cs	Implements process enumeration, module collection, and process information retrieval for Haiku using team and thread APIs
Process.cs	Adds [UnsupportedOSPlatform("haiku")] attributes to working set limit properties
Process.Haiku.cs	Implements Haiku-specific process properties including boot time caching, start time, processor time tracking, and platform-specific helper methods
System.Diagnostics.Process.csproj	Adds Haiku target framework and includes Haiku-specific source files and interop definitions
Interop.OS.cs	Defines Haiku native interop for OS-level APIs including team/thread/area/system information structures and P/Invoke declarations
Interop.Libraries.cs	Defines the libroot library constant for Haiku native library imports
Interop.Image.cs	Defines Haiku native interop for image (module) information APIs

[Copilot]

The setter is missing [SupportedOSPlatform("linux")] and [SupportedOSPlatform("freebsd")] attributes. While these platforms throw PlatformNotSupportedException in their implementations, the attributes on the public API should match the getter's attributes to maintain consistency and accuracy in the API surface declarations. The presence of the getter attribute for these platforms indicates the API should be callable, even if it throws at runtime.

Suggested change

	[SupportedOSPlatform("windows")]
	[SupportedOSPlatform("windows")]
	[SupportedOSPlatform("linux")]
	[SupportedOSPlatform("freebsd")]

[trungnt2910]

Ignoring since it's not related to Haiku.

[trungnt2910]

Still tracking, will take action soon.

[jeffhandley]

@trungnt2910 I pushed 0ee9ed3 to my fork; it merges main into your branch and resolves the conflict. Feel free to cherry-pick that commit if it's helpful.

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 7 comments.

[Copilot]

Interop.OS.TeamInfo is declared as an unsafe struct (due to the fixed buffer). Declaring/using it here (and calling GetNextTeamInfo) requires an unsafe context; as written this method will fail to compile for the Haiku TFM. Mark the method as unsafe (or refactor the interop type to avoid requiring unsafe at call sites).

[trungnt2910]

Haven't seen any build errors so far.

[Copilot]

CreateProcessInfo uses Interop.OS.TeamInfo (an unsafe struct because of the fixed buffer). This method needs to be in an unsafe context (e.g., mark it unsafe) or the interop needs to be reshaped so callers don't need unsafe; otherwise the Haiku build will fail to compile.

[trungnt2910]

Haven't seen any build errors so far.

[Copilot]

StartTimeCore uses Interop.OS.TeamInfo (an unsafe struct because of the fixed buffer). This getter must be in an unsafe context (e.g., mark the property/getter as unsafe) or the interop needs to be reshaped; otherwise the Haiku TFM will not compile.

[trungnt2910]

Haven't seen any build errors so far.

[trungnt2910]

Local builds are succeeding in both Release and Debug mode (with all my other open PRs on native components applied).

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

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

[am11]

LGTM!
cc @adamsitnik, PTAL.

[Copilot]

Pull request overview

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

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "4e26169766106d54cf582a095878d6d439763335",
"last_reviewed_commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "4e26169766106d54cf582a095878d6d439763335",
"last_recorded_worker_run_id": "29674636225",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"review_id": 4730182665
}
]
}

[github-actions]

Holistic Review

Motivation: Justified. This adds System.Diagnostics.Process support for Haiku (part of #55803), which is a real prerequisite for building and running managed libraries on that platform. The approach follows the established per-platform partial-class pattern already used for iOS, SunOS, etc.

Approach: Sound and consistent with the codebase. New PInvokes are added as SystemNative_* entrypoints wrapped in #if HAVE_OS_H/HAVE_IMAGE_H with ENOTSUP fallbacks, structs are marshalled through PAL shims, and the managed side reuses ArrayBuilder/ProcessModuleCollection. Public API surface changes are additive [SupportedOSPlatform("haiku")] annotations on existing members, so no new API approval is required.

Summary: ⚠️ Needs Human Review. The change is well-structured and platform-isolated, so it cannot regress existing platforms. My main concern is the UTF-8 vs. ANSI string decoding of process/module names (flagged inline). There is also a dead GetNextTeamId PInvoke. Neither blocks the platform bring-up goal, but a maintainer familiar with the Haiku work should confirm the name-decoding intent.

---

Detailed Findings

⚠️ Correctness — Process/module name decoding uses the default code page, not UTF-8

See the inline comment on ProcessManager.Haiku.cs. new string((sbyte*)ptr, 0, length) interprets the bytes using the current ANSI code page, whereas Haiku names are UTF-8. Non-ASCII process/module names will be mangled. Decoding via Encoding.UTF8 (over the computed length) would match both the platform encoding and the convention used elsewhere for native UTF-8 strings.

💡 Dead code — SystemNative_GetNextTeamId appears unused

GetNextTeamId is declared in Interop.OS.cs, exported in entrypoints.c, and implemented in pal_getosinfo.c, but I found no managed caller (GetProcessInfos iterates via GetNextTeamInfo, and there is no EnumerateProcessIds/GetProcessIds for Haiku). If it is not needed for the current bring-up, consider removing it to avoid unused surface; if a follow-up will consume it, a brief note would help.

✅ Native PAL layer — guards and fallbacks look correct

Each entrypoint null-checks its out-params, memsets native structs before use, returns status_t codes directly, and provides (void)-cast ENOTSUP stubs when HAVE_OS_H/HAVE_IMAGE_H are absent. c_static_assert(SYSTEMNATIVE_MAX_PATH >= MAXPATHLEN) guards the image-name buffer. The struct field layouts match the managed [StructLayout(LayoutKind.Sequential)] definitions.

✅ Boot-time caching — race-safe

Process.Haiku.cs caches s_bootTimeTicks with Interlocked.Read/CompareExchange and reconciles with the winning writer's value, so concurrent initialization is handled correctly.

✅ Test coverage — no new tests, but consistent with platform bring-up

No unit tests are added, which is consistent with other platform-enablement PRs in this project where cross-platform System.Diagnostics.Process tests provide coverage once the platform is buildable. A human reviewer should confirm this matches the project's expectations for Haiku enablement.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 181.6 AIC · ⌖ 11 AIC · ⊞ 10K

[github-actions]

⚠️new string((sbyte*)ptr, 0, length) decodes the bytes using the system default ANSI code page rather than UTF-8. Haiku uses UTF-8 for team and image names, so any process or module name containing non-ASCII characters will be misdecoded here. Consider Encoding.UTF8.GetString(new ReadOnlySpan<byte>(ptr, (length < 0) ? maxLength : length)) (you already compute the NUL-terminated length just above), which is the pattern used elsewhere in the codebase for UTF-8 native strings.

[trungnt2910]

Add support for process/thread management functions in System.Diagnostics.Process for Haiku.

This is required to build managed runtime libraries for Haiku as well as running a simple "Hello, World!" application.

Part of #55803.

[trungnt2910]

C/c @am11

I just added the relevant parts of the common files to both, then we can rebase stuff later.

[Copilot]

Pull request overview

This PR adds Haiku operating system support to the System.Diagnostics.Process library, enabling process and thread management functionality for Haiku. This is part of the broader effort to support Haiku as a platform (#55803).

• Implements Haiku-specific process/thread management APIs using native Haiku system calls
• Adds proper platform attribute annotations for API surface compatibility
• Integrates Haiku interop layer for process, thread, and image information

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
ProcessThread.cs	Adds [SupportedOSPlatform("haiku")] attributes to PriorityLevel property getter and setter
ProcessThread.Haiku.cs	Implements Haiku-specific thread priority management and processor time tracking using native BeOS-style priority values
ProcessManager.Haiku.cs	Implements process enumeration, module collection, and process information retrieval for Haiku using team and thread APIs
Process.cs	Adds [UnsupportedOSPlatform("haiku")] attributes to working set limit properties
Process.Haiku.cs	Implements Haiku-specific process properties including boot time caching, start time, processor time tracking, and platform-specific helper methods
System.Diagnostics.Process.csproj	Adds Haiku target framework and includes Haiku-specific source files and interop definitions
Interop.OS.cs	Defines Haiku native interop for OS-level APIs including team/thread/area/system information structures and P/Invoke declarations
Interop.Libraries.cs	Defines the libroot library constant for Haiku native library imports
Interop.Image.cs	Defines Haiku native interop for image (module) information APIs

[Copilot]

The setter is missing [SupportedOSPlatform("linux")] and [SupportedOSPlatform("freebsd")] attributes. While these platforms throw PlatformNotSupportedException in their implementations, the attributes on the public API should match the getter's attributes to maintain consistency and accuracy in the API surface declarations. The presence of the getter attribute for these platforms indicates the API should be callable, even if it throws at runtime.

Suggested change

	[SupportedOSPlatform("windows")]
	[SupportedOSPlatform("windows")]
	[SupportedOSPlatform("linux")]
	[SupportedOSPlatform("freebsd")]

[trungnt2910]

Ignoring since it's not related to Haiku.

[trungnt2910]

Still tracking, will take action soon.

[jeffhandley]

@trungnt2910 I pushed 0ee9ed3 to my fork; it merges main into your branch and resolves the conflict. Feel free to cherry-pick that commit if it's helpful.

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 7 comments.

[Copilot]

Interop.OS.TeamInfo is declared as an unsafe struct (due to the fixed buffer). Declaring/using it here (and calling GetNextTeamInfo) requires an unsafe context; as written this method will fail to compile for the Haiku TFM. Mark the method as unsafe (or refactor the interop type to avoid requiring unsafe at call sites).

[trungnt2910]

Haven't seen any build errors so far.

[Copilot]

CreateProcessInfo uses Interop.OS.TeamInfo (an unsafe struct because of the fixed buffer). This method needs to be in an unsafe context (e.g., mark it unsafe) or the interop needs to be reshaped so callers don't need unsafe; otherwise the Haiku build will fail to compile.

[trungnt2910]

Haven't seen any build errors so far.

[Copilot]

StartTimeCore uses Interop.OS.TeamInfo (an unsafe struct because of the fixed buffer). This getter must be in an unsafe context (e.g., mark the property/getter as unsafe) or the interop needs to be reshaped; otherwise the Haiku TFM will not compile.

[trungnt2910]

Haven't seen any build errors so far.

[trungnt2910]

Local builds are succeeding in both Release and Debug mode (with all my other open PRs on native components applied).

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

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

[am11]

LGTM!
cc @adamsitnik, PTAL.

[Copilot]

Pull request overview

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

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "4e26169766106d54cf582a095878d6d439763335",
"last_reviewed_commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "4e26169766106d54cf582a095878d6d439763335",
"last_recorded_worker_run_id": "29674636225",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "0b80a9e38506d4f0915adadda63ae6e315a229cb",
"review_id": 4730182665
}
]
}

[github-actions]

Holistic Review

Motivation: Justified. This adds System.Diagnostics.Process support for Haiku (part of #55803), which is a real prerequisite for building and running managed libraries on that platform. The approach follows the established per-platform partial-class pattern already used for iOS, SunOS, etc.

Approach: Sound and consistent with the codebase. New PInvokes are added as SystemNative_* entrypoints wrapped in #if HAVE_OS_H/HAVE_IMAGE_H with ENOTSUP fallbacks, structs are marshalled through PAL shims, and the managed side reuses ArrayBuilder/ProcessModuleCollection. Public API surface changes are additive [SupportedOSPlatform("haiku")] annotations on existing members, so no new API approval is required.

Summary: ⚠️ Needs Human Review. The change is well-structured and platform-isolated, so it cannot regress existing platforms. My main concern is the UTF-8 vs. ANSI string decoding of process/module names (flagged inline). There is also a dead GetNextTeamId PInvoke. Neither blocks the platform bring-up goal, but a maintainer familiar with the Haiku work should confirm the name-decoding intent.

---

Detailed Findings

⚠️ Correctness — Process/module name decoding uses the default code page, not UTF-8

See the inline comment on ProcessManager.Haiku.cs. new string((sbyte*)ptr, 0, length) interprets the bytes using the current ANSI code page, whereas Haiku names are UTF-8. Non-ASCII process/module names will be mangled. Decoding via Encoding.UTF8 (over the computed length) would match both the platform encoding and the convention used elsewhere for native UTF-8 strings.

💡 Dead code — SystemNative_GetNextTeamId appears unused

GetNextTeamId is declared in Interop.OS.cs, exported in entrypoints.c, and implemented in pal_getosinfo.c, but I found no managed caller (GetProcessInfos iterates via GetNextTeamInfo, and there is no EnumerateProcessIds/GetProcessIds for Haiku). If it is not needed for the current bring-up, consider removing it to avoid unused surface; if a follow-up will consume it, a brief note would help.

✅ Native PAL layer — guards and fallbacks look correct

Each entrypoint null-checks its out-params, memsets native structs before use, returns status_t codes directly, and provides (void)-cast ENOTSUP stubs when HAVE_OS_H/HAVE_IMAGE_H are absent. c_static_assert(SYSTEMNATIVE_MAX_PATH >= MAXPATHLEN) guards the image-name buffer. The struct field layouts match the managed [StructLayout(LayoutKind.Sequential)] definitions.

✅ Boot-time caching — race-safe

Process.Haiku.cs caches s_bootTimeTicks with Interlocked.Read/CompareExchange and reconciles with the winning writer's value, so concurrent initialization is handled correctly.

✅ Test coverage — no new tests, but consistent with platform bring-up

No unit tests are added, which is consistent with other platform-enablement PRs in this project where cross-platform System.Diagnostics.Process tests provide coverage once the platform is buildable. A human reviewer should confirm this matches the project's expectations for Haiku enablement.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 181.6 AIC · ⌖ 11 AIC · ⊞ 10K

[github-actions]

⚠️new string((sbyte*)ptr, 0, length) decodes the bytes using the system default ANSI code page rather than UTF-8. Haiku uses UTF-8 for team and image names, so any process or module name containing non-ASCII characters will be misdecoded here. Consider Encoding.UTF8.GetString(new ReadOnlySpan<byte>(ptr, (length < 0) ? maxLength : length)) (you already compute the NUL-terminated length just above), which is the pattern used elsewhere in the codebase for UTF-8 native strings.