Wireshark · Wireshark-dev: Re: [Wireshark-dev] Wireshark-commits: [Wireshark-commits] rev 44161: /trunk/epan/dissectors/ /trunk

[Sylvain Munaut <246tnt@xxxxxxxxx>]

Hi Pascal,

> If you check the mailing list archive you will see that I also raised
> this issue regarding filter names for protocols split across several
> files. See http://www.wireshark.org/lists/wireshark-dev/201207/msg00258.html
> for the mail exchange.

Yes, I've seen this (I replied in the same email thread :)


> So far only Michael and myself have expressed our opinion on those
> "meta" protocols split across several files. Personally I preferred
> the previous filter scheme despite the warnings generated by the
> checkfiltername.pl script. It would be good if other people were also
> giving their feeling (as you did) so that we can decide once for all
> whether the dissectors or the script must be changed for this use case
> and try to stick to this decision in the future.

As I said, I didn't take the decision lightly, I hesitated between
both options (and actually you can even see the rest of a bad 'sed' in
some of those where you find gmr1.rr._xxx ...).

I the end I chose the one that made the most sense and confirmed with
the ML ( http://www.wireshark.org/lists/wireshark-dev/201202/msg00033.html
) and IRC there was no objection. Anders Broman responsed that it
looked reasonable and he's the one who merged them IIRC.


> Note that the change was done in the development branch only and that
> next stable release from this code base is due in a year so we still
> have plenty of time to change things.

That would be nice :P

I don't know all the protocols where this happens but to me having
gmr1_rr.xxx or gmr1_common.xxx makes it believe those are different
protocols which they're not ... GMR-1 is the protocol and then you
have the channel types like CCCH on which you can find messages that
can contain elements from RR/CC/...

And so having the hierarchy  protocol (gmr1) / category of element
(common / rr / cc / ...) makes sense to me. Those category are not
arbitrary either, they're explicitly defined that way in the official
specifications, I'm not making them up.

If someone has a good argument _against_ this, I'd be interested to
hear it. (And the fact the checkscript can't deal with it is not
really a good argument ... at worse we could add meta-tags in the
header of those files to define the prefix allowed to be used)


Cheers,

    Sylvain