On Dec 11, 2016, at 11:18 PM, Michal Labedzki <michal.labedzki@xxxxxxxxx> wrote:
> Good idea.
> I have similar problem with Bluetooth protocols. There is a lot of something like that:
> "Latency = N * 0.625 ms (1 Baseband slot)"
I.e., the value of the field is the number of baseband slots, and the latency, in milliseconds, is the number of baseband slots times .625?
> So I want to display [ms] instead of [slot] (or maybe both? [new use case]). What should I do in that case (N * 0.625)?
> 1. use own BASE_CUSTOM (dissector files)
> 2. public-predefined base custom function
> 3. combine it with "BASE_UNIT" (unit_name_string_get_value in base custom function) or BASE_UNIT | BASE_CUSTOM?
Perhaps we could have a structure that contains 1) a set of unit strings and 2) a scale factor, and:
if the scale factor is 0.0, there's no scaling;
if the unit string pointers are NULL, there's no unit;
otherwise, there's both scaling and a unit.
As for "or maybe both?", perhaps it'd be displayed as
Latency: 0.625 ms (1)
although, for that, we might want to allow units for both the scaled and the unscaled value, to display it as
Latency: 0.625 ms (1 baseband slot)
Should we have display-filter operators that work on both the raw value and the unscaled value, so that you could, for example, do
...latency == .625
or
...latency %= 1
(or whatever we choose for the two comparison operators).
> I think there should be abbrev-form of unit in "struct unit_name_string" (second, seconds, s) and provide user option to choose between full-form and abbrev.
That might make sense.
