Ethereal-dev: Re: [Ethereal-dev] opinions...
I've just finished a first pass at this.
Currently the column_info, frame_data, packet_info, value_string, and
miscellaneous to_str functions have been pulled out of packet.{c,h} and
into separate files ( packet.{c,h} seems to have accreted things over
time).
Some, but not all, of the stuff from packet-ipv6, packet-osi,
and packet-vines, have been pulled back into epan ( just enough
to remove the dependency of epan on the dissectors ).
I've implemented your suggestion for having epan_init take as arguments the
register_all_protocols and register_all_protocol_handoffs functions
to eliminate the dependency on register.{c,h}.
I've added a register_dissector call to proto_register_frame in
packet-frame.c. Then I added a find_dissector to proto_init so that
I can use call_dissector in proto.c. I also implemented a function
that will allow you to search for a protocol by it's filter_name
and used that to grap the proto_id of proto_malformed int proto_init.
Using these two things I eliminated the compile time dependency of
proto.c on packet-frame.c.
I determined that we don't actually have any dependency in epan
on pref.{c,h} or util.{c,h}, it just seemed that the #includes where
hanging around for no good reason.
Net result, epan still depends on wiretap and on the existence of
a compiled version of lemon. Other than that, no compile time
dependencies on anything else that comes with the ethereal source
tree remains. ( I've tried moving the epan, wiretap, and tools dir
to a separate directory, away from the rest of the ethereal
source. epan still compiles).
A preliminary compile and trial run of ethereal after all of this seems
to work. I want to cool of for a couple of days and then come back
to look over this work once more and do some more extensive testing
before I check any of this in. Hopefully I'll start checking things
in next weekend.
We definitely want to consider what in the top level column.c belongs
in the epan/column_info.c. I'll look into that ( and other matters )
on a second pass.
Ed
On Mon, 26 Mar 2001, Guy Harris wrote:
> On Sat, Mar 24, 2001 at 06:37:04PM -0500, Ed Warnicke wrote:
> > How would the rest of you feel about seeing the column stuff pulled
> > out of packet.{c,h} and into a separate column.{c,h}?
>
> Sounds good to me.
>
> We might want to think about how much of the stuff in the top-level
> "column.c" would belong in "epan/column.c", and how much of the stuff
> that would end up in "epan/column.c" would belong in the top-level
> "column.c".
>
