Re: [ethereal-dev] New proto_tree patch

[Ashok Narayanan <ashokn@xxxxxxxxx>]

Guy Harris writes:
 > > 1) It should not be compulsory to register each and every
 > > field. Complex protocols like RSVP and SMB will essentially end up
 > > doubling their code size or more.
 > 
 > It appears that "proto_register_field" fills in all the fields of
 > "struct header_field_info" that aren't to be specified by the protocol
 > dissector; an alternative might be to have a protocol dissector contain
 > an array of all fields for the protocol, and have a routine that takes,
 > as an argument, a pointer to that array and a count of elements in the
 > array, and registers all of them.

Yeah, but then you end up with this 150-element array which will have
to be declared, element by element. Then you have the data writing
code - so you've doubled your codelines.
 
 > The amount of stuff you'd type when writing a protocol dissector
 > wouldn't necessarily change - you'd type in an entry in the array rather
 > than a call to "proto_register_field()" - but code would be replaced by
 > data, and the data in question would have to exist *anyway*, as, in the
 > old scheme, it'd have been allocated by "proto_register_field()".

Right - so you still end up doubling your code.

 > > There should be a default value for
 > > hfindex which indicates "put this in the tree here, but I don't ever
 > > care about filtering on it".
 > 
 > Presumably "Match Selected" will use this new filtering mechanism...

No, not really. Let me clarify - I'm thinking of two different
mechanisms here:

1) Match Selected *Field*: This will use the new filtering mechanism
and will basically be a shorthand for a filter expression. Of course,
this won't work on HF_DEFAULT fields.

2) Match Selected *Bytes* (which is what we support today). This is
independent of filtering, and I expect will remain so. Basically we
would just run down the set of packets and do memcmp. This doesn't fit 
into the scheme well because using Match Selected Bytes, you could
pick an entire large object (or even an entire message), which is made 
of may bytes and potentially many fields. It's easier and more
efficient to just do memcmp in this case than to attempt to create a
filter expression for this. In fact, I wager that if we try to do this 
by expression, we'll end up implementing a memcmp-like thingy.

-- 
--- Ashok Narayanan ----------------------------------------
IOS Network Protocols, Cisco Systems
250 Apollo Drive, Chelmsford, MA 01824
Ph: 978-244-8387