22 Jun
2010
22 Jun
'10
11:46 a.m.
On 06/22/2010 09:35 AM, Holger Hans Peter Freyther wrote:
On 06/21/2010 11:54 PM, Harald Welte wrote:
> At the moment I'm slightly more inclined to actually go for '2', since it
is
> a cleaner solution from my point of view.
>
> What do you think?
I see how the blocking semantic of an opstart and such
is very
appealing, we do not need to worry about the queue but the kernel will
queue messages for us.
Today I was searching for Coroutines and Tasklets for C again and wonder
if we could use that, we should not rely on createcontext and such as it
is not available on ARM. Another option would be to use fork and have a
socketpair between OpenBSC OML and OpenBSC proper and forward OML
messages in both ways.
We could kill the process whenever the BTS is gone, and create it once
it is up. This would also mean config changes would be handled on every
BTS reconnect..
And I felt lazy and created zecke/nm-long-queue which appears to work
for BTS bringup and ipaccess-config -r -o IP BTS...