I've told Lee to test something for me. I think the priority from match functions are being confused via these (stupid) UMATCH_* variables, which are some weird disguise for what is supposed to be a priority code.
In his upgraded case, ubm should win. it returns UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO which is 5. umsm does fewer tests, and returns UMATCH_VENDOR_IFACESUBCLASS which is 6. So with my change umsm wins. I asked Lee to first test if_umb.c returning a higher value such as UMATCH_VENDOR_IFACESUBCLASS_IFACEPROTO which is 7 On my backwards device, if_umb does not match at all, so umsm would win. If I am right, that would satisfy both old and new devices; I think umb_patch is already doing the correct "tests", but simply returning the wrong value. And if that helps, then I think all this should be reconsidered. I *think* the idea behind this UMATCH_* variable naming is that the match return value says "how many fields did I look at and how confident am I", and that's what the naming comes from, but what I don't understand is --- who cares how many fields you looked at, as far as the subr_conf.c code is concerned this is ONLY a priority code not some "what did I do" to decide thing. And the priority value is going to something more magical, it's not some direct mapping between "how much did you look at". However are a mess of relationships here with the many device need "first kick me off umass", so we need to be somewhat careful to pick at this problem from the correct end.
