Re: [RFC PATCH gnumach 1/3] don't set max_priority in thread template

Re,

[email protected], le lun. 27 avril 2026 00:07:11 +0100, a ecrit:
> From: Diego Nieto Cid <[email protected]>
> 
> Leave max_priority uninitialized (0) so that when
> a thread is created it inherits the max priority
> from the processor set.

I'd rather set it to BASEPRI_SYSTEM, to avoid going lower than kernel
threads etc.

> This should not change any behaviour (except allowing
> inheritance) because the default max_priority of a
> processor set is also BASEPRI_USER.

Which I advised to lower to BASEPRI_SYSTEM too :)

It's rather in boot_script_task_create that we'd want to set the
max_priority to BASEPRI_USER, so that userland inherits it by default,
including root, while letting it go down from that.

> ---
>  kern/thread.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/kern/thread.c b/kern/thread.c
> index deb9688d..0e753d7a 100644
> --- a/kern/thread.c
> +++ b/kern/thread.c
> @@ -335,7 +335,14 @@ void thread_init(void)
>  	thread_template.swap_func = thread_bootstrap_return;
>  
>  /*	thread_template.priority (later) */
> -	thread_template.max_priority = BASEPRI_USER;
> +	/*
> +	 *	Setting a max_priority here prevents inheritance
> +	 *	from higher priority tasks to its threads.
> +	 *
> +	 *	BASEPRI_USER will be set nonetheless as it's the
> +	 *	default value of the task processor set.

This last comment is confusing, the reader is wondering where it will be
set.

Just making the field BASEPRI_SYSTEM and saying that it's a priori the
base max priority for thread is enough.

> +	 */
> +	thread_template.max_priority = 0;
>  /*	thread_template.sched_pri (later - compute_priority) */
>  #if	MACH_FIXPRI
>  	thread_template.sched_data = 0;
> -- 
> 2.53.0
> 
>