Messages in this thread | | | From | Nikita Danilov <> | Date | Fri, 30 Sep 2005 21:27:20 +0400 | Subject | Re: I request inclusion of reiser4 in the mainline kernel |
| |
Vladimir V. Saveliev writes: > Hello > > Christoph Hellwig wrote: > > ... > > Looking at the actual code all these point to the spin lock obsufcation > > SPIN_LOCK_FUNCTIONS/RW_LOCK_FUNCTIONS from spin_macros.h which I told > > to get rid of in the first round of reviews. > > ... > > reiser4 spinlock macros provide following functionality: > > (1) encapsulation of locks: instead of writing spin_lock(&obj->lock), > where obj is object of type foo, one writes spin_lock_foo(obj). > > (2) keeping information about number of locks of particular type currently > held by thread > > (3) checking that locks are acquired in the proper order. > > (4) collection of spin lock contention statistics > > > I agree that (1) is not very necessary. (2) and (4) helped a lot in early > debugging. Now we are about to remove it.
This was already discussed during earlier attempts to merge reiser4. The proper solution purportedly is to make useful features of reiser4 spin-lock code generic and merge them so that the rest of kernel can enjoy their superiority.
> > However, we would prefer to keep (3). It makes catching spinlock deadlocks very > easy. Don't you think that makes sence?
Lock-ordering monitoring was _immensely_ useful. For one thing it forces one to have complete and up to date description of lock ordering.
> > Thanks
Nikita. - 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/
| |