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.

Thanks,
Bhanu

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Joe Eykholt
> Sent: Tuesday, May 26, 2009 4:22 PM
> To: [email protected]
> Subject: [Open-FCoE] libfc: RFC: rport / discovery fixes
> 
> Hi all,
> 
> I'm working on some remote port changes and would like some
> suggestions and opinions about the best way to proceed.
> 
> Today's issue is where the list of remote port list lives.  
> Bottom line:
> I'd like to move it out of struct fc_disc to struct fc_lport, 
> and protect
> it with lp_mutex instead of disc_mutex (eliminating disc_mutex).
> Some of the lookups already hold lp_mutex, note especially that all
> incoming ELS request handlers have it held.
> 
> Currently the list is part of the discovery structure in the 
> local port, and
> protected under the discovery lock.  For correctness, that means the
> discovery lock should be taken when looking up a remote port (part of
> my changes).   Also, a callback from the rport module to disc is used
> to remove an rport from the list when it logs off.
> 
> When in point-to-point mode, we don't need dNS, but we need a
> single remote port, and we just put it on the list of known 
> remote ports
> for convenience.  In this case it would be nice to have the 
> list outside
> of the discovery module.
> 
> When receiving an PLOGI from a remote port we haven't 
> discovered, we need
> a way of adding the rport.
> 
> All that seems to be a good motivation to moving the list 
> outside of discovery,
> and to put the access to the list into the rport module.
> 
> Any thoughts on this?
> 
> Here are the other related things I'm working on:
> 
> - handling RSCNs without logging out of unaffected remote ports
> - using ADISC to reverify login status after an RSCN
> - getting rid of the separate rogue rport list
> - correcting the rport lookup to lock and do device_get().
> - handle incoming PLOGI requests correctly
> - handle incoming ADISC requests.
> 
> I'll send patches out soon for comments.
> 
> Thanks for your help.
> 
>       Joe
> _______________________________________________
> devel mailing list
> [email protected]
> http://www.open-fcoe.org/mailman/listinfo/devel
> 
> 
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel

Reply via email to