> Negative names can sometimes be confusing. For the option name, then, > how about "cfm_op_state" or "cfm_opstate" or similar, with valid > values "up" and "down"?
I'm fine with this, i'll change it and resend. > I agree that it makes sense for the opdown byte in struct ccm to have > this inverted sense for compatibility. Maybe it makes sense for > cfm_get_opdown(), too, since then it has the same sense as > cfm_get_fault(). I kind of wish I had called cfm_get_fault cfm_get_status and used a positive name from the beginning in retrospect. I don't have a strong opinion either way on what the module accessor should be called. I can think of good reasons for either choice. > > struct cfm now has a ton of "bool" members, I wonder when it makes > sense to start using a bitmask (or even bitfields)? > > Should we report remote_opdown in the database? I guess it would have > to be true if any remote MP was down, so maybe it isn't granular > enough to be useful. I plan in the relatively near future to expose a lot more data about the state of the CFM machine to the controller. I think that may be a logical time to convert to a bitmask so it can be easily passed up to the bridge. I think remote_opdown would be a logical thing to pass up as well, but I think I'll hold off and push everything up in one patch series. Ethan _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
