On Tue, 5 Sep 2000, Linus Torvalds wrote:
> We just grab the page, populate it with buffers if required, and find the
> one buffer that we need to clear out. We clear it out and mark it dirty.
> End of story.
>
> NOTE: Udo, because I haven't actually tested this (it may not actually
> compile etc small details), you probably shouldn't actually test this out
> as-is unless you are _really_ daring and don't mind fixing up after me.
> It's more a "this is how it should work" kind of thing.
>
> Al? Mind giving it a quick look?
It looks OK, except for the following (issues are actually common to
all block_... functions):
* if we ever do allocation unit != IO block size (have to do it on
UFS, probably want it on ext2 to break 4Kb limit) we'll have to deal with
more than one block. Not a big deal, but worth getting it right
* "make sure that ->buffers is there and map the buffers in given
range" is too fscking common and deserves a function of its own.
* with some filesystems we really want an analog of get_block()
acting on array. Aside of UFS, FAT-derived filesystems are obvious candidates.
I mean, WTF? Why bother recalculating the thing if allocation unit is larger
than IO unit?
I'll play with #2 and see what can be done there. I have a funny
feeling that lots of things will merrily factor out, so we may end up with
ability to do 10-liner transition to kiobuf whenever we will decide to do
it.
BTW, Jeff's complaint about size restriction in ll_rw_block() is
valid. It made sense when we used the thing only for buffer-cache, but
these days it looks bogus. It doesn't work as alias-prevention anymore, so
there's little point in doing it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
