Open rizard opened 8 years ago
@rizard - oxm_map
is a function in java_model
(disguised as a property).
I'm thinking a relatively easy way to improve this would be to call the function with the current version from the template (should be available as version
AFAIR); and then in the function you'd check for whether the OXM is contained in the given version.
Along the lines of:
@memoize
def oxm_map(self, version):
OxmMapEntry = namedtuple("OxmMapEntry", ["type_name", "value", "masked" ])
return OrderedDict( (oxm.name, OxmMapEntry(type_name=oxm.member_by_name("value").java_type.public_type,
value=re.sub(r'^of_oxm_', r'', re.sub(r'_masked$', r'', oxm.ir_class.name)).upper(),
masked=oxm.ir_class.name.endswith("_masked")))
for oxm in self.interfaces if oxm.has_version(version) and oxm.ir_class.is_subclassof("of_oxm") )
OF1.2 and up include every OXM in Match's supports() function. This seems to be rooted in the fact that java_gen/templates/custom/OFMatchV3Ver12.java, OFMatchV3Ver13.java, OFMatchV3Ver14.java, and OFMatchV3Ver15.java all delegate to OFMatchV3.java, which pulls possible/valid OXMs from model.oxm_map.values(), line 37 of OFMatchV3.java.
@andi-bigswitch Do you have any thoughts about the best way to fix this? Brute force would be to create a separate supports() function for each OpenFlow version in the version-specific Match class templates. But, I have a feeling there might be something in Loxi that tracks this already and maybe the wrong oxm_map is being referenced. Is there a version-specific list of OXMs that's compiled when Loxi parses the OpenFlow input files? Maybe this can be referenced instead in the OFMatchV3.java template, rather than the global list of OXMs.