This way i most usual rate_ctr related internal logging is disabled by default
(notice), and it can b eeasily enabled by switching the category to info
or debug.
Change-Id: Id6c36432da7e7ce673c585bcae6772a695028ec5
The log category DDEV ueses LOGL_INFO as debug level. This is too
verbose, lets use LOGL_NOTICE instead
Change-Id: I56d45ce5c3f55574491ffa6e4d902d6ba7499d46
Related: OS#2577
Using %lu for pthread_t was wrong on armv7l arch. Even worse, according
to pthread_self() man page, pthread_t cannot be assumed to be of a simple
type and hence printable:
"""
POSIX.1 allows an implementation wide freedom in choosing the type used
to represent a thread ID; for example, representation using either an
arithmetic type or a structure is permitted.
"""
Let's use gettid() instead. According to glibc documentation:
"""
The pid_t data type is a signed integer type which is capable of
representing a process ID. In the GNU C Library, this is an int.
"""
It may not be the same on other libc's though, so let's better cast to a
long int just in case.
Accordign to gettid() man, the libc function was only added recently
during glibc 2.30, however the system call has been around for quite
some time (linux 2.4.11). Let's accomodate use udner non-glibc or older
versions of it by having a direct syscall fallback.
Change-Id: I40265fd4c62e550014ba3ff3335ca053c5bc01f2
Make sure old configs using "logging level lms <level>" are still accepted.
Initialization order of VTY componenets need to be resorted since newly
introduced command requires logging VTY node to be already setup
beforehand.
Change-Id: Ia195a74a62a8a3dd6267fb1359acaa5628208d8e
Take the chance to clean up logging lines in this file:
* Use LOGCHAN in more places where chan is useful
* Replace inherited (old osmo-trx) categories such as WARNING with
osmocom ones.
Change-Id: Ic8c218f050f35d48046ccf1561fb0bfc505d4f63
Since libosmocore Id7711893b34263baacac6caf4d489467053131bb, a new API
log_enable_multithread() is available which takes care of protecting
logging infrastructure from us (and actually does it correctly since we
cannot protect internal libosmocore structures from osmo-trx).
Let's drop all mutex related code from osmo-trx logging infra and simply
rely on libosmocore's.
Related: OS#4088
Change-Id: I519d0f30bce871005ca26b90177ea4aa4839360a
This log category is applied to messages related to TRX CTRL socket
interface, and it's printed in yellow, same color used in osmo-bts-trx
for TRX category (so same messages are printed with same color in both
sides).
Change-Id: I98ec5e416272783ad3fbadf70478a4e48ae64983
The DMAIN category got too overloaded. Let's have the code in
Transceive52M/device/* use the new DDEV category.
Also, in some cases the log levels have been adjusted to ensure
that enabling INFO level should not result in a complete overflow
of messages during normal operation.
Change-Id: I844fe4a75bf277cd3cc5bd8fa06e06ad97b2ea95
Up to this point, the logging system, vty and ctrl are initialized and
can be used fine, though they don't have a lot of use yet.
Depends on libosmocore Change-Id Ib79cdb62d45d8c78445c7b064e58eb7e9faeccf9
Related: OS#2184
Change-Id: I08982c37b4f873966304b3cfb38a10ee86eb3dad