Why? It's not enough to say that the capability, even in a primitive
form, can't be added. Technically, if you set up a request properly in
the call to a function like start_request(), by configuring the
(ide_drive_t *)drive->queue with a generic unused buffer, with a copy
of memory in it, it should work. If you know why it technically shouldn't
be done, such as an IDE limitation, then I'd stop working on it ...
My questions relate to locking, what entry function to use, etc. If
one function over another makes more sense from a locking standpoint,
I'd rather know that instead of inadvertantly cause locking grief to
myself later.
The big key is avoiding utilizing the buffer cache for the disk write,
and since it's going to a raw partition anyway ... this should be a
straightfoward implementation.
|>Post 2.4 there are lots of related things to sort out - passing kiovecs to
|>block devices, 32bit bounce buffers, and the like. If you had a queue-kiovec
|>ability then your raw device would be trivial.
Agreed, doing this in post-2.4 will be much simpler, but it doesn't
make sense to not do it now "just because" ...
--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/