Hi Holger, On Wed, Jun 17, 2015 at 2:04 AM, Holger Freyther <[email protected]> wrote: >> On 15 Jun 2015, at 21:01, Alexander Chemeris <[email protected]> >> wrote: >> I agree that transactional functionality would be nice and I had been >> thinking about this. But it's a big change which should be well planned and >> requires considerable effort to go through all commands and split >> configuration from application. One issue is that we'll need to create >> "shadow" registers for the non applied settings. E.g. in case of power >> control, the setting was actually applied at the BSC part of the control (it >> was using the setting variable directly), but was not propagated to the BTS >> party, which was really confusing from a user perspective. >> >> In short - I agree that such feature would be nice, but I don't think this >> is a showstopper for this patch, because it just makes things more >> consistent. > > > we will not be able to find an agreement here. The current behavior is not > consistent (we > have attributes that apply immediately, after a BTS restart or even only > after the restart of > the system). Moving one VTY command from one class to another doesn’t improve > the > consistency in any way. The same inconsistency remains in the system, we face > the same > issue in documenting the inconsistencies.
Please note that the current behavior of this command is that it already applies the change immediately by setting bts->ms_max_power. This value is then used at rsl_rx_chan_rqd() to initialize lchan->ms_power. But it does not apply it to SIs sent by the same BTS, which makes the effect of the command inconsistent. The commit I suggest just makes the behavior of the command consistent. Please also note that it makes complete sense to apply this value immediately when you're doing live cell tuning. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co Subscribe to Fairwaves news: http://eepurl.com/baL_pf
