Project

General

Profile

Bug #3833

Fix storage location of AMR S15-S0 bits

Added by dexter over 1 year ago. Updated 9 months ago.

Status:
New
Priority:
Low
Assignee:
Category:
-
Target version:
-
Start date:
03/11/2019
Due date:
% Done:

0%

Spec Reference:

Description

The current storage location of s15_s0 (lchan->activate.info.s15_s0) is incorrect by the current memory model. This should be fixed by finding a proper storage location that fits into the current memory model.

See also:
https://gerrit.osmocom.org/#/c/osmo-bsc/+/13200/
https://gerrit.osmocom.org/#/c/osmo-bsc/+/13039/


Related issues

Related to OsmoBSC - Bug #3787: Assignment Request modifies conn->codec_list before the Assignment is successfulNew02/07/2019

History

#1 Updated by laforge over 1 year ago

  • Status changed from New to Feedback

both patches are merged. Does that fix/resolved this issue?

#2 Updated by dexter over 1 year ago

Its a "cosmetic" problem. Neels has some model in mind where temporary and permanent values should be stored. I am not sure that I understand every aspect of this right. I think we should wait until neels is back and then we can fix this together. There is no pressure on this, technically its just moving a struct member to the correct sub struct to have everything consistent.

#3 Updated by neels about 1 year ago

lchan->activate.info = the settings that were requested on lchan_activate(). So lchan->activate.* is preliminary and volatile, used before the lchan actually is activated successfully.

As soon as the lchan activation is successful, all valid information should end up in lchan->foo fields (outside of lchan->activate),
in this case probably lchan->s15_s0.

The distinction is quite trivial. lchan->activate contains the settings that are requested before setting up the lchan, and aren't verified to be really active.

At any time, some code (bug?) might try to invoke another activation request and overwrite lchan->activate.* data.
So any items that describe the actually active lchan should not be kept in lchan->activate.*

A similar concept exists in various other FSMs, it is an important mechanism that separates possibly invalid manipulation requests from the actually verified active settings.

#4 Updated by laforge 10 months ago

  • Priority changed from Normal to Low

#5 Updated by neels 9 months ago

  • Status changed from Feedback to New
  • Assignee changed from dexter to neels

laforge wrote:

both patches are merged. Does that fix/resolved this issue?

The linked issue https://gerrit.osmocom.org/c/osmo-bsc/+/13039 was merged still containing the problem.
It is however "merely" a cosmetic / code maintenance problem, not distinguishable by the user.
I guess I should just clean this up since original authors clearly can't be bothered.

#6 Updated by neels 9 months ago

  • Related to Bug #3787: Assignment Request modifies conn->codec_list before the Assignment is successful added

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)