FreeBSD spinlock - compatibility layer

[Warner Losh]

On May 22, 2013, at 12:14 AM, Orit Moskovich wrote:

> From what I've read in "FreeBSD - device drivers" book by Joseph Kong on interrupt handling, you cannot voluntarily context switch (that is, sleep) in interrupt threads .

In ithreads, the interrupt thread context, you can voluntarily context switch. In a interrupt filter you can't, but that's because you are running in an interrupt context. Please note that an interrupt context and an interrupt thread context are different things.

> In any case, I think that the functionality of spin mutex should remain as is, and not modified to sleep mutex, as it can be used in places that sleep mustn't be used, or that require the properties of the spin due to performance considerations.

The linux compat layer is just for the oled stuff. It isn't intended to be a complete 'drop in' replacement environment for Linux drivers. Anything at odds with this basic purpose is unlikely to happen.

Warner

> 
> 
> -----Original Message-----
> From: John Baldwin [mailto:jhb at freebsd.org] 
> Sent: Tuesday, May 21, 2013 10:02 PM
> To: Orit Moskovich
> Cc: freebsd-arch at freebsd.org
> Subject: Re: FreeBSD spinlock - compatibility layer
> 
> On Tuesday, May 21, 2013 12:36:38 am Orit Moskovich wrote:
>> That's not the case when using taskqueues for deferring  execution of 
>> an
> interrupt handler.
>> Tasks can be delayed using the global taskqueue taskqueue_swi, which
> executes its tasks in the context of an interrupt.
>> In this case sleep is forbidden, and using spin mutex is not (although 
>> might
> be not recommended).
> 
> No, swi's run in an interrupt thread, and interrupt threads can use regular mutexes.  (That is why they run in a thread context.)  The only way you can run in a context requiring a spin lock in a driver is to use an interrupt filter.
> 
> --
> John Baldwin
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"