laforge has abandoned this change. ( https://gerrit.osmocom.org/c/pysim/+/39746?usp=email )
Change subject: [6/7] personalization: refactor K, Opc
......................................................................
Abandoned
looks like this was merged into https://gerrit.osmocom.org/c/pysim/+/39745 and it was forgotten to abandon this one?
--
To view, visit https://gerrit.osmocom.org/c/pysim/+/39746?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: abandon
Gerrit-Project: pysim
Gerrit-Branch: master
Gerrit-Change-Id: I966817db38333b6c82f8e316552dfc987e23ab70
Gerrit-Change-Number: 39746
Gerrit-PatchSet: 2
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Attention is currently required from: dexter, fixeria, neels.
laforge has posted comments on this change by neels. ( https://gerrit.osmocom.org/c/pysim/+/39742?usp=email )
Change subject: [2/6] personalization: refactor ConfigurableParameter, Iccid, Imsi
......................................................................
Patch Set 7: Code-Review+1
(2 comments)
File pySim/esim/saip/personalization.py:
https://gerrit.osmocom.org/c/pysim/+/39742/comment/77dfcdc5_a3eee2d7?usp=em… :
PS7, Line 67: =
shouldn't that be a double-equals (also below)? to me it looks like an assignment rather than a comparison?
https://gerrit.osmocom.org/c/pysim/+/39742/comment/a0f0005a_ad7564bd?usp=em… :
PS7, Line 100: allow_types = (str, int, )
Does the comma with empty element imply that None is a vaid input value? In that case, I'd prefer an explicit None. Not critical. Just saying I don't understand the way that code is written.
--
To view, visit https://gerrit.osmocom.org/c/pysim/+/39742?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: pysim
Gerrit-Branch: master
Gerrit-Change-Id: I6522be4c463e34897ca9bff2309b3706a88b3ce8
Gerrit-Change-Number: 39742
Gerrit-PatchSet: 7
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: dexter <pmaier(a)sysmocom.de>
Gerrit-Comment-Date: Sat, 19 Apr 2025 16:11:45 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
Attention is currently required from: fixeria, neels.
laforge has posted comments on this change by neels. ( https://gerrit.osmocom.org/c/pysim/+/39741?usp=email )
Change subject: [1/6] personalization: refactor: drop ClassVarMeta use
......................................................................
Patch Set 7:
(1 comment)
File pySim/esim/saip/personalization.py:
https://gerrit.osmocom.org/c/pysim/+/39741/comment/f3b91bd8_214049bb?usp=em… :
PS7, Line 155: class SdKeyScp80_01(SdKey):
I'm still somewhat doubtful that this is an improvement. You're turning something that was a very nice single-line syntax into something that now needs three lines to declare something. The original syntax was almost like a table, with columns listing each key_id and key_usage_qual at the same positinin of each line...
What I really fail to see is some kind of argument in the commit log how the new approach is better than the old one.
I really don't want to spend weeks or months arguing about this. I just want to understand what is the improvement here. "Not using a metaclass" doesn't seem like a qualitative improvement of the code. What was the problem caused by the metaclass? Why is it desirable to not use one? The questions are not rhethorical. I tend to use metaclasses quite a bit in pySim and elsewhere, and so far nobody has argued in code review that anything is wrong about this.
--
To view, visit https://gerrit.osmocom.org/c/pysim/+/39741?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: pysim
Gerrit-Branch: master
Gerrit-Change-Id: I60ea8fd11fb438ec90ddb08b17b658cbb789c051
Gerrit-Change-Number: 39741
Gerrit-PatchSet: 7
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Sat, 19 Apr 2025 16:07:25 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Attention is currently required from: fixeria.
kirr has posted comments on this change by kirr. ( https://gerrit.osmocom.org/c/osmocom-bb/+/40047?usp=email )
Change subject: trx_toolkit/clck_gen: Don't use threads because Python GIL is latency killer
......................................................................
Patch Set 1:
(1 comment)
Patchset:
PS1:
> P.S. However one thing that could be maybe possible to maybe do is to merge the patch > of pyx timerfd right after switch to cython. Then the time where fake_trx becomes py3.13-only will be limited.
I moved `trx_toolkit/_clck_gen: Unroll our own timerfd_* functions` to come right after `trx_toolkit: Move FakeTRX-related performance-sensitive modules to Cython` in the patch series as explained above.
--
To view, visit https://gerrit.osmocom.org/c/osmocom-bb/+/40047?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmocom-bb
Gerrit-Branch: master
Gerrit-Change-Id: Iaa675c95059ec8ccfad667f69984d5a7f608c249
Gerrit-Change-Number: 40047
Gerrit-PatchSet: 1
Gerrit-Owner: kirr <kirr(a)nexedi.com>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-CC: osmith <osmith(a)sysmocom.de>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 18 Apr 2025 08:19:17 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: kirr <kirr(a)nexedi.com>
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Attention is currently required from: fixeria.
kirr has posted comments on this change by kirr. ( https://gerrit.osmocom.org/c/osmocom-bb/+/40047?usp=email )
Change subject: trx_toolkit/clck_gen: Don't use threads because Python GIL is latency killer
......................................................................
Patch Set 1:
(1 comment)
Patchset:
PS1:
> Looks good to me, thank you! […]
Vadim, thanks for feedback.
There are drawbacks of both approaches: if we do it earlier in the patchset, then faketrx cannot work without cython at all. However this fix does not require cython and can be done in pure python. It brings significant benefit just by itself, but unfortunately that speedup is not enough.
Overall the problem here is similar to bootstrapping: you cannot really do via single-step without braking something: do single step in plain py - we break compatibility with py < 3.13. Do single step with upgrading to cython: we break compatibility with current tests because they all do currently fail as it is not programmed there to build fake_trx before running it.
I choosed to do this step in plain py without bringing cython yet, because it looks more logical to me to fix this while being at plain py level.
Reworking the patches to bring cython earlier would be alot of internal inter-patch churn without, in my view, strong benefit. I would appreciate if we can leave the order of steps as they are currently.
Kirill
P.S. However one thing that could be maybe possible to maybe do is to merge the patch of pyx timerfd right after switch to cython. Then the time where fake_trx becomes py3.13-only will be limited.
--
To view, visit https://gerrit.osmocom.org/c/osmocom-bb/+/40047?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmocom-bb
Gerrit-Branch: master
Gerrit-Change-Id: Iaa675c95059ec8ccfad667f69984d5a7f608c249
Gerrit-Change-Number: 40047
Gerrit-PatchSet: 1
Gerrit-Owner: kirr <kirr(a)nexedi.com>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-CC: osmith <osmith(a)sysmocom.de>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 18 Apr 2025 08:12:29 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: kirr <kirr(a)nexedi.com>
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Attention is currently required from: kirr.
fixeria has posted comments on this change by kirr. ( https://gerrit.osmocom.org/c/osmocom-bb/+/40047?usp=email )
Change subject: trx_toolkit/clck_gen: Don't use threads because Python GIL is latency killer
......................................................................
Patch Set 1:
(1 comment)
Patchset:
PS1:
> > Unfortunately os.timerfd_create() & friends are only available starting […]
Looks good to me, thank you!
Just one moment: can we somehow do this earlier in the patchset? Otherwise one would have to bypass the build verification for most of the patches in this set. Not only this is annoying (it needs to be done manually for each patch), but also imposes a risk of not noticing a regression somewhere in the middle.
--
To view, visit https://gerrit.osmocom.org/c/osmocom-bb/+/40047?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmocom-bb
Gerrit-Branch: master
Gerrit-Change-Id: Iaa675c95059ec8ccfad667f69984d5a7f608c249
Gerrit-Change-Number: 40047
Gerrit-PatchSet: 1
Gerrit-Owner: kirr <kirr(a)nexedi.com>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-CC: osmith <osmith(a)sysmocom.de>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: kirr <kirr(a)nexedi.com>
Gerrit-Comment-Date: Fri, 18 Apr 2025 07:24:15 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: kirr <kirr(a)nexedi.com>
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>