[XL] Change in osmo-msc[master]: ASCI: Add call control for VGCS/VBS

Attention is currently required from: jolly. laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-msc/+/33511 ) Change subject: ASCI: Add call control for VGCS/VBS ...................................................................... Patch Set 10: (15 comments) File src/libmsc/vgcs_fsm.c: https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/5f7b6d12_9b45ad97 PS10, Line 123: tatic __attribute__((constructor)) void vgcs_bcc_fsm_init(void) : { : OSMO_ASSERT(osmo_fsm_register(&vgcs_bcc_fsm) == 0); : } : : static __attribute__((constructor)) void vgcs_gcc_fsm_init(void) : { : OSMO_ASSERT(osmo_fsm_register(&vgcs_gcc_fsm) == 0); : } : : static __attribute__((constructor)) void vgcs_bss_fsm_init(void) : { : OSMO_ASSERT(osmo_fsm_register(&vgcs_bss_fsm) == 0); : } : : static __attribute__((constructor)) void vgcs_cell_fsm_init(void) : { : OSMO_ASSERT(osmo_fsm_register(&vgcs_cell_fsm) == 0); : } : : static __attribute__((constructor)) void vgcs_mgw_ep_fsm_init(void) : { : OSMO_ASSERT(osmo_fsm_register(&vgcs_mgw_ep_fsm) == 0); : } is there a reason to have separate constructor symbols for this? Why not have one consturctor function which has N OSMO_ASSERT statements? https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/5676916c_34b24ae6 PS10, Line 152: sprintf(string, "%08u", callref); yes, 8 decimal digits plus zero termination is shorter than 16 characters, but I'd say as a matter of good practice we should still use snprintf. This makes it easier for somebody else to to audit the code, where every sprintf requires auditing if it's really ok, with snprintf you can just ignore it from manual audit/inspection. https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/f5c4c9e6_54602382 PS10, Line 222: if (with_prio) also here I would first build the 32bit value as a stack variable of uint32_t type and use msgb_put_u32() to avoid having to type-cast around and using the third byte of an uint32.... https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/96efd94e_f92b21a9 PS10, Line 232: int _ie_invalid(void) are those (_add_cause_ie, _add_callref_ie, _msg_too_short, _ie_invalid) really intended to be exported (non-static) functions? IF yes, then their name should be expanded to reflect they relate to ASCI as the name is very geneirc. If not, then they should be static. https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/436e05d4_dca1bc9d PS10, Line 249: e = msgb_put(msg, 1) you can first buld the uint8_t as a local variable and then use msgb_put_u8(msg, value), avoiding a pointer to an array and indexing only the 0th element in it. https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/48de5e4a_926d7567 PS10, Line 265: #if not sure why this is commented out? because there are no users yet and it's a static function? IF there is a good reason to do it like this, then add a comment as explanation, please. https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/4915c3cf_455819db PS10, Line 314: payload_len as you're decrmenting this variable, I thing I'd call it remaining_len or remaining_payload_len or something like that. payload_len sounds like the total length of the payloda field https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/1d80b9d4_bcf8d0f6 PS10, Line 323: [0] + 1; I don't have an immediate better solution, but I really think ti is very hard to read/follow and particularly had to say if it is correct, contains some overflows, .... You're basically incrementing the ie pointer as you go, but also deducting the payload_len pointer, both by the same amount, causing duplicate sub-expressions like "ie[0] + 1" which all must be consistent. https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/7c636d95_5af9fece PS10, Line 337: ie[0] + here I think you're trusting ie[0] blindly, without having done much checking on it? probably osmo_mobile_identity_decode() imlpicitly trusts it as it is used as input variable. https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/33b80962_fc054624 PS10, Line 346: ie += 4; in each of those blocks we have a magic value (length) that is used three times and which must be consistent. 4 here in this example. I think there must be a way without all those copies of the same value. Like some kind of helper functions, or in the worst case macros? https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/a6d317a3_034b52be PS10, Line 391: ie[0] = (da << 3) again I'd put the value together in a uint8_t local variable and then msgb_put_u8() it aftrewards. This way we're not de-refernecing the zero'th element in an aray of 1, which makes it harder to read (and one might assume the array might have more elements, ... https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/5c2a76a1_90ecbadf PS10, Line 416: if (ie[3] & 0x10) { same comments as other decoders above. https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/475f3568_92b349ae PS10, Line 604: osmo_fsm_inst_free(mgw->fi); we typically use the goto err_* label construct here to not have to repeat all the various free functions in every case. https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/e7774254_19940618 PS10, Line 694: return -EINVAL; here we return -EINVAL without talloc_free etc? https://gerrit.osmocom.org/c/osmo-msc/+/33511/comment/6dbde9df_e5b6777e PS10, Line 1279: int gsm44068_rcv_bcc_gcc(struct msc_a *msc_a, struct gsm_trans *trans, struct msgb *msg) this function is quite long. Even the variable list alone fills half a page on soem screen heights. That's usually a sign that it should be pslit up into sub-functions. -- To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/33511 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-msc Gerrit-Branch: master Gerrit-Change-Id: I9947403fde8212b66758104443c60aaacc8b1e7b Gerrit-Change-Number: 33511 Gerrit-PatchSet: 10 Gerrit-Owner: jolly &lt;andreas(a)eversberg.eu&gt; Gerrit-Reviewer: Jenkins Builder Gerrit-CC: dexter &lt;pmaier(a)sysmocom.de&gt; Gerrit-CC: laforge &lt;laforge(a)osmocom.org&gt; Gerrit-Attention: jolly &lt;andreas(a)eversberg.eu&gt; Gerrit-Comment-Date: Wed, 05 Jul 2023 13:36:36 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment