Re: [RFC 1/2] scsi core: alloc_cmnd

[Boaz Harrosh <bharrosh@panasas.com>]

On Fri, Oct 19 2007 at 20:33 +0200, Matthew Wilcox <matthew@wil.cx> wrote:
> This fairly naive patch introduces alloc_cmnd and destroy_cmnd.  I'm not
> exactly happy about passing down the gfp_mask -- I'd prefer to be able
> to allocate scsi_cmnds before we grab the queue_lock (and hence get
> rid of the possibility we might need to GFP_ATOMIC), but I don't see
> anywhere to do that.  Maybe there's a simple change we can make to the
> block layer to allow it.
> 
> Merely-an-RFC-by: Matthew Wilcox <willy@linux.intel.com>

You know Matthew when you first talked about this, I envisioned
something else.

My idea was to have a new variable in scsi_host_template that states
the host_cmnd_extra_bytes. The mid-layer allocates a mempool with
sizeof(struct scsi_cmnd) + host_cmnd_extra_bytes.
A utility function will return that space for drivers given
a cmnd like:
void *host_cmnd_priv(struct scsi_cmnd *cmd)
{
	return cmd + 1;
}

This serves the drivers well because all they need to do is set
host_cmnd_extra_bytes = size_of(my_cmnd_stuff) and start using
it. much more simple than setting up cache pools. It also keeps
the Q per host vs Q per driver.

This also solves your problem with locks and allocation flags
since nothing changes, and it is all private to the mid-layer.

And it serves me, because when bidi comes I just do:
sizeof(struct scsi_cmnd) + host_cmnd_extra_bytes + sizeof(bidi_stuff)
for hosts that support bidi. And the rest of the work was done by you.

Do you need that I scribble some tryout patch for above + example driver

Thanks for doing this
Boaz