lchan_free() is called when RSL released the logical channel. all ressources that 'uses' the channel, must be released. i aggree with you, that it makes no sense to consider everything that 'uses' the logical channel. to fix this, i have an idea and need some response before implementing.
problems:
- what instance uses the logical channel?
- how do we release them, if the channel is closed?
- how do we change the channel (handover/SDCCH->TCH ...)? (is this required?)
one possible solution:
every logical channel gets a list of 'users'. these users have nodes in this list. users can be i.e.: an active call, a call on hold, an SMS transaction, a location update....
each node has a pointer to the lchan. the 'user' can access the logical channel via node.
each node has a destructor function pointer. during lchan_free(), the destructor of each node is called. the 'user' will remove the node. with that, the chan_alloc does not need to know how to free 'users'
if we want to change the logical channel, we just unlink the nodes from the old channel and attach them to the new channel.
each node has:
- "struct llist_head" to link to previous and next node
- pointer to the logical channel (lchan)
- pointer to the destructor for the node owner. (the 'user')
- void pointer to the owner's private structure.
user 'uses' a channel:
- it calls the lchan_use() function with the logical channel, the destructor, and private structure pointer
- the node is created and linked to the logical channel
- the pointers within that node are set
user 'drops' a channel:
- it calls the lchan_put() function with the pointer to the node.
- the node is unlinked from lchan and destroyed
lchan closes:
- for each node of a logical channel, the destructor is created.
- within this destructor, the 'user' must remove all relations to that channel, remove the node, and set the node pointer to NULL.
user can refers to it's channel:
struct gsm_lchan *lchan = private->lchan_node->lchan;
what do you think?
-----Ursprüngliche Nachricht-----
Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther
Gesendet: Dienstag, 2. Juni 2009 03:02
An: openbsc(a)lists.gnumonks.org
Betreff: Re: patch 22: lchan_use
I don't like this part. First of all when making release_loc_update_req
"public" it should be properly prefixed, but I don't think chan_alloc.c should
know/care about gsm_04_08.c at all. Also tying the timeout of the Location
Update with the autorelease of the channel does not seem appropriate.
I would very much prefer if this logic can stay within gsm_04_08.c and we fix
the usage count issue there.
For me it looks like:
- We get a reference when creating the loc_update_request
- We start a timer
- We put the reference when destroying the loc update request...
- So we might just remove the extra put/use for the waiting for IMSI/IMEI
and fix the "leak" like this?
what do you think?
z.
Hello,
I want to sync the e1 card with a HFC-s card, which is attached to my
ISDN line.
How do I have to interconnect the two cards?
Best regards
Björn
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Björn Heller
Jabber: tec(a)jabber.hellercom.de
correction: patch 12 (not 13) uses dynamic transactions.
-----Ursprüngliche Nachricht-----
Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Andreas.Eversberg
Gesendet: Samstag, 23. Mai 2009 10:21
An: Harald Welte
Cc: openbsc(a)lists.gnumonks.org
Betreff: AW: patch: 8_paging
here is the problem: we don't know about the called bts, if
- the subscriber detaches after paging was started and the current_bts pointer inside subscriber is NULL.
- the lchan is not set because paging expires.
we can use the network pointer instead of the bts pointer for paging callback function. the gsm_network is required when paging result is received. all transactions (call instances) are linked in a list in gsm_network. (see patch 13) even if paging expires, the transactions in this list with the same subscriber must be released. (MO out of order)
but it is more complex: the subscriber will not be NULL, because it is "used" by the transactions. the use-counter of subscriber is increased for every transaction created and decreased on release of that transaction. if there is a call process for the paged subscriber, the subscr is set when paging response is received. we need at least a pointer to the network to access the transactions.
we can keep paging callback function without bts (or network) pointer, but then we need a network pointer in gsm_subscriber to process the network's paging result.
-----Ursprüngliche Nachricht-----
Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Andreas.Eversberg
Gesendet: Samstag, 23. Mai 2009 09:47
An: Harald Welte
Cc: openbsc(a)lists.gnumonks.org
Betreff: AW: patch: 8_paging
i use the calling party's BTS, because the subscriber database does not contain the current BTS number of the subscriber last seen. (or detached)
i agree that the subscriber gives us information about the paged bts and we can resolve the gsm_network from that also.
-----Ursprüngliche Nachricht-----
Von: Harald Welte [mailto:laforge@gnumonks.org]
Gesendet: Samstag, 23. Mai 2009 08:30
An: Andreas.Eversberg
Cc: openbsc(a)lists.gnumonks.org
Betreff: Re: patch: 8_paging
Hi again,
On Sat, May 23, 2009 at 02:23:11PM +0800, Harald Welte wrote:
> On Thu, May 21, 2009 at 02:27:36PM +0200, Andreas.Eversberg wrote:
> > Paging refers to a BTS. To page a mobile phone, the current location
> > is required. If paging succeeds or expires, the BTS structure is
> > also given to the callback function (cbfn).
> >
> > Because paging refers to a BTS, the cbfn (callback function) must
> > include a pointer to bts.
>
> The paging response includes a lchan pointer, which can be resolved to
> the physical channel / timeslot and to the trx and finally to the BTS.
> Is this not sufficient?
Ah, ok, in the case we do not successfully allocate a lchan, then that's obviously NULL.
Still, when you call paging_request() you actually pass on a number of parameters, including:
1) the BTS on which you want to page (whcih, indeed, is currently the
BTS of the calling party rather than the called party). So this parameter
is likely to get removed soon.
2) The subscriber that was called. This should be used by paging_request()
to resolve the BTS that this subscriber was last seen/registered to.
3) a reference to the call, which is treated as an opaque pointer that
is passed back as a reference when calling the call-back function. So
if the bts of the calling or called party needs to be known, it should
probably be referenced from that data structure.
Or am I missing something?
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
i don't know what autoreconf is.
root@fuckup:~/gsm/openbsc.orig# autoreconf
configure.in: required file `./install-sh' not found
configure.in: required file `./mkinstalldirs' not found
configure.in: required file `./missing' not found
src/Makefile.am: required file `./depcomp' not found
autoreconf: automake failed with exit status: 1
root@fuckup:~/gsm/openbsc.orig#
maybe i need to update autoconf...
>> Adding "autogen.sh". It generates files like "configure".
>>
>> Question: Do we need this? Without it, I cannot compile OpenBSC.
>
>Why is invoking autoreconf not enough?
>
>z.
-----Ursprüngliche Nachricht-----
Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther
>And I was too fast. I have one more question. Could you please explain the
>extra call to:
> subscr_update(lchan->subscr, bts, GSM_SUBSCRIBER_UPDATE_ATTACHED);
i don't know why, but i will check that tonight too.
hi,
finally my patch is documented (almost). you will find the documentation
of the patch:
http://home.eversberg.eu/stage1.html
the patch in plain text fromat:
http://home.eversberg.eu/stage1.patch
it also includes the changes i posted here before. if you have
questions, ask.
regards,
andreas
Tells mISDN not to release layer 2 on closing socket, when not
requested. If mISDN was told to release layer 2 once, it will continue
to release layer 2 on every shutdown of OpenBSC.
During bootstrap of BS11, the e1links are initialized. This must also be
done when BS11 is already bootstrapped (when restarting OpenBSC). It is
required to correctly multiplex the audio traffic between channels.
Without it, all time slots refer to card 0, slot 0, subslot 0, which
causes crashes when handling TRAU frames..
