On Mon, 18 Sep 2000, Alexander Viro wrote:
> >
> > but should instead be
> >
> > static int make_buffer_uptodate(struct page *page, struct buffer_head * bh)
> > {
> > if (Page_Uptodate(page)) {
> ^^^^^^^^^^^^^^^^^^^
> > set_bit(BH_Uptodate, &bh->b_state);
> > return;
> > }
> > ll_rw_block(READ, 1, &bh);
> > }
>
> > Forget about your "stage 1" and "stage 2" complications. They shouldn't
> ^^^^^^^^^^
> > exist.
>
> Erm...
No, but that's just because you _think_ about the problem the wrong way
around.
If you think about it like the above, it's not a "stage" at all. It's just
part of getting the buffer to be up-to-date.
Very logical, very simple, no "fscking mess" at all.
That's my argument. You're trying to make it a problem. It's not. It's
something new with the page cache, yes - the fact that the page cache
drives the logic means that the buffer "uptodate" logic is different, but
if you think about it some, you'll realize that that's actually just a
natural outgrowth of the fact that the buffer cache is slaved to the page
cache these days.
It's not a "stage 2". It's a basic fact of life - we don't care _how_ the
page got to be up-to-date, because for all we know there are other ways to
get it to be up-to-date than your "stage 1".
For example, a recvfile() implementation could mark the page up-to-date by
virtue of getting the information off the network. No "stage 1" or "stage
2" there at all: the make_buffer_uptodate() logic does _not_ mean that we
lost the buffers from "stage 1", it might equally well mean that we got
the page up-to-date through some other means.
Just change how you think about the problem, and suddenly it's not a mess,
it's a design.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:18 EST