Attention is currently required from: neels, laforge, fixeria, lynxis lazus.
7 comments:
Patchset:
I don't get why did you move the stuff to allstate again despite I explicitly told you not to do that. what's going on here? what's the rationale behind that? can you explain the problem in detail?
File include/osmocom/bsc/nm_common_fsm.h:
Patch Set #16, Line 41: NM_EV_RAMP_GO, /* BTS ramp allow to continue to configure */
"RAMP" is too generic here, maybe "NM_EV_SETUP_RAMO_GO".
File src/osmo-bsc/bsc_vty.c:
Patch Set #4, Line 3100: bts-setup-ramping-step-interval
As pespin proposed I followed the example of access-control-class-ramping and be consistent with acc […]
I'm fine with current proposal. Oteherwise you end up with a command "bts-setup-ramping" and a command starting with the same, which is confusing.
One could use "bts-setup-ramping enable (0|1)" too, but I don't see it's really needed. As pointed out we already have similar stuff with access-control-class-ramping.
File src/osmo-bsc/bsc_vty.c:
Patch Set #16, Line 3131: DEFUN_ATTR(cfg_bsc_no_bts_setup_ramping,
I'd move this one immediately below the "bts-setup-ramping" one, since it's its counterpart.
Patch Set #16, Line 3609: install_element(BSC_NODE, &cfg_bsc_bts_setup_ramping_cmd);
See. here you put the 2 commands together (correct).
File src/osmo-bsc/bts_setup_ramp.c:
Patch Set #16, Line 86: { BTS_SETUP_RAMP_GO, "Go" },
(I find the "go" state a bit weird tbh, "Ready" would fit more imho).
File src/osmo-bsc/nm_bb_transc_fsm.c:
Patch Set #16, Line 347: case NM_BB_TRANSC_ST_OP_DISABLED_DEPENDENCY:
I'm still not getting why you keep putting this in the allstate. Put it in the relevant states like all the other stuff calling the configure_loop().
AFAIU this event can only come while the BTS is being configured.
To view, visit change 29788. To unsubscribe, or for help writing mail filters, visit settings.