Subject: Re: [BK PATCHES] add ata scsi driver
From: James Bottomley <James.Bottomley@steeleye.com>
To: Jens Axboe <axboe@suse.de>
Cc: torvalds@transmeta.com, Linux Kernel <linux-kernel@vger.kernel.org>
In-Reply-To: <20030526181852.GL845@suse.de>
References: <1053972773.2298.177.camel@mulgrave> 
	<20030526181852.GL845@suse.de>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 26 May 2003 14:47:08 -0400
Message-Id: <1053974830.1768.190.camel@mulgrave>
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1834
Lines: 45

On Mon, 2003-05-26 at 14:18, Jens Axboe wrote:
> > 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 :)

I agree with the sentiment.  I just don't think variable size SG tables
will remain the exclusive province of SCSI forever.

> > 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.

Yes, this is our nastycase, especially for locking and ref
counting...you didn't say I only had to hand off the easy problems,
though...

Hotpluggin has to have some awareness of this locality too.  Even for
IDE, hot unplug a card and you can lose two devices per cable.

> > 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?

Pretty much yes, now.  We lost all of our memory allocation nightmare
problems when we moved away from fixed command queues per device to lazy
command allocation using slabs.

James


-
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/