Branches update & things to consider for merging

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/.

Sylvain Munaut 246tnt at gmail.com
Sun Jan 3 10:22:25 UTC 2010


Hi,

Thanks, I've cherry-picked all I could right now.
>
> I'll have to test the software activation related changes with my nanoBTS's
> and
> with the BS-11.  I expect to do this later today.
>

Great !

What about the rrlp branch ? They are only changes to rrlp-ephemeris and the
.gitignore patch is especially useful to ignore the output of asn1c (without
that git detects thousands of new files if you have built it :)



> As for the ebab9a9e (Differentiate paging success), I think this code
> needs to update 04_11.c and silent_call.c as well, i.e. all locations
> where PAGING_SUCCEEDED is is currently used.
>

Mmm, I don't understand what you mean here.

in 04_11 & silent call, it's not the signal dispatch that's used but the
call back specified when making the paging request.
The advantage of the call back is that you can give contextual information
and it's only called for that specific

It's true that for sms, we could just check every time a paging succeed if
there are pending SMS ...
But for silent_call & 04_08 MT calls I think the call back need to stay.



>  > sylvain/encryption: The current state of my encryption support work. I
> > rebased it and used the db structure you pushed for encryption.
> Everything
> > but the last 3 patches are pre-work / preparation / fixes and are imho
> OK.
> > The last 3 patches are the real implementation and I also think they're
> in
> > pretty good shape. Tested and working here :) Limitations includes : No
> Kc
> > re-use & No MT encryption yet.
>
> I disagree with removing the 'id' primary key for AuthTuples and AuthKeys.
>
> Without that id we have it very hard to remove a single authtuple from the
> database manually, since we would have to provide the subscriber_id and
> some
> BLOB to select only a single entry.  This is why I did not merge this
> particular
> commit.
>

?
In both table, you have :

  subscriber_id NUMERIC UNIQUE NOT NULL,

since there is a UNIQUE, there can't be two entries for the same subscriber
and so you can just delete by specifying the subscriber_id.


> All the others (minus the last three) inside the encryption branch should
> have been merged now.
>
> It would be great if you can rebase those last three commits and your
> encryption_testing branch on current master and continue testing.
>

Sure.

Cheers,

    Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20100103/8f0a32f0/attachment.htm>


More information about the OpenBSC mailing list