Re: [BK PATCHES] add ata scsi driver

[Jens Axboe (axboe@suse.de)]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/