> On 20 Jan 2016, at 16:57, suraev(a)alumni.ntnu.no wrote:
>
> From: Max <msuraev(a)sysmocom.de>
Hi,
> Some tests are leaky which is ok since it's one-shot programs
> anyway. For them mem. leak sanitizer is explicitly disabled via
> env. variables.
I think it is best to use the OpenBSC mailinglist for libosmocore
and other libraries.
From my point of view it really makes sense to have ASAN build and
run the tests (and include leak check if we can ignore some globals)
but I have a couple of issues with the specific patch:
1.) not all compilers we use support ASAN
2.) Just compiling the test doesn't help us to verify the library
itself. It needs to be instrumented too!
So my proposal would be:
1.) We get a gcc 5.x or clang on one of the linux builders (or I will
create one)
2.) We use your AT_CHECK check so we can pass this variable from the
outside too.
3.) We have a Jenkins nightly job that does make CFLAGS+="-fsanitize.."
CXXFLAGS+=.. check on all dependencies
> +AT_COLOR_TESTS
What does this give us?
> -AT_CHECK([$abs_top_builddir/tests/msgfile/msgfile_test], [0], [expout])
> +AT_CHECK([ASAN_OPTIONS="detect_leaks=0" $abs_top_builddir/tests/msgfile/msgfile_test], [0], [expout])
Did you have a look at osmo-bts and how I sneaked in support for using
qemu to execute the tests?
Hi,
I'm just noticing
warning: ‘dbi_initialize’ is deprecated (declared at /usr/include/dbi/dbi.h:169)
called from
openbsc/openbsc/src/libmsc/db.c:db_init()
(and a couple more dbi deprecations)
Should we do something about it?
...rather: who and when? ;)
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
Hi Thomas,
in case you'd like to add it to your benchmark results, below is a run
of trx-bench on a Debian stable (jessie) system on a G-T40E CPU @ 800MHz.
What I find surprising is that it appears to be comparable than the Atom
D2500 @ 1.86GHz, despite the Atom running at twice the clock rate...
More details see attachments.
Regards,
Harald
--
- 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)
Hi buy a bts3900B on Ebay. I have a project similar to yours. I want to know if it was possible to open the connection with BSC. I also want my users to browse internet through my mobile network. I appreciate your help in my project.
From: Jacob Erlbeck <jerlbeck(a)sysmocom.de>
This commit adds this predicate function which can be used to
avoid the execution of code if a certain log level is not enabled.
The function will only return 0 (false), if it is sure that a logging
call for the same facility and level will not produce any output.
This safety criterion shall ensure, that no logging output is lost
due to the use of this predicate as a guard. On the other hand, even
if the predicate returns != 0 (true), no logging output might get
generated by a similar logging command.
Note that the current implementation is not focussed on performance,
which could be improved by using a lookup table instead of iterating
through every target.
Sponsored-by: On-Waves ehf
---
include/osmocom/core/logging.h | 1 +
src/logging.c | 39 +++++++++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+)
diff --git a/include/osmocom/core/logging.h b/include/osmocom/core/logging.h
index 1c159d0..290b33d 100644
--- a/include/osmocom/core/logging.h
+++ b/include/osmocom/core/logging.h
@@ -198,6 +198,7 @@ void logp2(int subsys, unsigned int level, const char *file,
int line, int cont, const char *format, ...)
__attribute__ ((format (printf, 6, 7)));
int log_init(const struct log_info *inf, void *talloc_ctx);
+int log_check_level(int subsys, unsigned int level);
/* context management */
void log_reset_context(void);
diff --git a/src/logging.c b/src/logging.c
index 876964a..c7b1999 100644
--- a/src/logging.c
+++ b/src/logging.c
@@ -865,4 +865,43 @@ int log_init(const struct log_info *inf, void *ctx)
return 0;
}
+/*! \brief Check whether a log entry will be generated.
+ * \returns != 0 if a log entry might get generated by at least one target */
+int log_check_level(int subsys, unsigned int level)
+{
+ struct log_target *tar;
+
+ if (subsys < 0)
+ subsys = subsys_lib2index(subsys);
+
+ if (subsys > osmo_log_info->num_cat)
+ subsys = DLGLOBAL;
+
+ /* TODO: The following could/should be cached (update on config) */
+
+ llist_for_each_entry(tar, &osmo_log_target_list, entry) {
+ struct log_category *category;
+
+ category = &tar->categories[subsys];
+ /* subsystem is not supposed to be logged */
+ if (!category->enabled)
+ continue;
+
+ /* Check the global log level */
+ if (tar->loglevel != 0 && level < tar->loglevel)
+ continue;
+
+ /* Check the category log level */
+ if (tar->loglevel == 0 && category->loglevel != 0 &&
+ level < category->loglevel)
+ continue;
+
+ /* This might get logged (ignoring filters) */
+ return 1;
+ }
+
+ /* We are sure, that this will not be logged. */
+ return 0;
+}
+
/*! @} */
--
2.6.3
Hi,
here are some patches that I produced while compiling some osmocom
projects and its dependencies on a new box.
Most of them are trivialities that prevent compiler warnings.
The patch for openbsc though fixes a bug that prevents the build when
libgtp from openggsn is not present on the system.
Kind regards,
-Alex
Hi list,
during my gtphub development, I marked numerous commits as
Sponsored-by: On-Waves ehi
which is wrong. The ehi should have been ehf:
Sponsored-by: On-Waves ehf
It's in the history now, so unless we rebase kazillion of commits on
openbsc master, the ehi is gonna stick. So ... why didn't any reviewer
catch that a bit sooner? ;)
Opinions welcome.
And thanks, ☭, for spotting this, at last!
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
Hi,
I like code-review around mailinglists (mostly everybody can read and learn from
comments or code), it shows that people collaborate and that we move forward.
What I don't like about the current workflow is that we need to manually close things
in patchwork after applying/rejecting/ignoring a patch and that to see if it compiles and
works are done after the review and by the person that applies the changes.
In other projects I have used Gerrit and besides it being a Java monster found it
quite okay to use. One strength is that one can directly push the changes for a branch
for review, the other is that Jenkins and Gerrit can collaborate. This means that after
a commit is pushed make, make check, make distcheck can be executed. Comments
will always be attached to a line and not be lost due me quoting and removing parts
of the mail.
What I am not sure about:
* How do the email notifications look like? E.g. do we just get a "Somebody has
commented" mail or do we get diff + comment sent here? In OpenOCD I see there
is an email with the diff[1] but no mail with the comments.
* Shall we support direct pushes? I think specially in the beginning we should but
the branch name for that would change.
* A change that impacts libopenbsc+OpenBSC is difficult to represent. It would break
"the" build but I don't see any other way.
Is there enough consensus to give it a try?
holger
[1] http://sourceforge.net/p/openocd/mailman/message/34646766/
Good Morning,
Max has brought up the topic of somehow testing the debian packages and I wonder
what aspects we need to test it. Ideally we would test:
(a) Building a new version of everything against the last packages we have built to find
wrong minimum versions.
(b) Create source packages and build everything.
(c) Try to upgrade services and check something is respawned and the config file is
compatible.
(a) is a complicated mess. We do add new interfaces, versions to the development version
of libraries and we don't want to bump the SO_VERSION and such until we make a release.
So this item will always break.
(b) Is quite easy. When making a release we should open the changelog with version+1 and
not being released and then make nightly source packages and upload them to the OpenSUSE
build service and see how it fails.
(c) Is possible but a bit tricky again. We need to do this for each service (e.g. nitb and bsc
share the same VTY, OML, RSL port and are mutual exclusive).
Max is probably aiming for (b) and I think it is not that needed. I tend to make releases and build
packages and the breakage is quite small from release to release. I think there would be real
value in (c) but that requires some work that we will probably not have time for in Q1.
holger
