22 Mar 2008 (updated 2 Apr 2008 at 01:08 UTC)
»
What Would Rusty Say?
One of the many great things Rusty has done was introducing the Misuse Levels of APIs (in OLS 03 keynote, slide 30 and beyond). I had a run-in with something of that nature last week.
Here's an interface:
/**
* blk_end_request - Helper function for drivers to complete the request.
* @rq: the request being processed
* @error: 0 for success, < 0 for error
* @nr_bytes: number of bytes to complete
*
* Description:
* Ends I/O on a number of bytes attached to @rq.
* If @rq has leftover, sets it up for the next range of segments.
*
* Return:
* 0 - we are done with this request
* 1 - still buffers pending for this request
**/
int blk_end_request(struct request *rq, int error, unsigned int nr_bytes)
What do you think the "number of bytes to complete" is? It seemed natural to me that it's the number of bytes which was transferred (and thus, it can be smaller than the number of bytes remembered in the request). This is how I would design an API. But in this case, nr_bytes is the number of bytes which was in the request initially. As such, it is greater than the request->data_len, which drivers modify to indicate the residue.
I think this has something to do with Tomo's & Jens' desire to avoid modifying drivers which poke ->data_len today (indeed, the code doing so in ub remained unchanged). If so, the price is too steep, IMHO.
Curiously, the designers of the API themselves misused it when they converted ub. They called __blk_end_request() with and argument of blk_rq_bytes(rq), but since ub modifies ->data_len, it guaranteed a failure for packet requests.
Everything seems to be working now, but I suspect that 2.6.25 is going to ship with a broken ub (thank Chris Wright for the Stable Tree).
UPDATE: See also a blog article (same server, but helps if Rusty decides to reshuffle his home directory).
Syndicated 2008-03-22 04:49:37 (Updated 2008-04-02 00:22:24) from Pete Zaitcev
