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/.
Andreas.Eversberg Andreas.Eversberg at versatel.de> One thing that keeps me from pushing (after having tested) is the following observation. For going from layer3 to layer4 we currently have a queue, for my patches when going from layer2 to layer3 I have a direct callback. Should I change that to use the same queuing approach? hi holger, for me it is very hard to explain, but i will try... - bsc = lower layer (signalling) - msc = upper layer (application) actually we need a queue in only one direction, if we link two finite state machines. (or in our case link two instances of transactions using mncc.c). during an bsc-event, when a message from bsc is sent to msc, the bsc might do some processing right after sending the message. without a queue, the msc could reply directly to that message (with a function call to msc) which may change the state machine of bsc, while bsc is still processing the first event... (race condition) an up-queue from bsc to msc will fix that problem. msc will only process messages, if bsc has finished it's processing of events. in case of a message from msc to bsc, we also don't have that problem, even without a queue. if msc sends a message directly down to bsc (using a function call), an eventually direct reply is queued in the up-queue, so msc can finish processing the first event before processing the message in the up-queue. it does not matter if the queue is for messages from bsc to msc, or from msc to bsc, but at least we need one queue. it may happen that a message is dequeued, but the call instance is already gone. in this case the other layer (bsc or msc) should ignore it. this is why the call reference is used instead of a memory pointer. also it must be unique all the (run-)time. regards, andreas