Re: [BK PATCHES] add ata scsi driver

Jens Axboe (axboe@suse.de)
Mon, 26 May 2003 20:18:52 +0200


On Mon, May 26 2003, James Bottomley wrote:
>
> On Mon, May 26 2003, Linus Torvalds wrote:
> > > What does the block layer need, that it doesn't have now?
> >
> > Exactly. I'd _love_ for people to really think about this.
>
> In discussion with Jeff, it seems most of what he wants is already
> there. He just doesn't know it yet :-)
>
> Maybe that's my problem as well, maybe the code / comments / doc /
> whatever is not clear enough.
>
> My wishlist for this would be:
>
> 1. Unified SG segment allocation. The SCSI layer currently has a
> mempool implementation to cope with this, is there a reason it can't
> become block generic?

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/