--- Tejun Heo <htejun@gmail.com> wrote:

Christoph Hellwig wrote:

quoted

On Mon, Jan 23, 2006 at 05:20:42PM +0900, Tejun Heo wrote:

quoted

Arjan van de Ven wrote:

quoted

On Mon, 2006-01-23 at 13:09 +0900, Tejun Heo wrote:

quoted

Export two SCSI EH command handling functions.  To be used by libata EH.

since these are pretty much internal, can we make these _GPL exports?

It's SCSI developers' decision.  I chose EXPORT_SYMBOL because all other
exported symbols in scsi_error.c were using it.  James?

These are internal functions.  If we're going to export them at all then
as _GPL (which is grossly misnamed and should be _INTERNAL)

And from the other thread created by my mistake.

 > What do you need it for?  Please send the whole patch series (and
 > generally anything in libata that interacts with the scsi midlayer) to
 > linux-scsi, please.

It's rather large patchset consisting of 13 libata-eh related patches. 
Only two of the patches are relevant to SCSI.  I'm not sure whether 
cross-posting the whole thing is appropriate.

The first one exports two scsi_eh functions (this thread) and the second 
one uses these two to implement ata_eh_retry/complete helpers.

http://marc.theaimsgroup.com/?l=linux-ide&m=113798939719926&w=2
http://marc.theaimsgroup.com/?l=linux-ide&m=113798939627887&w=2

These are used because libata implements shost->eh_strategy_handler for 
error handling.  libata's ->eh_strategy_handler should do everything 
scsi_unjam_host() does and one chunk is to retry or complete failed SCSI 
commands during or after EH completes.  libata used to do this by 
calling scsi_finish_command() directly, which is an internal interface 
too.  Directly calling scsi_finish_command() also used to have deadlock 
problem when libata shared SCSI's host lock.

As what has to be done is identical, above two patches make libata share 
that part of code with scsi_unjam_host().  And, as Jeff commented, once 
these are settled scsi_fini_command() can be unexported.

Let me understand:

So when scsi_finish_command() is unexported, then _all_ EH strategies
would have to define local done_q, and splice eh_cmd_q into local work_q,
then from local work_q into local done_q and then that is passed
to SCSI Core, via scsi_eh_flush_done_q().

Is it possible that this is done asynchrounously?  Since EH recovery is
per host, but you may have only a single device which is misbehaving?

I.e. is it possible, in a such and such EH strategy, not necessarily
SCSI Cores's or libata's, to _not_ have a local done_q?  So that,
we have only local work_q (after splicing eh_cmd_q) and after each
command is looked at, we "return" that command back to SCSI Core, so
that SCSI Core can "finish" it. (In effect "per-command", as opposed to
"per-queue-of-commands".)

Alternatively, simulating this using one-command-per-local-done_q and
calling scsi_eh_flush_done_q() each time a single command is added
to local done_q would seem rather inefficient.

    Luben