Skip to content

include/threads: expose min,max prio values to userspace#791

Open
adamgreloch wants to merge 1 commit into
masterfrom
adamgreloch/RTOS-1353
Open

include/threads: expose min,max prio values to userspace#791
adamgreloch wants to merge 1 commit into
masterfrom
adamgreloch/RTOS-1353

Conversation

@adamgreloch

Copy link
Copy Markdown
Member

Pthreads need to validate sched_param->sched_priority values. It'd be best not to hardcode the bounds in libphoenix.

TASK: RTOS-1353

Description

Motivation and Context

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Chore (refactoring, style fixes, git/CI config, submodule management, no code logic changes)

How Has This Been Tested?

  • Already covered by automatic testing.
  • New test added: (add PR link here).
  • Tested by hand on: (list targets here).

Checklist:

  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have added tests to cover my changes.
  • All new and existing linter checks and tests passed.
  • My changes generate no new compilation warnings for any of the targets.

Special treatment

  • This PR needs additional PRs to work (list the PRs, preferably in merge-order).
  • I will merge this PR by myself when appropriate.

@adamgreloch adamgreloch requested a review from etiaro June 17, 2026 10:43

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces global scheduling constants PH_MAX_PRIO and PH_MIN_PRIO in include/threads.h and refactors proc/threads.c to use them instead of local macros and hardcoded values. The reviewer suggested adding documentation to clarify that scheduling priorities are inverted (where 0 is the highest priority and 7 is the lowest) to prevent potential misunderstandings by developers.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

Comment thread include/threads.h Outdated
Pthreads need to validate sched_param->sched_priority values. It'd be
best not to hardcode the bounds in libphoenix.

TASK: RTOS-1353
@adamgreloch adamgreloch force-pushed the adamgreloch/RTOS-1353 branch from 9a903bc to 0a3270a Compare June 17, 2026 10:57
@github-actions

Copy link
Copy Markdown

Unit Test Results

10 860 tests  ±0   10 190 ✅ ±0   53m 27s ⏱️ -11s
   670 suites ±0      670 💤 ±0 
     1 files   ±0        0 ❌ ±0 

Results for commit 0a3270a. ± Comparison against base commit a7b0cf1.

Comment thread include/threads.h


/* NOTE: lower numerical values represent more critical scheduling priorities */
#define PH_MAX_PRIO 7 /* least-critical priority */

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would avoid exposing these constants in the public API and introducing a new PH_* naming scheme unless they are required by external applications. For now, they can be moved to the source file.

@etiaro

etiaro commented Jun 17, 2026

Copy link
Copy Markdown
Contributor

This API is problematic e.g. when considering changing priorities number, as it requires recompilation of both kernel and userspace programs with new headers to keep compatibility.
Another thing is future-proofing for multiple scheduling policies, etc.
If we really need to fetch this values from kernel now, I would opt for syscall.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants