Comment # 42
on bug 8431
from Max Baker
Hi Evan,
I'm able to pick this up again, sorry for the absence.
(In reply to comment #40)
> I was referring not just to the structure but to the accessor functions
> (table_value_from_mask etc.) as well. That function references
> USB_PTP_FLAVOR_MTP directly which is why I wasn't sure if it was possible to
> make it generic or not.
>
> This does sound like something that could be made generic, although I'm
> still not clear on the two-pass logic. From this explanation it sounds like
> there should still only be one pass, but that entries not matching the mask
> should be ignored rather than checked?
>
This is a PTP/MTP-specific behavior, so I guess the function is not a good
candidate for being generic. The vendor codes have collisions in their
assignment. On the first pass the code is looking for the more-specific,
more-accurate vendor codes if they exist. On the second pass the more generic
MTP standard code is looked for. Both codes exist in the same table w/
different masks and are matched at runtime.
> Is it possible for the same value to have two different entries with
> disjoint masks, so that only one of them is selected at a given time? If not
> it may be simpler to do this as a regular value string, use the existing
> accessor functions, and then check the mask afterwards to determine if
> you're "allowed" to use the returned value or not.
Unfortunately, it is possible which is what pushed me down the masked table
route.
I've merged with most recent and everything is still compiling cleanly (modulo
unrelated packet-dtn issues). What's the next step in order to get this
committed? Thanks, -m
You are receiving this mail because:
- You are watching all bug changes.