Change in osmo-ttcn3-hacks[master]: pcu: Refactor GPRS infrastructure to keep state and simplify tests

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

pespin gerrit-no-reply at lists.osmocom.org
Wed May 20 11:00:52 UTC 2020


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 <pespin at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: Vadim Yanitskiy <axilirator at gmail.com>
Gerrit-Reviewer: laforge <laforge at osmocom.org>
Gerrit-Reviewer: pespin <pespin at sysmocom.de>
Gerrit-Comment-Date: Wed, 20 May 2020 11:00:52 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Vadim Yanitskiy <axilirator at gmail.com>
Comment-In-Reply-To: laforge <laforge at osmocom.org>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20200520/037058e4/attachment.htm>


More information about the gerrit-log mailing list