Dear Andreas,
going through the patchset of jolly/testing in OpenBSC it would be nice
to get most of the things merged (having TCH/H support for something like
the 31C3 is a nice goal).
I wanted to start with merging the Connection Failure Criteria code but
I am confused about the conversion. When parsing the criteria value from
from the VTY you divide by four and subtract (so 4 becomes 0). You ondo
this when saving the config and patching it in the nanoBTS attribute
array.
Wouldn't it be more easy to not doing the conversion?
holger
Hi all,
time is moving fast, and I want to start some initial discussion and
planning for OsmoDevCon 2014.
There are basically four questions which I'm raising below. Please
provide your feedback to the osmocom-event-orga mailing list only, to
avoid cross-posting over all the project lists.
= Who? =
My intention is to keep it an 'active developer/contributer only' event,
like we had it before. I would also want to keep the group relatively
small, to keep the 'Osmocom family' atmosphere.
If desired, we could have one half or full day of public prsentations in
a larger auditorium, but the developer meeting should be a close group,
as known so far.
= Where? =
If we keep the number of attendees within the same range as this year,
then I'm sure we could again hold it at the same venue. I know it is
not perfect, but it is a place that we have access to, 24 hours per day,
and free of cost for community projects like osmocom.org.
If the community wants a larger event, then this is something that would
require more funds and much more time organizing. And that is something
that I personally could not offer to take care of, sorry. I'm happy to
attend and support any larger events, but I'm unable to take care of
fundraising and venue research.
= When? =
Q1/2014. In January, I'm not aware of any 'blocker' events. February,
there is Fosdem (Feb 1 + Feb 2), and MWC from Feb 24 through Feb 27. In
March there is CeBIT (March 10-14) and Easter holidays (with EasterHegg
March 17-21). Did I miss any other FOSS / mobile event that might clash
in Q1?
So my preference woudl be to do it either late January (23-26) or in
February (6-9 or 13-16). Any preferences regarding preferred schedule?
Once we have some concencus here on the list [and we want to do it in
the same size / venue], I'll talk to IN-Berlin.
= What? =
I think that question is easy to answer, if we have the above three
figured out... There's no shortage of topics, I suppose.
You can start adding your suggestions to
http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2014
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)
Good Morning,
during the 30C3 we had some "broken channels" because the BTS didn't
respond within four seconds to a Channel Activation/Deactivation. I
started to look at it with perf and "snprintf" appears to be called a
lot and did show up in the top.
snprintf is mostly called from within osmo_hexdump and gsm_lchan_name.
Both of these function calls are used in our logging calls throughout
the code.
Going forward I think we can do
* Remove some LOGP/DEBUG with osmo_hexdump (I did so for some call sites
in the osmo-bts)
* Start handlin -DNDEBUG inside logging.h and undefine/not define 'DEBUG'
in logging.h. But this would take away some code paths that would be
nice to look at.
* gsm_lchan_name could 'cache' the last lchan and then not call snprintf.
I did this once but it didn't appear to be much help. I will have
another look.
* Introduce a DEBUGQ, 'Q' for quick and check if the output would be
enabled and then log. This can be useful when the cost of checking
all targets twice is smaller than the cost of snprintf.
comments?
holger
diff --git a/include/osmocom/core/logging.h b/include/osmocom/core/logging.h
index 1d57e22..a8476d2 100644
--- a/include/osmocom/core/logging.h
+++ b/include/osmocom/core/logging.h
@@ -27,6 +27,10 @@
#define DEBUGPC(ss, fmt, args...)
#endif
+#define DEBUGQ(ss, fmt, args) \
+ if (log_would_log(ss, LOGL_DEBUG)) \
+ logp(ss, __FILE__, __LINE__, 0, fmt ## args);
+
void osmo_vlogp(int subsys, int level, const char *file, int line,
int cont, const char *format, va_list ap);
@@ -215,6 +219,9 @@ const char *log_vty_command_description(const struct log_info *info);
struct log_target *log_target_find(int type, const char *fname);
extern struct llist_head osmo_log_target_list;
+/* helper to check if it would log without using filter_fn */
+int log_would_log(int subsys, unsigned int level);
+
/*! @} */
#endif /* _OSMOCORE_LOGGING_H */
diff --git a/src/logging.c b/src/logging.c
index 2e3a80a..1e64ba5 100644
--- a/src/logging.c
+++ b/src/logging.c
@@ -268,6 +268,26 @@ err:
target->output(target, level, buf);
}
+
+static int cat_enabled(const struct log_target *tar,
+ const struct log_category *category, int level)
+{
+ /* subsystem is not supposed to be logged */
+ if (!category->enabled)
+ return 0;
+
+ /* Check the global log level */
+ if (tar->loglevel != 0 && level < tar->loglevel)
+ return 0;
+
+ /* Check the category log level */
+ if (tar->loglevel == 0 && category->loglevel != 0 &&
+ level < category->loglevel)
+ return 0;
+
+ return 1;
+}
+
/*! \brief vararg version of logging function */
void osmo_vlogp(int subsys, int level, const char *file, int line,
int cont, const char *format, va_list ap)
@@ -286,17 +306,8 @@ void osmo_vlogp(int subsys, int level, const char *file, int line,
va_list bp;
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)
+ if (!cat_enabled(tar, category, level))
continue;
/* Apply filters here... if that becomes messy we will
@@ -799,4 +810,19 @@ int log_init(const struct log_info *inf, void *ctx)
return 0;
}
+int log_would_log(int subsys, unsigned int level)
+{
+ struct log_target *tar;
+
+ llist_for_each_entry(tar, &osmo_log_target_list, entry) {
+ if (!cat_enabled(tar, &tar->categories[subsys], level))
+ continue;
+
+ if ((tar->filter_map & LOG_FILTER_ALL) != 0)
+ return 1;
+ }
+
+ return 0;
+}
+
/*! @} */
Dear all,
just a quick reminder:
On Sat, Nov 30, 2013 at 02:57:20PM +0100, Harald Welte wrote:
> Please make sure to add your name to the list at
> https://openbsc.osmocom.org/trac/wiki/OsmoDevCon2014 until December
> 31st (latest). If you don't have a wiki account, ask somebody who has
> one, apply for a wiki account or send an e-mail to me.
so today is the last chance to indicate your intrest in attending
OsmoDevCon.
I'm surprised to not have seen the following names in the list: pablo,
peter, nion, steve-m, dmitry, kaber. It would be great to have you
around again this year.
Looking forward to meeting all of you again!
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)
Has anyone experienced these cards (as can be found on eBay) failing
after a matter of months? I have some I programmed ~1 year ago and
which worked fine in a bunch of Calypso handsets with NITB, but now I
get "SIM card absent" whenever I try to make a call (but LUR is
accepted OK and can see programmed IMSI in NITB debug).
An operator SIM and an R&S test SIM is working fine with the setup.
Also tried reprogramming the SuperSIM card (command used below).
Regards,
Andrew
//
./pySim-prog.py -d /dev/ttyUSB0 -n OpenBSC -c 44 -x 001 -y 01 -i
001010000000053 -s 1234567890000000003 -k
DEADBEEF0C0FFEE0F00D013370D00F03
Insert card now (or CTRL-C to cancel)
Autodetected card type fakemagicsim
Generated card parameters :
> Name : OpenBSC
> SMSP : e1ffffffffffffffffffffffff058100445555ffffffffffff000000
> ICCID : 1234567890000000003
> MCC/MNC : 1/1
> IMSI : 001010000000053
> Ki : DEADBEEF0C0FFEE0F00D013370D00F03
> OPC : 56078bafca0ce95e81089288cbfb296e
Programming ...
Done !
--
Andrew Back
http://carrierdetect.com