lkml.org 
[lkml]   [2000]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectQ: Block drivers and the io_request_lock
From
Date
I've been digging my way through the block layer as part of the device
driver book project. I believe I've got most of it figured out, but
there's a couple of things I would like to verify. Many thanks to anybody
who feels like helping out.

The request method in a block driver should, it would seem, drop the
io_request_lock once it has pulled the request(s) off the queue and is
ready to get down to work. That's not too hard to understand. But then...

- Once the lock has been dropped, it would seem that nothing prevents
the system from calling _request() again, should more requests be added
to the queue - perhaps even when the first invocation is still running.
Correct?

- Multiple invocations could also happen if the request method simply
returns without completing the request(s).

- It seems that you need to reacquire the lock before calling end_request,
especially if the active request is still on the queue. Certainly some
of the functions that get called want the lock to be held. But some
drivers (i.e. floppy) do not reacquire the lock, which makes me wonder.

- It would appear that _request() should not sleep, even if you don't call
it from your interrupt handler, for a number of reasons.

- As far as I can tell, the only reason to put your gendisk structure on
the list at gendisk_head is to have it show up in /proc/partitions.
Correct?

Finally, is there any problem if a block driver plugs its own queue as a
simple-minded way of avoiding reentrant _request() calls? (Yes, I agree
there are probably better ways...).

Thanks,

jon

Jonathan Corbet
Executive editor, LWN.net
corbet@eklektix.com

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.188 / U:1.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site