On Fri, 8 Jun 2001, Steve Lord wrote:
> If the vfs level code in something like the lookup path was thread safe,
> then rather than the grab lock/release lock, do the work, grab lock/release
> lock sequence, would it be better to add something to allow the vfs
> code to not grab the lock for filesystems which indicate this is a safe
> thing to do? Some sort of mask in the superblock would be one way to
> do this. That way the lock could be totally avoided, and individual
> filesystems which need the BKL could be tackled one at a time. I would
> have to rely on Al to say which of the VFS level operations still using
> the BKL have the potential to be changed in this way.
Bad idea. It had been tried (not in VFS) and it had always lead to mess.
Callee informing the caller which locks should be taken seems to be
attractive way to maintain compatibility. No arguments here. But this
strategy always backfires. You end up with more and more complicated
logics in callers and sooner or later you get a code that is impossible
to debug. Moreover, it complicates the life for the callee - instead of
uniform locking rules you get a mess. People _do_ cut'n'paste writing.
And having different templates to copy from, each with its own kind of
locking warranties is a way to madness.
I've seen such attempts in many projects. It had backfired in all cases,
regardless of language, userland vs. kernel, etc.
Standing policy in Linux: in case of API change do it for all instances
at once. Explicitly stated by Linus. Many times.
In case of locking it means global search for all instances of given
method and shifting the lock into them. Then individual instances can
do whatever they like. We had pulled that off for character devices -
compared to that filesystems are easy. Moreover, on the VFS side
everything is ready for such shift - BKL is taken just before and
dropped immediately after the calls in question. So shifting it
is a simple matter of grep.
However, such shifting is a 2.5 fodder - it doesn't fix any bugs, so
it has no place in -STABLE.
PS: before anyone starts the flamewar on backwards compatible interfaces
and being friendly to 3rd-party code - take it with Linus. Preferably -
in private email to avoid lists pollution. It had been beaten to death.
Many times. Short summary:
* in -STABLE we can change API if it is needed to fix bugs
* in -CURRENT everything is fair game
* locking rules for filesystems are documented in
Documentation/filesystems/Locking and anyone making a change in that area
is expected to update that file.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
