On Wed, 2006-02-08 at 09:56 +0100, Jens Axboe wrote: > Hmm, this (and further up) could fail, yet you don't check. By and large, you have process context, so this isn't going to be a problem. > I don't think this API is very nice to be honest, there's no good way to > handle failures - you can't just sleep and loop retry the execute if you > are in_interrupt(). I'd prefer passing in a work_queue_work (with a > better name :-) that has been allocated at a reliable time during > initialization. Yes, I agree ... however, the failure is less prevalent in the new code than the old. The problem is that we may need to execute multiple puts for a single target from irq contex, so under this scheme you need a wqw (potentially) for every get. I could solve this by binding the API more tightly into the device model, so the generic device contains the wqw and it is told that the release function of the final put must be called in process context, but that's an awful lot of code changes. James - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
