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/OpenBSC@lists.osmocom.org/.
Holger Freyther zecke at selfish.orgOn 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...