[I hope the following comments are not misplaced: I picked up this
thread half way through, and I didn't read the code...]
Presumably the only reason you want a spin lock is because drivers
may be walking the list in interrupt context when the time comes
to add/remove a member. My first comment is: what are drivers
doing walking this list anyway? Shouldn't it be private to the ATM
layer? Drivers can maintain their own list if they need one. My
second comment is that the ATM layer should never need to take
the spinlock itself when walking the list (I'm guessing it always
walks the list in process context). You could have the following
setup: list protected by a semaphore and a spinlock.
Deleting a member does the following:
acquire the semaphore
...
take the spinlock
delete the member
release the spinlock
...
release the semaphore
Adding a member does the following:
acquire the semaphore
...
take the spinlock
add the member
release the spinlock
...
release the semaphore
Walking the list in process context does:
acquire the semaphore
walk the list doing stuff
release the semaphore
Walking the list in interrupt context does:
acquire the spinlock
walk the list doing stuff that can't sleep
release the spinlock
Of course the semaphore could be used as a "big device lock",
not just a list lock.
Duncan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/