pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18370 )
Change subject: pcu: Refactor GPRS infrastructure to keep state and simplify tests ...................................................................... Patch Set 1: (8 comments) https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18370/1/pcu/GPRS_Components.ttcn File pcu/GPRS_Components.ttcn: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18370/1/pcu/GPRS_Components.ttcn@a235 PS1, Line 235: /* 3GPP TS 44.018, table 9.1.8.1, note 2b: Request Reference shall be set to 127 : * when Immediate Assignment is triggered by EGPRS Packet Channel Request. Here : * we assume that 11 bit RA always contains EGPRS Packet Channel Request. */ : if (is_11bit != 0) { ra := 127; } > This should have not been removed. That's why the related test cases fail. So what's the point then for tests TC_egprs_pkt_chan_req*() crafting ra values if finally this value 127 is set? Please enlighten me. To me either this or all those tests are wrong. https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18370/1/pcu/GPRS_Components.ttcn@48 PS1, Line 48: GsmRrMessage > Do we really need to store the RR Immediate Assignment in a TBF record? As > far as I understand, we p […] We parse most relevant and usually used stuff like TFI, USF,etc. but for some stuff which we scarcely use it makes sense to keep rr_imm_ass, even if it's only for quick testing and test addition. IIRC I stored it here because some test required something from rr_imm_ass, so it doesn't hurt that much keeping it for now. We may remove it later if we move all the contents to some other specific fields. https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18370/1/pcu/GPRS_Components.ttcn@49 PS1, Line 49: PacketDlAssign ass, : PacketDlAssignment rlcmac_ass, > Please add a couple of comments here, what is the difference between both? If > I understand correctly […] Yes it serves the purpose you said. Ok, I can move it to a union "ass" and then have "ass.ccch" and "ass.pacch" https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18370/1/pcu/GPRS_Components.ttcn@66 PS1, Line 66: GprsTlli tlli > minor whitespace Ack https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18370/1/pcu/GPRS_Components.ttcn@72 PS1, Line 72: UlTbf ul_tbf optional, : DlTbf dl_tbf optional > Please add a comment that there can be more than one UL/DL TBF. Ack https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18370/1/pcu/GPRS_Components.ttcn@111 PS1, Line 111: f_init_gprs_ms > This function looks redundant. Just let test cases evaluate t_GprsMS_def as > they need. […] Well, so far it only does that, but we may add new stuff here in the future, so I prefer keeping it this way for now, in case we have to init something component related at some point. https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18370/1/pcu/GPRS_Components.ttcn@239 PS1, Line 239: f_ms_set_lqual > This functions is redundant. That's like usual discussion on wheter setters are required or not for class attributes. I find it useful because grepping for the function name I can find all places where lqual is being set. Similar, in the future we can add new APIs to set if in dB, etc. https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18370/1/pcu/GPRS_Components.ttcn@244 PS1, Line 244: f_ms_set_ta > I am sorry, but it looks like f_sum(a, b) { return a + b } to me. Again, I find it useful to quickly find where the TA field is being set, and make sure we always do it in a unified way. I want to have as much logic as possible wrapped in this class. -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18370 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: Ib3fee37580f0ea0530a659dec83656799bf57288 Gerrit-Change-Number: 18370 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <[email protected]> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Vadim Yanitskiy <[email protected]> Gerrit-Reviewer: laforge <[email protected]> Gerrit-Reviewer: pespin <[email protected]> Gerrit-Comment-Date: Wed, 20 May 2020 11:00:52 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Vadim Yanitskiy <[email protected]> Comment-In-Reply-To: laforge <[email protected]> Gerrit-MessageType: comment
