Hi Daniel,
i am occasionally browsing the commitlog of the daniel/controlif branch and am wondering what exactly is happening there.
It seems much more to me that 'controlif' is about reimplementing a lot of the functionality that already exists in the VTY, which I think is bad.
My original understanding of the idea of SNMP support was: 1) we mostly want to export counters that we already have, but in a consistent/machine-parseable way. This is read-only 2) we may want to have traps 3) we have some (few!) things like rf_lock which should be issued (written) by the external SNMP process.
Has the focus changed since this last discussion? Can anyone explain why that is?
Even if we suddenly have a need for a lot of write/modify type settings from the SNMP side, we should not have two ways how to modify a single parameter inside OpenBSC. In that case we may need some code that can sort-of automatically 'export' all controlif parameter to the VTY, and remove the current code that sets this parameter from the VTY.
Any ideas?
Regards, Harald
On 12/09/2010 06:31 PM, Harald Welte wrote:
Hi Daniel,
Has the focus changed since this last discussion? Can anyone explain why that is?
The focus has not changed. There are two things I want out of it. Get statistics from the BSCs (we will query the nat/mux, which will..), turn off RF via the nat/mux.
I asked Daniel to start with something easy (this is why we have plenty of strcmp and if/else), it probably just appeared easy to add get/set for existing properties. As the second step I asked Daniel to somehow consolidate this and look at if we can use things from the VTY.
Even if we suddenly have a need for a lot of write/modify type settings from the SNMP side, we should not have two ways how to modify a single parameter inside OpenBSC. In that case we may need some code that can sort-of automatically 'export' all controlif parameter to the VTY, and remove the current code that sets this parameter from the VTY.
I agree that there should not be two ways in the long run. To ease Daniels work and have progress I asked him to ignore this problem of duplication for now and move things forward.
Personally I would like to see the branch to be in a state that it is solving the use case that we have discussed. This way we know what we will need from the code, as the second step I would look into integration and see how we will deal with the VTY overlap.
holger
-
Harald Welte -
Holger Hans Peter Freyther