I'm not hacking anything. Thanks for the inference, though. :)
|>So wouldn't it be more productive to get the kiovec to block device interface
|>working. You also btw do need to go via the ll_rw_block request queue at all
|>times. There is locking in that, there is request merging in that and there
|>is overlap handling in that.
I want to implement the same locking strategy _without_ going through
ll_rw_block(). That's the whole point -- I don't want to utilize that
function as a mechanism for writing to disk. If I used ll_rw_block(),
I might as well do that for all disk types. It's obviously the wrong
way to go in a system crash scenario, which is where I'm going to be
utilizing the code.
Very little matters about the disk queue if the system is crashing.
There's only so much you can do to save the data. Don't get me wrong,
I'm not saying "ignore what's in buffer cache", just that if this code
gets executed, it's very doubtful what was in the buffer cache really
would have ever made it to disk. You'll be "Oops" or "Aiee"ing.
|>If you queue a request when the driver knows the queue status or the plug
|>status you will change behaviours, and I doubt the ide layer will like it
Right; hence the reason for setting up the appropriate locking, and
using an entry function for start_request with the locking already
established. That way you emulate ll_rw_block() without all the
lock_buffer() stuff in the way (a la make_request()). If the buffer
cache code has a problem, and I use that same code to try and write the
dump, I'm toast. That's the wrong way to go.
Does that make sense?
|>Alan
--Matt
-
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/