On Sat, May 25, 2002 at 01:40:34PM -0700, Jason R Thorpe wrote:
> On Sat, May 25, 2002 at 08:59:20PM +0100, David Laight wrote:
> 
>  > I found some problems with the 'solaris' semantics of saving the spl
>  > level within the mutex, the 'SVR4' semantics where the spl level
>  > is returned to the user are more flexible.
> 
> Some say "flexible", others say "error-prone".

Writing device drivers for SMP kernels is error-prone :-)
Anyone who suggests they can 'path test' such a beast needs
their head examined!  The only way you can fix lock related
bugs is to read the code until you find one, and hope it
fixes the problem you've got :-(

> 
>  > 	pl1 = read_lock( table_lock )
>  > 	entry = search_table( key );
>  > 	pl2 = lock( entry->lock );
>  > 	unlock( table_lock, pl2 );
actually you need curpl() here, not pl2.
>  > 	.....
>  > 	unlock( entry->lock, pl1 );
> 
> You can already do this with Solaris-style mutexes if they are adaptive
> mutexes.

I don't remember those being mentioned when we were writing solaris
drivers - for 2.5.1, OTOH we were doing without a solaris source
license - someone I knew at sun (later) wondered how we actually
managed it!

> Interrupt-blocking mutexes are meant to not be used that often
> in the Solaris kernel (and I happen to agree with their approach).

I guess this is because they try not to run any code in the actual
interrupt routine.  Almost everything requires a switch to one of
the kernel threads (leading to code that suspends one of the timer
threads until the other one wakes it up - really bad news if two
bits of code try that trick!).

The bummer with solaris locks/mutex was that you couldn't create
one that would disable interrupts unless you were a hardware
driver and had already attached the interrupt (otherwise you
didn't have the right cookie) - rather problematical...
Especially for code that might just be called from an
interrupt routine.

Oh, will a netbsd splnet() ever enable interupts?
(eg if called after splhi())

	David

-- 
David Laight: david@l8s.co.uk