Comment # 11
on bug 9050
from Michal Labedzki
(In reply to comment #6)
> Comment on attachment 11398 [details]
> [PATCH 3] Bluetooth: Replace proto_tree_add_text with hf items
>
> While I applaud the effort to replace proto_tree_add_text calls with
> something filterable, there are many fields which are of type FT_NONE. Upon
> cursory glance, it appears many could have a real type to them. I realize
> sometimes multiple values are involved in a single field display, but does
> that mean either:
> 1. One of the values should be chosen as filterable as an integer/string
> 2. More fields should be created
>
> I don't think many more hf_ items need to be created (which I consider the
> harder part), just the type changed to something that can "filter by value"
> (and thus change proto_tree_add_none_format to
> proto_tree_add_[uint|string]_format)
This patch provide me functionality:
1. Filtering by "items" - Bluetooth dissectors have repeatable structures that
items now, so I can filter by them, find it (frame with).
2. Structure of dissector is more logical now - there is no "text" fieldnames,
but itemized fieldname, my favourite case:
OLD:
text: LMP Features (subtree)
bthci_evt.lmp_features.secure_simple_pairing_host: .... ...1 = Secure Simple
Pairing Host: True
NEW:
bthci_evt.lmp_features: LMP Features (subtree)
bthci_evt.lmp_features.secure_simple_pairing_host: .... ...1 = Secure Simple
Pairing Host: True
3. I hope FT_NONE can be filterable like FT_BYTES (or should I use it with
little override of Description to hide "bytes") (exzample:
btsdp.service_long_uuid contains 8e:77:16:02 vs btsdp.data_element conatins
77:99)
Please give a chance to the patch. It is improvement.
You are receiving this mail because:
- You are watching all bug changes.