Shared spinlocks

[Matthew Dillon]

:Hi,
:
:Why don't we have shared spinlocks anymore?
:
:Thanks,
:-- vs

    Sometimes excessive complexity leads to excessive confusion.
    The shared spinlocks were a pretty horrible hack that I added
    on an otherwise pristine mechanism.  There were severe limitations
    on recursive use.  The only thing that used them that was actually
    in the critical path was the file descriptor code and frankly I
    don't think there is much of a point when the lock is only held
    for a few instruction cycles anyway.  If it comes down to it there
    are faster ways to implement fast file descriptor lookups if we
    decide we really need it.

    If I reduce the spinlock code to just exclusive locks and get rid
    of the extending naming I think people will have an easier time
    using them properly.  Right now our biggest problem is that the
    spinlocks are not being used properly... they are not supposed to
    be held across any complex kernel procedure call (like kfree),
    or huge long chains of procedures (though we might not have a
    choice when it comes to syscons).

    Also our kern_mutex.c module has full read/write/chaining semantics
    and provides a similar interface.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>