Hi list,
Comments please,
By coding a bit and thinking, recoding, thinking, trying to figure out how
it will be used, ...
I came up with the following thoughts:
New thoughts on my thoughts of creating a new version of COMPOSITE tvbuffs.
COMPOSITE tvbuffs contains a list of backing structures as:
struct backing_data {
guint32 start;
guint32 len;
tvbuff_t real_data_tvbuff;
guint32 offset;
};
This structure tells us that real_data_tvbuff[offset,offset+len] is mapped
into the composite at
composite[start,len].
To map a real_data tvbuff into a composite one uses the function
tvb_insert(tvbuff_t *composite, guint32 start, guint32 len, tvbuff_t
*real_data, guint32 offset).
REAL_DATA, this type of tvbuff works as it always has.
It has the following properties:
* It is backed by a real malloc()ed buffer holding the real data.
* It maps one continous buffer from offset 0 to length, where length may be
up to 4Gb.
* The valid buffer range for a REAL_DATA tvbuff is [0,length]
COMPOSITE, redesigned, this type of tvbuffis a holder for slices of
REAL_DATA tvbuffs.
It has the following properties:
* It contains a virtual address range from 0 to 4G.
* the buffer data will/need not be continous.
* Slices (parts) of REAL_DATA tvbuffs can be mapped to arbitrary positions
inside the address range.
* One can map a (slice of) REAL_DATA tvbuff into the address range of the
COMPOSITE with a call
tvb_insert(composite_tvb, start, length, real_data_tvb, offset)
Which means that real_data_tvb[offset,offset+len] is mapped into
composite_tvb[start,len].
Example: assume real_data[0,100] and the call tvb_insert(composite, 200,
50, real_data, 50)
this would map real_data[50,50] into composite[200,250].
If len would point to data outside the bounds of real_data_tvb, a slice
of read_data_tvb would automatically
be created and mapped instead.
Example: assume real_data[0,100] and the call tvb_insert(composite,
200,100,real_data,50)
this would map the slice real_data[50,50] into composite[200,50].
* Only real_data tvbuffs can be mapped into a composite.
* If mapping real_data into a composite would cause an overlap with existing
data in the composite,
only the non-overlapping part of real_data will be mapped.
(the overlapping data could be checked and flagged with a future new
tvb_memcmp() call)
* If mapping a composite into a composite, the composite being mapped will
degenerate into a sequence of
real_data tvbuffs, and these will be mapped instead as appropriate.
SUBSET: saubset tvbuffs are redunbdant and can be removed.
A subset tvbuff really just slices a real_data tvbuff and remaps it at
ostart==0.
This behaviour will be emulated with a composite only mapping one real_data
slice at start==0
in the composite.
tvb_new_subset() (I think, I cant check the source when I am running
windows) will remain as
a function since many dissectors use it, but this function will not create a
subset any more,
it will create a composite and map the real_data slice at start==0 in the
composite.
All accessors will be updated to handle both REAL_DATA (as before) and also
COMPOSITE.
Support in accessors for SUBSETs can be removed.
Must have properties for COMPOSITE: (so it scales to useful sizes of
captures)
* The operation to insert a real_data tvbuff into the composite must be very
very cheap in regards to cpu and memory consumption.
* The operation to search for a backing tvb corresponding to a random
address in the range 0-4G of buffer for the composite
must be very very efficient and cheap.
* The operation to access backing tvbuffs sequentially forwards and
backwards must be very very cheap.
These properties I have good hope in managing to satisfy.
