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;
+}
+
/*! @} */
