Of course that is doable, when I killed scsi_dma.c it was just a direct
replacement. Given that IDE had no such dynamic sg list allocation
requirements, it stayed in SCSI. Overdesign is never good :)
> 2. Device locality awareness. Quite a bit of the esoteric SCSI queueing
> code occurs because we have two type of queue events:
> a. device can't accept another command---stop queue and restart when the
> device sends a completion back
This should be doable.
> b. the host adapter is out of resources for *all* its devices. Block
> all device queues until we free some resources (again, usually a
> returning command).
This is harder, because it involves more than one specific queue.
> 3. Perhaps some type of unified command handling. At the moment, we all
> seem to allocate DMA'able regions for our commands/taskfiles/whatever
> and attach them to reqest->special. Then we need to release them again
> before completing the request.
>
> 4. Same thing goes for sense buffers.
Completely agree.
> 5. There needs to be some amalgam of the SCSI code for dynamic tag
> command queue depth handling.
Again, block layer queueing was designed for what I needed (ide tcq) and
no overdesign was attempted. If you describe what you need, I'd be very
happy to oblige and add those bits. Some decent depth change handling, I
presume?
-- 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/