Re: [RFC] adding per scsi-host workqueues for defered processing

[Brian King <brking@us.ibm.com>]

James.Smart@Emulex.Com wrote:
> So, is there a reason we aren't just starting the workq thread
> upon the first call to queue something to it ?

Don't you need to be at task level to create a workq thread?

-Brian


> -- james s
> 
> 
>>-----Original Message-----
>>From: Luben Tuikov [mailto:luben_tuikov@adaptec.com]
>>Sent: Tuesday, March 08, 2005 8:12 AM
>>To: Andrew Vasquez
>>Cc: Smart, James; linux-scsi@vger.kernel.org
>>Subject: Re: [RFC] adding per scsi-host workqueues for defered
>>processing
>>
>>
>>On 03/08/05 02:00, Andrew Vasquez wrote:
>>
>>>There were some background tasks I shelved until the remote-ports
>>>stuff settled down which I thought could use the deferred processing
>>>thread:
>>>
>>>* Initiate LIP -- several customers have asked for this ability as
>>>  several topological configurations isolate disruptive FC events.
>>>* Initiate LLDD rescan (i.e. ports (fibre channel), devices (iSCSI),
>>>  etc.)
>>>
>>>I had originally envisioned these functions residing in the 
>>
>>transport.
>>
>>Yes, I agree.  Domain (target, topology, etc) discovery should be
>>"part" of the transport class.
>>
>>What I'm thinking of is that the LLDD would register a known
>>trasport class with the SCSI Core at/after registering a host
>>template and then would call something with a name like
>>"start_scsi" which would do whatever necessary for the domain
>>(SAS, FC, iSCSI, etc) before scanning for targets.  Of course
>>for some domains no additional work is needed.
>>
>>	Luben
>>
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center