On Thu, 2012-09-13 at 14:07 -0700, Andy Grover wrote: > On 09/13/2012 01:06 PM, Christoph Hellwig wrote: > > On Thu, Sep 13, 2012 at 01:01:52PM -0700, Nicholas A. Bellinger wrote: > >> On Mon, 2012-09-10 at 13:05 -0400, Daniel Lane wrote: > >>> Hello, I am having the same problem reported here (with any > >>> resolution) http://www.spinics.net/lists/target-devel/msg02618.html > >>> and https://bugs.launchpad.net/ubuntu/+source/targetcli/+bug/1040404 > >>> > >> > >> Hi Daniel, > >> > >> The mainline version of qla2xxx by default runs in initiator mode > >> enabled only. In order to enable qla2xxx to run in target mode, you'll > >> need to follow the instructions from the wiki here: > >> > >> http://linux-iscsi.org/wiki/Fibre_Channel#Enable_target_mode > > > > Maybe targetcli should a report a useful error including that link > > instead of throwing an exception no one understands? > > FWIW rtslib-fb will catch the OSError and convert it to an > RTSLibError("could not create <foo> in configFS"). The backtrace is > avoided but the error message is still unhelpful. > > All fabrics are supported in rtslib via a single Target class that looks > at the .spec file for per-fabric differences, so we can't just override > a method to print a better diagnostic for qla2xxx. > > What would really be nice is if we could put a given iface into target > mode at runtime - the solution on the wiki appears to do it for all > ifaces and require a module reload. Correct. > Then we could add another hook in the qla .spec, and rtslib could > enable target mode automatically on the ifaces as they were added in > targetcli, which would be slick. > Yes, being able to do this on a per port basis for tcm_qla2xxx from targetcli would be very slick indeed. > How hard would it be for qla_target.c to expose a per-iface sysfs > attribute to change active_mode? > So some of the existing limitations for doing mixed-mode on a per HW port basis between an LLD + tcm fabric driver have been discussed on the list ahead of the tcm_qla2xxx merge, but in order to really do the transitions between T->I and I->I properly, scsi-core + target-core are going to have to become (more) aware of what each other is doing. AFAICT the biggest piece of work would involve a global re-factoring of the current LLD assumption that SCSI initiator mode is always enabled + LUN scan is performed within PCI ->probe_one(), and then disabled within PCI ->remove_one() context. This means currently the only way to disable initiator mode for a specific LLD port is to remove the underlying PCI device.. Unfortunately supporting proper mixed T/I mode operation has not gotten much interest just yet post merge, primarily due to the fact that the re-factoring involved for existing LLDs would make the great scsi_host lock push-down of 2010 look like a bunch of white-space patches. ;) --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
