Attention is currently required from: dexter, fixeria, pespin.
4 comments:
File include/osmocom/hnbgw/context_map.h:
Patch Set #2, Line 5: osmocom/core/bitvec.h
Why do we need this import in a header file? Looks unrelated and unneeded.
thanks. it's anrtifact of an earlier version of the patch, where I used a bit-mask of RABs - however, this turned out to be insufficient as we'd need at least two bits per RAB.
Patch Set #2, Line 173: uint8_t rab_state[256];
This is something we most probably want to have as some sort of bitmask in the future, eg using 2 bi […]
it actually was a bitmask with one bit in the beginning, but then I had to move to away from that. Using an array is simple and works. In the end, even at e.g. 10000 UE, this is only 2.5 Megabytes of RAM. Nothing to worry about.
What would make more sense is to unify this information with the ps_rabs list and the mgw_fsm further above. So that basically there's one object for per-RAB information and not multiple.
File src/osmo-hnbgw/kpi_ranap.c:
Patch Set #2, Line 54: ranap_message *ranap
`const` like above?
I had that originally, but it sadly doesn't work. I don't recall where it failed, but I think some of the osmo-iuh generated code doesn't permit passing a const structure [even when it should].
Patch Set #2, Line 362: //kpi_ranap_process_dl_iu_rel_cmpl(map, ranap); /* IU RELEASE COMPLETE (8.5) */
why is this one commented out?
I think I originally thought we'd need to track something here, but then didn't need it after all. Looking at the specs again, it looks like there's a list of released RABs in this message, so we might use that instead of simply assuming all RABs are releaed in the IU RELEASE COMMAND. I'll add a comment to say that.
To view, visit change 36311. To unsubscribe, or for help writing mail filters, visit settings.