[lkml]   [2001]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subjectcreate_bounce() in ll_rw_blk.c
In ll_rw_blk.c's __make_request() there is a call to create_bounce() if
CONFIG_HIGHMEM is set. The commentary in that file indicates that this is a
temporary fix until 2.5 at which point this would be removed in favour of
individual drivers handling this on their own. I've been trying to figure out
if a driver I'm working on needs to make this call. That got me wondering...

Is there a reason for pushing this down onto the individual driver writer
instead of placing it once and for all in the ll_rw_block() function like:

--- linux-2.4.8/drivers/block/ll_rw_blk.c.orig Wed Aug 15 22:15:55 2001
+++ linux-2.4.8/drivers/block/ll_rw_blk.c Wed Aug 15 22:39:55 2001
@@ -1000,6 +1000,10 @@
/* Verify requested block sizes. */
for (i = 0; i < nr; i++) {
struct buffer_head *bh = bhs[i];
+ bh = create_bounce(rw, bh);
+ bhs[i] = &bh;
if (bh->b_size % correct_size) {
printk(KERN_NOTICE "ll_rw_block: device %s: "
"only %d-char blocks implemented (%u)\n",
Since the commentary says the driver writer taking HIGHMEM into
account could call either create_bounce() or bh_kmap() and the latter
deals with bh->b_data, is this something you need to do only if you're
accessing bh->b_data? In that case putting the work on the driver writer
allows for it to only be done when needed, but are there cases were a
buffer_head would pass down out of ll_rw_block() towards a driver that's
not ultimately going to read or write the b_data member?

I don't know how all the HIGHMEM/PAE stuff actually works, but I'm
guessing that if the heavy handed create_bounce() exists that is because
simply doing a bh_kmap() and replacing the bh->b_data at ll_rw_block()
time doesn't result in a memory address that would work in the drivers'
context? So to get the efficiency of bh_kmap() over create_bounce()
you'd have to put the calls in all the drivers?

And since create_bounce() stores the original bh in bh->b_private is this
all magically undone then as nested bh->b_end_io's and bh->b_private's
unfold themselves with either of bounce_end_io_read() or _write() being
called somewhere in there?

Anybody care to comment?


* tpepper@vato dot org * Venimus, Vidimus, *
* * Dolavimus *
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at
 \ /
  Last update: 2005-03-22 12:57    [W:0.087 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site