Well - OK it's maybe not obvious. So let me please explain: What I have
in mind is...
1. It doesn't harm and it's a matter of completeness ...
(brain -pedantic)
2. QUEUE_FLAG_STOPPED would suddenly do the same trick as IDE_BUSY does
now and I could just do blk_start_queue() in timout and IRQ handlers in
IDE. This would bring the "driver in question" in line with all the
other drivers out there, which indeed do just that instead of explicite
recurrsion in to the request handler...
3. The while(test_and_set_bit(IDE_BUSY, ... ) on do_ide_request entry
could simply go away... and we would have just do_request() left.
4. I worry a bit how this interacts with tcq.c
5. I observed the BUG() during transfers running from one queue to
another comented as by you:
/* There's a small window between where the queue could be
* replugged while we are in here when using tcq (in which case
* the queue is probably empty anyways...), so check and leave
* if appropriate. When not using tcq, this is still a severe
* BUG!
*/
in do_request() on a system with enabled preemption and without TCQ
enabled. And I think that the above would plug the possibility of it to
happen. (Tought here I have to think harder.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/