Ethereal-dev: AW: [Ethereal-dev] Introducing additional capture-stop capabilities
-----Ursprüngliche Nachricht-----
Von: Guy Harris [mailto:gharris@xxxxxxxxx]
Gesendet: Sonntag, 9. September 2001 05:16
An: Thomas Wittwer
Cc: ethereal-dev@xxxxxxxxxxxx; Nyffenegger, Matthias
Betreff: Re: [Ethereal-dev] Introducing additional capture-stop
capabilities
On Wed, Aug 22, 2001 at 05:49:47PM +0200, Thomas Wittwer wrote:
>> There are three new modules (capture_stop_conditions, condition0s and
>> ringbuffer).
>"cnd_eval()" is a varargs function; however, if different conditions
>require different argument lists, how is the caller to know what type of
>argument list should be supplied?
Originally I did not intend to supply an argument list to 'cnd_eval()' at
all,
besides the condition. The conditions could have been kept in a dynamic list
and evaluated by iterating over the list and calling 'cnd_eval()'.
The idea was spoiled by the fact that I did not succeed to determine the
filesize of the capture file accurately enough by looking at the filestats
see CND_CLASS_FILESIZE in capture_stop_conditions.c).
The caller must now know about the argument list of a particular condition
type for 'cnd_eval()'. The caller knows what kind of condition is used when
he creates and initializes the condition.
>The code that calls it currently knows that there are two separate stop
>conditions, "cnd_stop_timeout", which takes no arguments, and
>"cnd_stop_capturesize", which takes as an argument the number of bytes
>written to the capture file so far.
>This doesn't seem to allow new conditions to be added without the code
>that calls "cnd_eval()" knowing about the new conditions; given that,
>I'm not sure I see the benefit of the general mechanism that
>"conditions.c" introduces.
I agree, see above. A possible solution would be to let the conditions
'eval' function fetch the 'bytes dumped' argument itself. This implies
initializing the condition with the dumper handle and a function pointer
to 'wtap_get_bytes_dumped()'.
Regards Matthias
