From: git repository hosting <gitosis@osmocom.org>
Precedence: list
To: osmocom-commitlog@lists.osmocom.org
Date: Sat, 29 Dec 2012 22:04:38 +0100
Message-ID: <E1Tp3aA-000419-Me@calypso.gnumonks.org>
Subject: osmo-bts.git branch zecke/channel-ho-wip updated. 0.1.0-40-gbdb51c0
Message: 18

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Osmocom BTS-side code (Abis, scheduling, ...)".

The branch, zecke/channel-ho-wip has been updated
  discards  098a267ca5be77d07042764be356d800acd26ab5 (commit)
  discards  2a300fa3692423a6efe07b420568129a4393f45b (commit)
  discards  a7c4d3b049c8684bbd74d97c95265403f8c98530 (commit)
  discards  7940abe46b39f7163336b0a3a1728404f94bdb66 (commit)
  discards  3750891fff0e39f68fa4845983dd5c1259c82b63 (commit)
       via  bdb51c041302a03fd790660448b5840fc7b49129 (commit)
       via  8cdce893b15b6cfd8bdb591c576bed6e59bb2ff2 (commit)
       via  3338585ebe35b9892b85f6cb9c804b7fb9c549be (commit)
       via  3acbe6ccaac8d79e81888fff0175aaad8e3fe234 (commit)
       via  19c972aba375def04d8e36447f381e97ca08d398 (commit)

This update added new revisions after undoing existing revisions.  That is
to say, the old revision is not a strict subset of the new revision.  This
situation occurs when you --force push a change and generate a repository
containing something like this:

 * -- * -- B -- O -- O -- O (098a267ca5be77d07042764be356d800acd26ab5)
            \
             N -- N -- N (bdb51c041302a03fd790660448b5840fc7b49129)

When this happens we assume that you've already had alert emails for all
of the O revisions, and so we here report only the revisions in the N
branch from the common base, B.

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
http://cgit.osmocom.org/cgit/osmo-bts/commit/?id=bdb51c041302a03fd790660448b5840fc7b49129

commit bdb51c041302a03fd790660448b5840fc7b49129
Author: Holger Hans Peter Freyther <zecke@selfish.org>
Date:   Sat Dec 29 18:10:12 2012 +0100

    sysmobts/lchan: Simplify code now that DIR_BOTH is gone

http://cgit.osmocom.org/cgit/osmo-bts/commit/?id=8cdce893b15b6cfd8bdb591c576bed6e59bb2ff2

commit 8cdce893b15b6cfd8bdb591c576bed6e59bb2ff2
Author: Holger Hans Peter Freyther <zecke@selfish.org>
Date:   Sat Dec 29 18:06:08 2012 +0100

    sysmobts/lchan: Add various static and runtime checks for SAPI code

http://cgit.osmocom.org/cgit/osmo-bts/commit/?id=3338585ebe35b9892b85f6cb9c804b7fb9c549be

commit 3338585ebe35b9892b85f6cb9c804b7fb9c549be
Author: Holger Hans Peter Freyther <zecke@selfish.org>
Date:   Sat Dec 29 17:38:50 2012 +0100

    sysmobts/lchan: Send a Channel Activate Ack when all SAPIs are established

http://cgit.osmocom.org/cgit/osmo-bts/commit/?id=3acbe6ccaac8d79e81888fff0175aaad8e3fe234

commit 3acbe6ccaac8d79e81888fff0175aaad8e3fe234
Author: Holger Hans Peter Freyther <zecke@selfish.org>
Date:   Sat Dec 29 16:45:29 2012 +0100

    sysmobts/lchan: On channel release, release all allocated SAPIs
    
    This make sures that everything will be released that was allocated
    during the lifetime of the channel. The code assumes that all previous
    requests are handled and no activation request is pending.

http://cgit.osmocom.org/cgit/osmo-bts/commit/?id=19c972aba375def04d8e36447f381e97ca08d398

commit 19c972aba375def04d8e36447f381e97ca08d398
Author: Holger Hans Peter Freyther <zecke@selfish.org>
Date:   Sat Dec 29 16:51:09 2012 +0100

    sysmobts/lchan: Release the lchan when all requests are handled
    
    When the lchan is in the release request state and all SAPI requests
    were handled by the dsp we can send the ACK to the BSC. In case of
    a single sapi failing we will still need to wait until all the other
    requests were handled.
    
    The rel request code will schedule the release of the required SAPIs
    and once these requets are handled we are done. We don't need to check
    if all SAPIs are in the none state. There is no RF Channel Release NACK
    so we will need to ACK the release and remember that some SAPIs are
    faulty and prevent the channel from being allocated again.
    
    In the future the release code could and should check if any release
    was scheduled at all.

-----------------------------------------------------------------------

Summary of changes:
 src/osmo-bts-sysmo/oml.c |   20 ++++++++++++--------
 1 files changed, 12 insertions(+), 8 deletions(-)


hooks/post-receive
-- 
Osmocom BTS-side code (Abis, scheduling, ...)


