Comment # 19
on bug 8089
from Chris Bontje
(In reply to comment #17)
>
> > 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.
I guess what I'm not seeing is the way that the entire 'frame' data structure
can be built in wmem and passed into the conversation record for later
retrieval. The 'Garray' let me dynamically build the fm_config_frame to
exactly the size I needed, I'm just not sure how the struct is modified to
allow (for example) a dynamically-sized "analogs" component.
> 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?
Yes, we do know how many ai_info's we will need when we run the function - how
to dynamically allocate that memory and assign it to part of the
fm_config_frame structure is where I get lost.
> 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 :)
I see you added the linked list functionality, nice to have the ability to
tinker when the hood is up!
> > 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.
I attempted to run the existing config_frame_fast code for each "configuration"
message before, but found that the conversation structure was always
over-writing the previously-saved config message with the current one. So all
I ever ended up with was a A5D3 message (as that's typically the last config
message encountered). I guess it's down to my lack of understanding of how to
utilize the conversation functionality to save multiple config packets and be
able to iterate through them later.
I am thinking that moving over to the new memory management system is beyond my
capabilities, at least without plenty of pre-existing examples to refer to.
Can I put it out there that you could modify the existing selfm code to use the
new library? I'd be happy to verify that all the functionality works as
before, and you get a showcase for the new library! :) Mind you, I understand
if you're tied up with other things and can't take that on.
Happy to help in any way I can!
Chris
You are receiving this mail because:
- You are watching all bug changes.
