Change in osmo-bsc[master]: Add a bts_model->bts_init() and trx_init() call-back function

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/.

laforge gerrit-no-reply at lists.osmocom.org
Tue Dec 22 11:08:00 UTC 2020


laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bsc/+/21825 )

Change subject: Add a bts_model->bts_init() and trx_init() call-back function
......................................................................


Patch Set 1:

(2 comments)

https://gerrit.osmocom.org/c/osmo-bsc/+/21825/1/src/osmo-bsc/bts.c 
File src/osmo-bsc/bts.c:

https://gerrit.osmocom.org/c/osmo-bsc/+/21825/1/src/osmo-bsc/bts.c@513 
PS1, Line 513: 	if (model->trx_init) {
> I would rather hook all this into vty_go_parent cb so that it is called at the end of config (you ca […]
All of this sucks (and has sucked ever since we supported more than one BTS type/model).  You already run into massive problems today when you change the type back and forth at runtime, as we have various initialization and no cleanup.

So if you wanted to do this properly, you'd also have to add cleanup functions and whenever setting the type/model, first run cleanup of the old model, then init of the new one.

If you want to do it at every go_parent from the BTS, you would have to memorize of what the old type was at entering the node, and what the new type is.  So you can figure out if any change was made, and then only call the init if there was any change.

As there is no funding for this work, I just wanted to improve the usability (i.e. persistent MO FSMs that you can show) with minimal effort.


https://gerrit.osmocom.org/c/osmo-bsc/+/21825/1/src/osmo-bsc/bts_trx.c 
File src/osmo-bsc/bts_trx.c:

https://gerrit.osmocom.org/c/osmo-bsc/+/21825/1/src/osmo-bsc/bts_trx.c@123 
PS1, Line 123: 	if (bts->model && bts->model->trx_init) {
> I find a bit strange that you call trx_init() here and in the previous file too. […]
I put a comment at the other invocation:

"/* handle those TRX which are already allocated at the time we set the type */"

The point is when we allocate a BTS, we always allocate TRX0 as it's mandatory.  And at the time of allocation we don't know the type yet, and hence we cannot do type/model specific initialization.  So there is one path invoked when you add trx >=1 in the vty (here) and one path for the trx0 which pre-exists when you set the type.



-- 
To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/21825
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-bsc
Gerrit-Branch: master
Gerrit-Change-Id: Icbad9cdc12221c9ad997267d77e5414edcbac538
Gerrit-Change-Number: 21825
Gerrit-PatchSet: 1
Gerrit-Owner: laforge <laforge at osmocom.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: pespin <pespin at sysmocom.de>
Gerrit-Comment-Date: Tue, 22 Dec 2020 11:08:00 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin at sysmocom.de>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20201222/dc6f77b6/attachment.htm>


More information about the gerrit-log mailing list