Joe Eykholt wrote: > Robert Love wrote: >> On Mon, 2009-06-01 at 14:28 -0700, Joe Eykholt wrote: >>> Robert Love wrote: >>>> On Mon, 2009-06-01 at 11:10 -0700, Joe Eykholt wrote: >> >> <snip> >> >>>>> Along with this, I'd like to rename struct fc_rport_libfc_priv to >>>>> something else. Any suggestions? How about fc_peer? or >>>>> fc_pport? I want something short like that, not specifically a >>>>> target or initiator, not necessarily an N port or >>>>> a discovered port, maybe just a port? >>>>> >>>> Of the ones you list I think I like fc_pport best, although it's a >>>> bit strange. fc_peer doesn't mean that much to me since it's >>>> missing "port" and fc_port would falsely indicate some type of >>>> inheritance (that fc_lport should be a child of fc_port) or >>>> something (to me at least). >>> I have the same misgivings, and after starting to code this up, it >>> seems really strange to have a function called fc_rport_login that >>> takes a pport as an arg, ... that would make us want to call it >>> fc_pport_login, and then to rename fc_rport.c to fc_pport.c ...etc. >>> ... it get's too messy. >>> >>> Also, despite the name, fnic is accessing fields in >>> fc_rport_libfc_priv, to find out whether to do retry, etc., on >>> offloaded ops. >>> >>> So, to keep things sane, I'd like to keep the name the same, or >>> maybe just drop the libfc portion. (fc_rport_priv). Less code >>> changes. >>> >> >> What do you think of fc_rport_libfc, or fc_libfc_rport? I think I >> like the prior better. It replaces "priv," which doesn't have much >> meaning to "libfc," which does. >> >> Either way it's not a terribly big deal to me and I do prefer >> fc_rport_priv to the initial alternatives. > > I think having the module name in the structure name isn't so nice. > I guess it's more descriptive than priv, since it says who it > belongs to ... maybe fcs_rport? > > Or, how about fc_login, since it describes the state of the login? > That's what fc_sess was trying to do, I guess. But I think it should > start with fc_rport_ so we don't feel the need to change the name of > the file and all the function names that start with fc_rport. That's > why I called it fc_rport_priv. > > One thing that sort of bugs me about this is the use of rdata all > over the > place instead of rport, as the variable name that's by convention > used for fc_rport_priv. Maybe the variable name should be rportp or > rp. > This was something discussed internally, at least, durring the re-arch. The debate at the time was "lp" vs. "lport" and "rp" vs. "rport". I think "lport" and "rport" were used since the FC transport was using "rport" for members. I believe the "rdata" was chosen because another FC driver was using that name for it's private data.
"rp" and "lp" aren't any more grep-able than their longer counterparts. I don't care as long as we're consistent. > It's a simple patch to change the name all over the place, and I don't > mind doing that at some point. For now, I'll stick with > fc_rport_priv and rdata. > > Thanks, > Joe _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
