Luben Tuikov wrote:
Hi Tejun,
--- Tejun Heo <htejun@xxxxxxxxx> wrote:
So, what's your suggestion here? Do you think libata should do such
things with its own mechanism?
Your instinct is correct. Anything between I and T, as in I_T, is SDS
domain. That is, SAM doesn't have a _context_ for anything between the I and T.
(In SATA's case I_T_L, of course.)
So this is why you shouldn't call SCSI's ER without context, as in "Hey,
neither command, nor device is broken, but do some ER for me." Such work belongs
in your SATA Layer, unless either a device or command is involved, as we discussed.
Handle protocol ER in your SATA layer. Note however that most of your ER could
be done on behalf of a command or device, since of course, a device or command(s)
end up being affected. Basically "do as little as possible but no less" technique.
Hello, Luben.
I see your point regarding SAM. If this is the consensus among SCSI
developers, I guess eh_schedule_host() shouldn't be added.
Hmmm.. libata isn't SCSI. It's just hitch-hiking on the back of SCSI at
the moment. And, being able to invoke EH on the host directly makes
things a lot simpler for libata. So, what do you think about just
adding shost->host_eh_scheduled, adding a condition to
scsi_error_handler() and export scsi_eh_wakeup()? The changes will be
like three lines. And, also, ->host_eh_scheduled can be marked as hack
for libata. libata can handle the rest.
This may not be the most graceful thing to do but...
1. SCSI change is minimal
2. it's a temporary measure (moving libata out of SCSI is one of the
items on my agenda and if no one else does it I'm gonna give a shot at
it in not-so-distant future. Once libata is gone of SCSI, the three
lines can be removed.)
3. It will take a lot more work to achieve the same thing in libata
proper without the three line change.
Luben, what do you think?
James and Jeff, any opinion on this matter?
Thanks.
--
tejun
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
