Re: [PATCH 7/8] qla2xxx: Stall mid-layer error handlers while rport is blocked.

[Mike Christie <michaelc@cs.wisc.edu>]

James Smart wrote:
> Given this is the 3rd instance of this (qla2xxxx, lpfc, mpt fusion),
> we should either:
> 
> - Fix the error handler. (but we all know this is a lot of work,
>     of which none of us have the time to do, nor expect it to
>     be complete in time for our next distro delivery).

I understand the bugs in the eh. I have worked around them in iscsi and
tried to fix them in scsi-ml :) (still working on the queuecommand
SCSI_ML_HOST/DEVICE_BUSY fix), but along with the problems in the eh
where we could get the device offlined there could really be times when
the device needs to be offlined and reonlined, right? For iscsi we do
not really worry about either, in our userspace daemon we have code
where if the device was offlined and the daemon has corrected the
problem (or in qla4xxx case has been notified that the problem has been
corrected), then we online the devices. Since FC, has added a netlink
interface could we add something like fc_rport state changed event
support to some daemom. The daemon could online the device when the
rport state is back up if needed.

I was also thinking that the iscsi code has some common features and
maybe iscsi and fc could share something in some sort of blktool daemon.

Or do you think the userspace daemon is more of hack in userspace. I
cannot tell when I am hacking around something in the kernel or doing
something nifty in userspace anymore :)