> >or are you just thinking of, say,
> > exporting the values of particular protocol-tree fields, so that the
> > dissectors don't have to know about this?
> I don't really see how you could do this without building the knowledge
> into the dissector?
Easy.
You run a dissection on the packet to build a protocol tree.
Then you extract stuff from a protocol tree.
> The dissector would have to add some meta information
> (e.g field name) about the fields it puts in the tree at startup I guess.
I assume that's supposed to be parsed as
{The dissector} {would have to add} {some meta information (e.g.
field name) about the fields it puts into the tree} {at startup}?
I.e. "at startup" refer to "would have to add" rather than to "it puts
into the tree".
If so, then the dissector *does* do *exactly* that; fields need to have
names to be used in display filters.
> Maybe we could add a parameter to the proto_tree_add routines that would
> contain the export information like field name, protocol to which it belongs
> etc.
We have that parameter - that's what the second argument, the "hfindex"
argument, is; it's the index filled in when protocol fields are
registered with "proto_register_field_array()".
> The problem is that this would cause overhead in every packet that is
> processed. The export format string is also different from the format string
> you'd use in the display tree, you typically just want the values of the
> fields without blabla in front of them.
Why do you need an export format *string*? The entry for a field
includes the type of the field and, for integral-valued numeric fields,
the base (decimal, hex, or octal).