Re: I request inclusion of reiser4 in the mainline kernel

Nikita Danilov
2005-09-30T17:27:09Z

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.