Well - depends on what the semantics of scan_start are.... to date, there
really are none.... and what does requiring it mean ?
What's implied is that you want "bring up link" to be enabled in scan_start().
Doable, but the code paths weren't put together expecting this, so it may be
a bit of work. I'll have to look at it. Also, you're asking me to fix one
driver, without thinking about the structure in others.... I'd rather the
api itself locked down state/behavior, not simply the LLD coding.
Before starting, I'd rather we setting on what the semantics of the api is.
To the uninitiated, requiring a driver to call scsi_scan_host(), when the
transport drives all discovery, and where the scan_host really has nothing
to do with scanning, but rather creates a firewall delay to hold off serializing
of device enumerations - is all very confusing. I'd rather we had a different
entry point for those things that supply start/finish routines and it was
named more in line with "start discovery delay".
Adding the notion of scan_start bringing up the link sounds reasonable. However,
how does this translate to other bus types ?
-- james s
Matthew Wilcox wrote:
On Mon, Aug 20, 2007 at 09:10:35AM -0400, James Smart wrote:
In testing 2.6.23-rc3, there is a small window where the async-per-target
scan of the transport can beat the call from the LLDD to scsi_scan_host().
I'd assumed that events wouldn't come in until ->scan_start was called.
I see lpfc doesn't have one; is it possible to restructure it to have one?
(In any case, good job tracking this down; it was really annoying me.)
Possibly we should be less forgiving, and require drivers to have a
scan_start, otherwise they can't avoid this race.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
