On Tue, 2011-11-08 at 14:19 -0800, Roland Dreier wrote: > On Tue, Nov 8, 2011 at 1:42 PM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > <SNIP> > >> To clarify, I'm not sure that adding target_core_mod symbol dependencies > >> into the qla2xxx LLD makes sense. This would mean target_core_mod would > >> need to be loaded even when qla2xxx is configured to run in initiator > >> mode (the presumable default). > > > > Which symbol would you pull in? > > In my opinion we should keep the dependency one-way, that is > tcm_qla2xxx depends on qla2xxx. However the way things should > work IMHO is that tcm_qla2xxx should call a qla2xxx function to > register itself as a target handler, and that registration function > should take a struct that tcm_qla2xxx fills in. > > And we can put whatever we need in that struct, so there's no > reason why qla2xxx can't call arbitrary target stack functions -- > and in fact having to register things through a struct like this forces > us to define the API clearly and keep it sane and small. > We already do define the API between the two with qla_hw_data->tgt_ops and tcm_qla2xxx_template. :) > (Doing things this way would let us fix the broken way tcm_qla2xxx > pokes into the private data of pci_devs to find qla2xxx structs -- > instead tcm_qla2xxx should pass in a callback that qla2xxx calls > once for each device) > <nod>, will get this addressed as well. As mentioned, it needs to be a qla_target.c based registration caller used by tcm_qla2xxx during initial lport setup from configfs context, along a new ->tgt_ops registration callback into tcm_qla2xxx to complete setup. --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
