locking in a device driver

[M. Warner Losh]

In message: <4360DD7B.20900 at samsco.org>
            Scott Long <scottl at samsco.org> writes:
: Dinesh Nair wrote:
: > 
: > carrying on this discussion, what would be a good locking mechanism to 
: > use to protect tsleep() and other sensitive areas in a driver in freebsd 
: > 4.x ?
: > 
: > the current code for the driver in 5.x uses mtx_lock and mtx_unlock with 
: > some parts even being protected by mtx_lock(&Giant).
: > 
: > would the use of simple_lock() or s_lock() do, given that 
: > SIMPLELOCK_DEBUG was defined in the 4.x kernel ?
: >
: > the mechanism is actually a pseudo device driver which communicates with 
: > the real device driver. the pseudo device driver creates a bunch of 
: > /dev/ devices which the userland reads/writes to, and the pseudo device 
: > driver then places data in a few buffers.
: > 
: > the real device driver then reads these buffers and uses busdma to send 
: > the data to the device. reading is done by using busdma to read from the 
: > device and then placing the data in these buffers for the pseudo device 
: > to return to the userland process.
: > 
: > locking in the real device driver uses splhigh/splx, but what locking 
: > should be used in the pseudo device driver ?
: > 
: 
: If you need to protect your pseudodriver from being interrupted by the
: real driver then you'll need to use the same spl() as the driver.  Note
: that you shouldn't be using splhigh() unless you really know what you
: are doing.  Other than that, there likely isn't anything that you need
: to do for 'locking' in 4.x.  The kernel is non-reentrant there, so you
: don't need to worry about synchronizing multiple threads.

One thing to also bear in mind is that in 4.x spl locking is a code
lock.  It keeps multiple 'threads' of execution from entering a block
of code.  mutexes in -current are data locks.  While usually one can
think of the two the same, it can trip the unweary up.

Locking in 4.x is indeed much simpler.

Warner