Ronnie Sahlberg wrote:
I think this seems like a good plan.
Can I suggest to call the flag FT_SYNTHETIC instead of FT_GENERATED?
Hmmm, I don't have a good imagination what synthetic should be, so it
might not be a good name.
We might still need a better name for this.
Please note the FTF_ prefix I've used before, to distinguish between the
new flags and the field values.
Three things to aware of are
1, the FT_xxx fields are used not only in the hf definitions, they are used
in some stats collection functions, some
helper functions and some dissector functions as well.
All these places must be updated as soon as this change occurs or they will
break.
Only the references in the hf definitions can be done one by one at a later
time.
Well, I thought of doing a preprocessing in the proto_tree_add_xy()
functions, so the flags will be seperated from the current FT_xy value
and stored seperately,
just like the current hidden/visible is already done. This will prevent
breaking something. We might later change this behaviour and have a look
at the places you've mentioned.
2, the hidden flag will not be able to solve all issues at all places, that
needs to be worked out first.
I am thinking of when a field is sometimes visible in the tree and at other
instances the very same field is hidden.
Example: nfs.fh.hash IS visible for the PDU in the NFS/NLM/MOUNT/NFSACL
Request/Response pair
where this field occurs. With suitable preference options this field is
ALSO added to the other PDU in the pair
so that useful filters like nfs.fh.hash==0x12345678 will find BOTH PDUs for
those transactions where this file occurs.
This applies to other fields as well. And even more fields in the future.
(smb.fid matching BOTH Request/Reply anyone?)
3, the synthetic flag will not solve all instances either.
Think the nfs.procedure_v3 field.
This field exists and describes in the ONC-RPC NFS requests.
The procedure number does NOT exist in the response PDU but we still want to
display this field in those PDUs anyway.
Both points are the same problem, I think..
As this shouldn't be often the case, I would suggest to simply duplicate
the hf entries. I'm unsure if the filtering and searching engines are
able to handle this.
If this isn't possible, we have to use plan b :-) This would be to
change the registration functions parameters, however, this isn't
appreciated by me.
Regards, ULFL
