I want to convert all Bluetooth dissectors to new proto tree API. Is
it a good idea?
wt., 18 wrz 2018 o 18:23 Alexis La Goutte <alexis.lagoutte@xxxxxxxxx>
napisał(a):
>
> Thanks Jakub for historic
>
> I think a good idea is revert to use "standard" API
> or write a tools for convert old dissector to new API...
>
> Cheers
>
> On Tue, Sep 18, 2018 at 6:05 PM Jakub Zawadzki <darkjames-ws@xxxxxxxxxxxx> wrote:
>>
>> Hi,
>>
>> W dniu 2018-09-18 16:56, Maynard, Chris napisał(a):
>> > While investigating the transum-related crash, I had suspected some
>> > unregistered hf's and ran the various tools like checkhf.pl. I then
>> > noticed that a number of dissectors seemed to have changed a bit from
>> > what I was used to before (...)
>>
>> These changes are quite old. For udp I did it in Aug 2013
>> (88eaebaedf2e19c493ea696f633463e4f2a9a757).
>>
>> some wireshark-dev threads:
>> - https://www.wireshark.org/lists/wireshark-dev/201307/msg00222.html
>> - thread continuation:
>> https://www.wireshark.org/lists/wireshark-dev/201308/msg00035.html
>>
>> Nobody stopped me that time.
>>
>> > And I guess I missed the reasoning behind the restructuring, but what
>> > is the purpose/benefit of this restructuring
>>
>> To sum up:
>>
>> Restructuring idea was to remove usage of int hf_foo, so you would need
>> only to declare header_field_info hfi_foo (unfortunate, you still need
>> to do it on top of file).
>>
>> Benefit is no more ints, so:
>> - proto_tree_ api checks if you passed header_field_info structure,
>> - You don't need to declare int hf_foo = -1; (bonus: binary size
>> smaller 4 bytes per hf),
>> - no need for table lookup in proto_tree_add_*
>>
>> > and use of HAVE_HFI_SECTION_INIT?
>>
>> Idea was that HFI_INIT(proto_bar) would put all protocol hfi's into
>> single binary section. This way wireshark could auto-register these
>> fields
>> without need of some indirect array (bonus: binary size smaller by
>> sizeof(void *) per hfi).
>>
>>
>> After 5 years simple grep shows that only 36 dissectors are using
>> NEW_PROTO_TREE_API, so it seems that this API is not well known or not
>> liked.
>> If it makes problem I would suggest to drop it.
>>
>> Alexis suggested the same in 2015:
>> https://www.wireshark.org/lists/wireshark-dev/201508/msg00087.html
>>
>>
>> Jakub.
>> ___________________________________________________________________________
>> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>> Archives: https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
--
Michał Łabędzki
