Well not really, DAC960 is still using the default per-major queues. But
switching to per-device queue would definitely be a Really Good Idea.
The only changes I did to this driver where trivial conversions in the
2.5.1-pre days, in fact even before multi-page bio's existed. This,
btw, is also something you should keep an eye out for -- multi-page bio
support is currently broken. I would suggest also moving DAC960 to the
pci dma api (this is a must) and then move it to use the generic block
helpers for mapping requests. That way there isn't a lot of nasty
duplication there as well, plus it will automatically get the multi-page
issues right.
> For those locks, I just removed the &'s, which seems like the right thing to
> do. The "Controller" lock really seems to be a request queue lock. Now I
> think I need to allocate and initialize a request queue, possibly in
> DAC960_CreateAuxiliaryStructures. Am I getting warm?
If you move the queues to be per-device, then yes you can use the
Controller lock for the queue lock as well. It was made that way for
easy conversions. So basically embed a request_queue_t inside the
DAC960_Controller_T (god damnit, I'm having a hard time even just
writing these ugly names down here :-) and do something ala
RequestQueue = = &Controller->ThisIsTheQueueYouAdded;
spin_lock_init(&Controller->ThisIsTheLockYouAdded);
blk_init_queue(RequestQueue, DAC960_RequestFunction, &Controller->ThisIsTheLockYouAdded);
RequestQueue->queuedata = Controller;
...
Hmm, is DAC960 using a full major per controller?!
But... This is the least of your worries. The major issue here is
updating it to the pci dma api. Once that is done, the rest is trivial
and will actually consist mainly of removing code, not adding.
-- Jens Axboe- 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/