Bryan:
>> introduced, it was not practical to update every filesystem driver, so
the
>> Big Kernel Lock (BKL) was added to give those drivers the uninterrupted
>> access they (may) expect. You may surmise that a "lookup" routine
doesn't
>> need such uninterrupted access, but you can never really assume that.
>
Al:
>Now, now. BKL _is_ worth the removal. The thing being, "oh, we just take
>BKL, so we don't have to worry about SMP races" is wrong attitude.
Yeah, I agree. I took the question to be "why is the BKL there?" and "Can
we just remove the lock_kernel() from FS?", not "is the BKL shield the
best possible design for Linux?"
I'd like to see the single threaded guarantee to VFS routines revoked --
not only the UP side of it, but the non-preemption as well. I have always
been taught to assume that anything can happen between any two
instructions, or even in the middle of one, unless I explicitly lock
against it.
An "MP-safe" attribute that a filesystem driver can register for its VFS
routines would be a good tool to get there.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
