Attention is currently required from: laforge.

wbokslag has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-tetra/+/34000 )

Change subject: Fixups and clarifying comments for msgb tail modifications ......................................................................

Patch Set 2:

(2 comments)

Patchset:

PS2: After further inspection, I find the msgb_trim function uses msgb->data as a reference, which is a problem, due to the multiple-resources-per-timeslot scenario. It would work if l1h were used as a reference, since I move that pointer forward in tetra_lower_mac.c. I'm not against refactoring all the manual field manipulation to an osmocom buffer manipulation function but can you suggest a way to do it properly?

What's the semantically correct way to deal with multiple upper mac messages in a buffer?

File src/lower_mac/tetra_lower_mac.c:

https://gerrit.osmocom.org/c/osmo-tetra/+/34000/comment/173bdf49_1109459c PS2, Line 347: msg->len = msg

Okay, I appreciate the comments and effort to maintain good code quality. […]

After further inspection, I find the msgb_trim function uses msgb->data as a reference, which is a problem, due to the multiple-resources-per-timeslot scenario. It would work if l1h were used as a reference, since I move that pointer forward in tetra_lower_mac.c. I'm not against refactoring all the manual field manipulation to an osmocom buffer manipulation function but can you suggest a way to do it properly?

What's the semantically correct way to deal with multiple upper mac messages in a buffer?