>From: Luben Tuikov [mailto:[EMAIL PROTECTED]
>>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/0
On Wed, 09 Mar 2005, [EMAIL PROTECTED] wrote:
>
> So, is there a reason we aren't just starting the workq thread
> upon the first call to queue something to it ?
>
I don't see any reason why that approach wouldn't work in this
circumstance..
--
av
-
To unsubscribe from this list: send the line
t, 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 thoug
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 dis
On Sat, 05 Mar 2005, [EMAIL PROTECTED] wrote:
> I've attached a revised patch.
>
> One other note:
> > scsi_scan_target(&rport->dev, rport->channel,
> > rport->scsi_target_id, SCAN_WILD_CARD, 0);
>
> The rescan flag should be 1, not 0. If 0, all kinds of bad thing
On Sat, 05 Mar 2005, [EMAIL PROTECTED] wrote:
> In thinking this through a little further - if the workq is just
> for the transport, the transport ought to simply create and use
> the workq. There would be no need to modify the host structure.
>
> If we're trying to avoid the potential for sever
ECTED] Behalf Of Smart, James
> Sent: Saturday, March 05, 2005 8:08 AM
> To: [EMAIL PROTECTED]; linux-scsi@vger.kernel.org
> Subject: RE: [RFC] adding per scsi-host workqueues for defered
> processing
>
>
> >Following discussions which resulted from the:
> >
>
>Following discussions which resulted from the:
>
>[RFC] target code updates to support scanned targets
>http://marc.theaimsgroup.com/?l=linux-scsi&m=110850749515984&w=2
>
>thread, the overall consensus seems to be that transport-classes
>should support a 'true-hotplug' mechanism of device discover
> >
> > I'd like to propose the addition of a per-Scsi_Host work-queue to
> > manage these scanning as well as any other (relevant)
> > lower-level-driver differed requests.
>
> Why not use the per-host error handler thread for this?
brings a deadlock condition to mind - where the error thread i
On Mon, Feb 21, 2005 at 04:09:37PM -0800, Andrew Vasquez wrote:
> * must be done from process context -- depending on transport type,
> discovery can occur from a non-process context
> * potentially _long_ scan times -- even if discovery is done from a
> 'sleeping' capable context, halting a LL
Following discussions which resulted from the:
[RFC] target code updates to support scanned targets
http://marc.theaimsgroup.com/?l=linux-scsi&m=110850749515984&w=2
thread, the overall consensus seems to be that transport-classes
should support a 'true-hotplug' mechanism of device discovery and
r
11 matches
Mail list logo
