On Jan 1, 2017, at 6:13 PM, Michael Mann <mmann78@xxxxxxxxxxxx> wrote:
> I really like the flexibility and power that the current dissector table API provides. The one small shortcoming is that a "protocol" needs to be provided when adding a dissection function to a dissector table. And not all dissection functions are a protocol. The "protocol" API is intentionally separate from the dissector function API because there isn't always a 1-1 relationship. This can lead to the creation of "dummy" protocols, or "pinos" (Protocols in name only) as I've decided to call them (modeled after [1]). To me, pinos don't have the same capabilities as real protocols. They don't have hf_ fields or heuristic dissection functions associated with them. They cannot be enabled/disabled. They are there strictly to satisfy the dissector table API and Decode As functionality by extension (names for dissection functions).
So why can't you just have dissector handles with -1 as the protocol ID? That means that you can't disable or enable it, but do we really *need* to be able to disable the dissector for some arbitrary IP or TCP or PPP option, for example? It also means that they can't participate in "Decode As", but I'm not sure there's a need for that, either.
The one reason I see for using dissector tables for TLVish things such as IP/TCP/PPP etc. options, attributes, etc., etc., etc. is to allow other dissectors, including third-party dissectors, to register dissection code for particular type codes. I'm not sure they need all the extra protocol-oriented enable/disable/decode as mechanisms.