On 19 Feb 2002, Steve Lord wrote:
> Al, I am not proposing this to go in, but what is your opinion on a
> change like this? XFS does not need the BKL at all, so for some aim7
> experiments on large systems this patch was used to bypass the BKL for
> filesystems which state they can live without it:
> +#define lock_kernel_optional(ip) \
> + if (!(ip->i_flags & S_NOBKL)) lock_kernel()
> +
Denied. No way in hell that (or similar) will ever go in. Locking must
be consistent, _period_. No provisions for "legacy drivers" and crap
like that - it's a standard policy in all kernel and that had been discussed
a lot of times.
_Please_, check 2.5. We already don't take BKL on majority of directory
operations. The rest will follow pretty soon.
In particular, in current Linus' tree there are 3 (three) instances of
lock_kernel() in fs/namei.c. Namely, ->permission() and two calls of
d_move(). The latter will go when ->d_parent mess is cleaned up. The
former will go as soon as we get to ->setattr()/->permission() cleanups -
hopefully in a week or so.
In general, such changes are done by global lock shifting - simultaneous
for all instances and being a trivial search-and-replace. Once the lock
is taken inside the method individual filesystems/drivers/etc. can
shrink the protected areas - in separate patches.
That's how it works - and that's how it had been done for most of the methods
already. Magic flags that make locking different for different instances
are Not Good. And not needed - see above for the usual way to do that stuff.
-
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/
This archive was generated by hypermail 2b29 : Sat Feb 23 2002 - 21:00:20 EST