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/.
fixeria gerrit-no-reply at lists.osmocom.orgfixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/21185 ) Change subject: l1sap: add repeated uplink SACCH ...................................................................... Patch Set 3: Code-Review-1 (6 comments) https://gerrit.osmocom.org/c/osmo-bts/+/21185/3/src/osmo-bts-trx/sched_lchan_xcch.c File src/osmo-bts-trx/sched_lchan_xcch.c: https://gerrit.osmocom.org/c/osmo-bts/+/21185/3/src/osmo-bts-trx/sched_lchan_xcch.c@63 PS3, Line 63: repeated_ul_sacch_active_decision Not sure if this file (which is more about mapping, interleaving, and convolutional coding) is the right place for such logic. Maybe l1sap is a better place? Not a merge blocker though. If you decide to keep it here, make it 'static', as it's a performance critical place. https://gerrit.osmocom.org/c/osmo-bts/+/21185/3/src/osmo-bts-trx/sched_lchan_xcch.c@101 PS3, Line 101: talloc_zero_size Not really related, but I think we should move memory allocations out of the burst handlers. This needs to be done once during the channel activation, not on receipt of *every Uplink burst*. https://gerrit.osmocom.org/c/osmo-bts/+/21185/3/src/osmo-bts-trx/sched_lchan_xcch.c@111 PS3, Line 111: *chan_state->ul_bursts_prev This is wrong, and may lead to NULL-pointer dereference if talloc returns NULL. CR-1. https://gerrit.osmocom.org/c/osmo-bts/+/21185/3/src/osmo-bts-trx/sched_lchan_xcch.c@178 PS3, Line 178: LOGL_NOTICE Not sure if this event actually deserves NOTICE. I would drop this logging statement. https://gerrit.osmocom.org/c/osmo-bts/+/21185/3/src/osmo-bts-trx/sched_lchan_xcch.c@179 PS3, Line 179: also yields good data ... and this reads really weird. Do we get good data block twice? https://gerrit.osmocom.org/c/osmo-bts/+/21185/3/src/osmo-bts-trx/sched_lchan_xcch.c@192 PS3, Line 192: L1SAP_IS_LINK_SACCH(trx_chan_desc[chan].link_id) && lchan->repeated_ul_sacch_active I think it makes sense to pre-calculate this condition into a boolean variable, given that you're using this combination three times. -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/21185 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: I7e4cc33cc010866e41e3b594351a7f7bf93e08ac Gerrit-Change-Number: 21185 Gerrit-PatchSet: 3 Gerrit-Owner: dexter <pmaier at sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy at sysmocom.de> Gerrit-Comment-Date: Thu, 19 Nov 2020 17:38:08 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: Yes Gerrit-MessageType: comment -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20201119/01d29c16/attachment.htm>