FreeBSD spinlock - compatibility layer

Julian Elischer julian at freebsd.org
Fri May 24 02:27:05 UTC 2013


On 5/22/13 11:15 PM, John Baldwin wrote:
> On Wednesday, May 22, 2013 9:27:16 am Alfred Perlstein wrote:
>> On 5/22/13 9:05 AM, John Baldwin wrote:
>>> Probably not.  For example, on FreeBSD you want your driver lock to be
>>> preempted by an interrupt to avoid higher interrupt latency for filter
>>> handlers.  Most drivers should not need temporary pinning.  If they want to
>>> pin work to threads they should bind threads or IRQs to specific CPUs, not
>>> rely on temporary pinning.
>>>
>> I know how it works in FreeBSD.
>>
>> I think that a compatibility layer should first and foremost aim for
>> compatibility, not speed at expense of expected semantics.
> The problem with this is that whatever code runs under this layer also has to
> cooperate with the rest of the system.  Blindly using spin locks does not do
> that.  Also, I think my entire point is about "expected semantics".  People
> should think about the actual semantics they need in a driver, not just assume
> that whatever side effects they get from the primitives and APIs provided on
> one platform defines the semantics they need.  I still assert that in terms of
> what a device driver actually expects, a regular mutex will provide the correct
> semantics.
>
in the *mumble* (company I worked for recently) compat layer, we used 
mutexes to
implement the "spinlock" that the linux driver used when it was run 
under FreeBSD..
It really didn't need a spinlock, it's just that by default linux 
drivers do/did so.



More information about the freebsd-arch mailing list