Re: [PATCH 2/2] export command allocation and freeing functions independently of the host

[Boaz Harrosh <bharrosh@panasas.com>]

On Thu, Mar 13 2008 at 20:20 +0200, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> On Thu, 2008-03-13 at 20:01 +0200, Boaz Harrosh wrote:
>> On Thu, Mar 13 2008 at 19:46 +0200, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>>> On Thu, 2008-03-13 at 19:39 +0200, Boaz Harrosh wrote:
>>>> On Thu, Mar 13 2008 at 18:53 +0200, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>>>> Looking long term. This will clash with Matthew Wilcox's effort of 
>>>> overridable per host command pool.
>>> Not really, since the design is to obtain commands outside of the normal
>>> host pool allocations for special purposes.  All that needs to be
>>> updated for the per host override is the setup and teardown path, which
>>> can be done in a few lines.
>>>
>> Again the concept was that an host might want a special size command for
>> the + host_priv additions that will get allocated once. This still applies
>> with "special purpose" commands, they need to be the size the host expects
>> them to be, so it can use container_of() macro to retrieve the real structure.
>> (Or any other dynamic size calculations)
> 
> Well, the currently presented interface is to tidy up the command use
> for precisely two drivers, neither of which seems to want to use special
> sized commands.  Even if that patch set were ready for merging (which it
> isn't), adding it to the command allocators with no users would still be
> over engineering.
> 
>>>>  I do have a scsi_host in the USB
>>>> initialization. Perhaps:
>>>>
>>>> +struct scsi_cmnd *scsi_allocate_command(struct Scsi_Host*, gfp_t gfp_mask);
>>>> +void scsi_free_command(gfp_t gfp_mask, struct scsi_cmnd *cmd);
>>> James
>>>
>> I guess it can change later when needed. Just that I wanted that new users of the
>> API get used to the need of an Scsi_Host
> 
> Yes, for just two users, particularly when there's doubt over whether
> they'd even need the potential feature set, simpler is better.
> 
> James
> 

Do you mean gdth? No I think gdth is not a user of this above new API.
gdth's patch I sent should be as it is.

I know of only one client of the new API presented here. isd200?

Boaz