`Linus Torvalds wrote:> > On Mon, 18 Sep 2000, Alexander Viro wrote:> >       * we have several bh state components and the thing is a big,> > fscking mess. If we look at the areas outside of the page lock we have:> > It's not a mess at all.> > I don't see why you call things "first stage" etc. It's perfectly> straightforward. There are two bits that matter:>  - buffer uptodate>  - buffer mapped.> > And the state is very clear and unambiguous:> >         Mapped, Uptodate: regular block>         !Mapped, Uptodate: hole of zeroes>         Mapped, !Uptodate: unread>         !Mapped, !Uptodate: "pending map"> > No "several states" at all.The more I think about it the less clear and ambiguous I find it. When you add the dirty bit into the pot you get:	 Mapped,  Uptodate,  Dirty:  not possible	!Mapped,  Uptodate,  Dirty:  not possible	 Mapped, !Uptodate,  Dirty:  pending write	!Mapped, !Uptodate,  Dirty:  pending map and write	 Mapped,  Uptodate, !Dirty:  regular block	!Mapped,  Uptodate, !Dirty:  hole of zeroes	 Mapped, !Uptodate, !Dirty:  unread	!Mapped, !Uptodate, !Dirty:  pending mapThose two 'not possible' states bother me, they show that the threebits are not orthogonal.  We can make arbitrary assignments of meaningto them as you did with !Mapped, !Uptodate (pending map) but in thatcase why not just enumerate all the states we need and lose the bitassignments?  I think the deep problem here is trying to look at thisas a bit-flipping problem instead of a state-transition problem.I'm not saying that the current design can't be made to work.  It can,it's practically working now - it's just confusing as Al said, andthere are reasons for that.  It gets more confusing when you add inthe less-than-simple relationship between buffers and pages and thentry to make sense of the combination of the two sets of states.  Themotivation for making this less confusing is to be able to think aboutoptimization possibilities instead of just making it work.--Daniel-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgPlease read the FAQ at http://www.tux.org/lkml/`