Ethereal-dev: RE: [Ethereal-dev] [RFC] specially mark protocol fields "generate d" byEthereal?
Ethereal development <ethereal-dev@xxxxxxxxxxxx> schrieb am 30.04.04 10:44:12:
>
> |From: Ulf Lamping
> |
> |It might be even a better idea to provide this info into the
> |hf_register_info by adding it in a "machine friendly" format, like
> |or'ing a flag into the FT_xy fields.
>
> I agree with you. This way an end-user may decide what to do with a given
> type of header fields (inclusive showing/hiding them and choosing how to
> render them).
> Maybe we need to specify this distinction in the PDML language too.
I've changed the PDML output some days ago, so a none visible field will be marked as such :-)
The generated flag has no representation in the current PDML spec.
>
> Also note that fields may have the hidden flag and the generated flag on at
> the same time.
Of course this should be a flag or'ed to the "normal" FT_ field, FTF_HIDDEN and FTF_GENERATED (usually, if hidden is used, generated will also be used), so for example:
#define FTF_HIDDEN 0x8000
#define FTF_GENERATED 0x4000
>
> |So the hf_register_info entry could look, like: FT_FRAMENUM |
> |FT_GENERATED, or we could provide another set of field registration
> |functions, like: proto_tree_add_uint_generated()
>
> Here we need to be careful as today the FT_* are an enum which may be just
> one single 8-bit byte.
an enum is an int (ANSI C), and an int is an all of our platforms 32bit AFAIK, so no problem here.
>
> We however still have some spare room in the HFILL macro to accommodate a
> bitfield without requiring us to edit all dissectors. We could even write
> HFILL for default, HFILL_HIDDEN for hidden, HFILL_GENERATED for generated
> and HFILL_GENERATED_HIDDEN for hidden generated fields, but there are
> certainly other worthwile approaches.
As described above, or'ing to the FT_ fields should be ok for the reasons described above.
>
> |Anyone an idea of how much effort that would be?
>
> Add the basic framework to the field registration: minimal.
> Add the field rendering changes: minimal, mainly GTK+.
As I know GTK now, both agreed.
> Review the dissectors: potentially huge, but not required for technically
> running Ethereal.
Fortunately, we can make the changes step by step.
Regards, ULFL
____________________________________________________________________
Der WEB.DE Virenschutz schuetzt Ihr Postfach vor dem Wurm Sober.A-F!
Kostenfrei fuer FreeMail Nutzer. http://f.web.de/?mc=021158
