On Mon, Oct 25, 2010 at 1:04 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > On Mon, 25 Oct 2010, Thomas Gleixner wrote: >> On Mon, 25 Oct 2010, Nick Piggin wrote: >> > Although a sane locking macro and structure like I had, would perfectly >> > allow you to switch locks in a single place just the same. >> >> And a locking macro/structure is better in self documenting than a >> helper function which was proposed by Christoph? > > Independently of what data structure you folks agree on, we really do > _NOT_ want to have open coded bit_spin_*lock() anywhere in the code. > > As I said before, aside of RT it's a basic requirement to switch bit > spinlocks to real ones for lockdep debugging. Putting it in hlist_bl locking function doesn't do much to help -- putting mutexes or spinlocks into hlist hashes is insane. What might be good is to have a bit spinlock structure which is 0 size in a normal config, but it can hold things like lockdep data. Someone posted a patch maybe a year ago to do that, which I thought was good but I don't know why it didn't go anywhere. It still doesn't solve your -rt problem really, because on a production rt build like I say, you can't blindly just replace bit spinlocks with mutexes. But it makes lockdep work and could take care of *some* bit spinlocks for -rt. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
