Michael Mann
changed
bug 9607
| What |
Removed |
Added |
| Attachment #12408 is obsolete |
|
1
|
| Attachment #12408 Flags |
review_for_checkin?
|
|
| Attachment #12423 Flags |
|
review_for_checkin?
|
Comment # 20
on bug 9607
from Michael Mann
Created attachment 12423 [details]
TFShark v.003
The latest installment of tfshark. This patch uses a minimum amount of wiretap
to dissect an ELF file (from bug 8818). To me this proves I can do dissection
without "true" wiretap.
It still looks like a hack job (because it is), but I want to keep it looking
like tshark source because I think the same "types of layers" will need to be
there, and it's easy to do a diff to the current tshark code. There has been
very minimal changes to the "epan" layer (and even that can probably be
abstracted/removed in time). It's the "below" and "above" that I'm still
fighting with (as well as trying to figure out how a "proto_tree_add_record"
would really work in the current epan code).
I'm leaning towards checking this in just because the file list (mostly for
build configurations) is starting to become unmanageable. I think this patch
does a good job at identifying all of the necessary layers and that once this
patch is committed, they can really start to be picked off one at a time (and
done correctly).
Right now, I'm still in favor of the "tap library" (wiretap/filetap)
determining "number of packets (or records)". Yes a tap/dissector could be
written to support a "single packet" (which is kind of what we have now), but
I'd like to discourage that for files that are truly "record based". I would
also encourage limiting the number of "record types" in a particular file, to
avoid the "duplication of knowledge" Evan mentions. For instance, I'd like to
see the ELF and MP4 dissectors converted accordingly. If for nothing else but
helping flush out layers/boundaries of the various pieces and provide examples
of "record type" boundaries.
You are receiving this mail because:
- You are watching all bug changes.
