On Mon, 6 Mar 2000, Alexander Viro wrote:
>> head_active drivers could have no knowledge at all about merging an
>> end_request could do all the work as it does when there's an error.
>
>It's not about merging (and predates it, BTW). Just that if request covers
>several sectors (block size > 512, absolutely common situation) you _have_
>to keep track of the sector number and memory address. And it's either
>global variables <bletch>, or allocating structures and storing this thing
>there (allocating... deep in the IO path? could you spell "deadlocks"?)
>_or_ using the request fields.
I think the >512 sector request handling should be done with a precise
field in the request that is declared as clobbered (req->sector should
remains read_only, writeable only by the highlevel layer in the common
usage). A new req->driver_sector will be set by the highlevel layer always
correctly (also from end_request) and the lowlevel layer can
advance/overwrite it to do the larger block handling.
>> If we want to provide backwards compatibility we must add a
>> "merging" field in the blk_dev_struct and skip the merging path if it's
>> set to zero.
>
> Yeah, and we both know how Linus reacts to such ideas. Frankly, I
>understand him very well on that - it's _the_ way to nightmarish code.
NOTE: I wasn't proposing that ;). I was instead proposing to fixup the
end_request semantics so that to get simple drivers fixed automatically
without braindamage ;). Unfortunately it wasn't so trivial as I thought at
first and I didn't gone into that cleanup seriously yet (I timed out while
reading the floppy driver precisely... ;).
>OK, so where do you keep the current sector number during the IO for
>multi-sector bh? [..]
A new:
req->driver_sector
will do the trick.
It will work exactly as req->buffer is _just_ currently working.
As req->buffer it will be clobbered by lowlevel driver across request_fn
and end_request and get set correctly by the highlevel layer before
calling request_fn and after each end_request.
Or another option is to left req->sector to the lowlevel layer and add a
new req->rq_sector or whatever else name for the highlevel accounting.
Drivers like loop and nbd won't need dirty hacks then (as they just don't
need dirty hacks for advancing req->buffer before calling end_request even
if req->buffer is advanced exactly like req->sector by hd.c).
Andrea
-
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/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:20 EST