Joe Eykholt wrote:
> Love, Robert W wrote:
>> Bhanu (Venkata Bhanu Prakash) Gollapudi wrote:
>>> Hi Joe/Robert,
>>> 
>>> I have a question in the related area of discussion.
>>> 
>>> Can we obtain the event_callback function in fc_lport_rport_ops and
>>> fc_disc_rport_ops from the libfc_function_template rather than
>>> having static functions(fc_lport_rport_callback and
>>> fc_disc_rport_callback). This would provide flexibility to LLDs to
>>> take any driver specific additional actions on that session along
>>> with the default action performed by these functions (adding or
>>> removing the rport from the list). Please let me know your thoughts.
>>> 
>> Sounds reasonable to me.
>> 
>> If Joe is moving the rport list to the rport layer (not sure why it
>> isn't moving to the lport layer) then he'll probably be moving the
>> fc_disc_rport_callback() out of the disc layer and into the rport
>> layer.
> 
> I guess the rport list could be put in the lport layer, but I wanted
> to have rport_create also add the new rport to the list.  It seems
> better in the rport layer.  I'm open to changes along those lines.
> 
I just didn't understand why it was in the rport layer since the list
is now associated with the lport. I reserved questioning because I
figured you had a good reason that your patches would expose when you
post them.

> On fc_disc_rport_callback(): I'm getting rid of that by
> having the rport layer do the list maintenance.  Since
> that's all that callback did, there isn't a need for it in fc_disc.
> fc_lport still uses an rport event callback to find out when the
> directory server rport or point-to-point rport is ready.
> 
> We could have a transport-template callback for all remote ports as
> well if there's a need by LLDs.   That would be in addition to
> the rport callback that was specified via rdata->ops, and we would
> probably call that before the other one on create, and after the
> other one on delete, I guess.
> 
Bhanu, do you want to override the callbacks completely or just be
notified as well as letting the normal callback continue doing what
they're currently doing?
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel

Reply via email to