Comment # 24
on bug 9607
from Michael Mann
(In reply to comment #22)
> Hint: ELF is not "record based".. or it is :) Clarification: there are many
> "records" but many of them are overlapped - unfortunately they may be
> different sizes (start offset, etc). What about multiple record with the
> same content or only some common part?
How a tap/dissector combination defines a "record" is completely up to it. It's
the same with dissectors making up a protocol. You can use one or many. When I
look at the current ELF dissector and its display of information in Wireshark,
I would say it has 4 record "types": Header, Program Headers, Section Headers,
and Infos (trailer?). Each should have it's own item in the "packet listview".
That would also mean 4 dissectors (which could also be done with the current
dissection independent of fileshark). The benefits of multiple frames would be
more obvious with a larger sample file (multiple MB) than what's provided in
bug 8818.
I think limiting a tap to just the record type information isn't too
duplicative. The "more generic" the record types is, the less duplication (but
also less items in the "packet listview"). We're just used to capture files
where it always boils down to record = frame.
Note that I'm just using the ELF dissector as an example/talking point on why
I'd like to see taps used (and where it's beneficial from a display
standpoint). Once fileshark is "stable", I think either design for ELF
dissection is acceptable - current (but with filetap as a single record) or
using (file)taps to get more "frames". But I may at least ask in a review
comment if the author considered multiple frames.
You are receiving this mail because:
- You are watching all bug changes.