* Waiman Long<waiman.long@xxxxxx> wrote:
Well, as I pointed it out to you during review, such a Kconfig drivenI think Waiman's patches (even the later ones) made the queued rwlocksIt is not actually a side-by-side implementation. A user can choose
be a side-by-side implementation with the old rwlocks, and I think
that was just being unnecessarily careful. It might be useful for
testing to have a config option to switch between the two, but we
might as well go all the way.
either regular rwlock or the queue one, but never both by setting a
configuration parameter. However, I now think that maybe we should do it
the lockref way by pre-determining it on a per-architecture level
without user visible configuration option.
locking API choice is a no-go!
What I suggested instead: there's absolutely no problem with providing a
better rwlock_t implementation, backed with numbers and all that.
Thanks,
Ingo