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
@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
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 several
Following discussions which resulted from the:
[RFC] target code updates to support scanned targets
http://marc.theaimsgroup.com/?l=linux-scsim=110850749515984w=2
thread, the overall consensus seems to be that transport-classes
should support a 'true-hotplug' mechanism of device discovery and
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:
[RFC] target code updates to support scanned targets
http://marc.theaimsgroup.com
Following discussions which resulted from the:
[RFC] target code updates to support scanned targets
http://marc.theaimsgroup.com/?l=linux-scsim=110850749515984w=2
thread, the overall consensus seems to be that transport-classes
should support a 'true-hotplug' mechanism of device discovery and
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 LLDD
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 is needed
8 matches
Mail list logo
