Comment # 17
on bug 8089
from Evan Huus
(In reply to comment #16)
> I'm not seeing a whole lot of wmem examples through-out the source right
> now, and the ones that are there (IP and smtp) seem to use a struct of
> hard-coded size, without dynamically associated arrays.
Wmem is quite new as a replacement for emem, which should be much more
widespread (but gradually deprecated). Wmem doesn't have dynamically associated
arrays yet - emem might, I'm not sure.
> What would be the wmem equivalent of g_array_append_val?
There isn't one (yet), but again there might be in emem. If there is then you
can use that, as emem won't be strongly deprecated until wmem can do everything
that emem can already.
> The issue I can
> see right now is that at the beginning of running config_frame_fast, I know
> I of course have a configuration frame. Within that configuration frame,
> there will be one cfg_data struct that has a variable length number of
> ai_info structs. Am I right in thinking that the existing wmem_alloc calls
> are good for assigning a new chunk of memory, not-so-good at appending an
> existing one?
Currently yes, but you know how many ai_info structs there will be, as you use
it to loop (cfg_data.num_ai). Are more added to the array in later packets?
> I see there are some calls called "stacks" and "slabs" that could be
> referenced in the wmem libraries, not sure if these are stacks I can dump
> data into and then pull out of when required?
Wmem's stack is a pretty standard stack data structure: push and pop. It only
deals in pointers, so you'd have to wmem_alloc each new structure then push the
pointer to that structure onto the stack.
The slab isn't likely to be useful except as an optimization.
> Ideally at the end of the day, what the selfm dissector needs is way to
> store/retrieve a conversation with this structure:
> - struct with pointers on any encountered config frames
> - within the pointer to fast meter A5C1/C2/C3 frame, associated cfg_data and
> dynamic ai information.
I've skimmed the code and I believe the following will work:
- g_slice_new(fm_config_frame) can be replaced with a regular wmem_alloc
- cfg_data.analogs (which is currently a g_array) can be replaced with a raw
wmem_alloc since you know the size ahead of time and it doesn't appear to
change
- fm_config_data_blocks (which is also a g_array) can be replaced with a wmem
linked list, as you only ever iterate it and never index directly into it.
Note that there isn't a wmem linked list (yet). I plan to write a simple one
this evening, as there is definitely a need :)
> A A5D1, A5D2 or A5D3 frame needs to refer back to it's corresponding "C"
> frame, so if there's a way in the new memory management library to do that,
> I'm all ears.
That's just a pointer, is it not? I'm not 100% clear on what you mean here.
Cheers,
Evan
You are receiving this mail because:
- You are watching all bug changes.
