Re: I request inclusion of reiser4 in the mainline kernel

[Nikita Danilov <nikita@clusterfs.com>]

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/