Hi Sylvain,
On Sun, Jan 03, 2010 at 11:22:25AM +0100, Sylvain Munaut wrote:
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.
this still hasn't happened, I suppose I'll get around doing it today.
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 :)
I have merged it right now. Feel free to commit directly to the master branch as long as you only touch rrlp-ephemeris code. After all, it's your code!
I just didn't want direct commit's to openbsc in the master branch. Thanks.
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.
It was my misunderstanding, sorry. I've applied it now.
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.
That's wrong then. subscriber_id should be unique for AuthInfo, but not for AuthTuples. We can (and should!) have multiple auth tuples for a subscriber and also think of a way how we can cycle through them (or randomly select one of them each time we need one)
Also, if subscriber_id is UNIQUE in AuthInfo, then we can remove the id there, like you proposed.