Hi List!
After my first proposal of marking special protocol fields as
"generated", a lot of responses to this topic comes in.
Especially Ronnies response reminded me, that my first proposal was too
inflexible of handling special cases, so I would like to propose a
different approach now.
Instead of putting this additional field information into the
hf_register_info data at protocol registry (which is too inflexible),
this info should be stored in the field_info while adding the the items
to the proto_tree, just replacing the current visible field (currently
used as a single flag only :-).
I would think of using a value holding several flags. The following
"rendering specific" flags comes to my mind:
#define FI_HIDDEN 0x0001
#define FI_GENERATED 0x0002 /* still need a good name for
this */
This flag field could also keep other field specific information, like a
more general way of marking bad packets (e.g. when a checksum failed).
When I remember it correct, this "expert functionality" was dicussed on
the list weeks/months already before. But please *don't* start a
discussion on this error reporting topic right now, and let's focus on
the correct mechanisms to handover this flag to the display output.
So I've added the following macros to the proto.h:
#define PROTO_ITEM_SET_HIDDEN(proto_item)
FI_SET_FLAG(proto_item->finfo, FI_HIDDEN)
#define PROTO_ITEM_SET_GENERATED(proto_item)
FI_SET_FLAG(proto_item->finfo, FI_GENERATED)
So instead of adding these flags as a parameter to the proto_add_xy_item
(and add new functions for every FT_), this new functions should be
called, after the normal proto_tree_add_xy functions returned.
This don't break anything in all the existing dissectors (as all the API
calls are unchanged), and we can bring the old
"proto_tree_add_xy_hidden" calls to this new API design step by step.
I've checked in the changes for some of the values in the TCP dissector
(see: "SEQ/ACK Analysis"), so you might want have a look there.
Regards, ULFL