Subject: Re: SCHED_LOCK(9)?
To: None <tech-kern@netbsd.org>
From: Andrew Doran <ad@netbsd.org>
List: tech-kern
Date: 04/21/2007 14:01:13
Hi Oliver,

On Fri, Apr 20, 2007 at 11:26:36PM -0400, Oliver Gould wrote:

> kqemu_schedule() is more-or-less the old sys/kern/kern_synch.c:yield()-
> except KQEMU wants to prioritize itself.  Eg:
> 
>   int
>   kqemu_schedule(void)
>   {
>         struct lwp *l;
>         int s;
> 
>         l = curlwp;
> 
>         s = SCHED_LOCK();
>         l->l_priority = MAXPRI;
>         l->l_stat = LSRUN;
>         setrunqueue(l);
>         l->l_proc->p_stats->p_ru.ru_nvcsw++;
>         mi_switch(l, NULL);
>         splx(s);
> 
>         return issignal(curlwp) != 0;
>   }
> 
> 
> Will mimicking the new yield() work similarly?

Yup, with l->l_usrpri replaced with MAXPRI. The call to issignal() needs the
process' signal state locked. For now issignal() also needs the kernel_lock
held as it may free memory. If you're sure that keqmu_schedule() will only
ever be called with the kernel_lock held then the following will work:

	KERNEL_LOCK(l->l_biglocks, l);
	mutex_enter(&p->p_smutex);
	sig = issignal(l);
	mutex_exit(&p->p_smutex);

	return sig != 0;

I'm curious what it uses the return value for, but the above seems to match
what keqmu_schedule() does for FreeBSD.

Andrew