No.
The code is much simpler and much more straightforward, and it makes
sense. No "tricks" involved.
See it my way:
- I have simpler code, with one less made-up bit of information. If you
look at the patches, you'll notice that NOTHING actually ever needs to
test the above combination - it just falls out as the natural
behaviour.
vs
- more complex code, with more state, that doesn't give anything new and
adds more rules that have to be tested for.
So obviously I'll drop the BH_Hole bit - it isn't buying us anything at
all, and it _is_ setting us up for coherency problems.
> !Mapped && Uptodate && !Dirty can be a valid combination
> in the future as well - we might want to destroy buffer-heads (the
> mapping) under a data block for legitimate reasons, eg. in the future it
> might be possible to move the device under a filesystem, or we simply have
> a filesystem with nonpermanent mappings, eg. a filesystem might choose to
> destroy the mapping after the IO has been finished.
I'll believe you when I see it. My motto is: never overdesign. It sounds
like you're making up reasons to overdesign something that isn't needed.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/