__BEGIN_DECLS and __END_DECLS are all that are left, and I can compile
with using normal <sys/cdefs.h>, so hopefully we can remove this at
last.
Test: build
Change-Id: I6df7ef0da027bb91c98806e0f9661d7416ebaa5d
This is simplified down to the point there are only two branches that
need to be made, so remove the rest of the transport structs and
simply branch where needed.
Test: liblog-unit-tests
Change-Id: Ic82e7e70eb7b4e40b381a4d8066629c5b7d4f827
There are a set of functions, such as android_logger_get_log_size()
and android_logger_get_prune_list() that talk to the logd command
socket to perform their activities. There's a transport abstraction
layer that handles these symbols to optionally route them to other
transports, originally designed for pstore or local logger; however
these functions fundamentally only make sense for logd.
Ideally, these functions would be removed and new functions would be
added that do not depend on struct logger_list or struct logger and
more clearly indicate that they only work with logd. For example:
android_logger_get_size(struct logger*) could be
logd_get_buffer_size(log_id_t log_id). We would remove the need to
'open' the struct logger and make it clear that it only operates on
logd.
Since liblog is an llndk library however, we cannot change or remove
these symbols. Since these symbols are not frequently used, it seems
acceptable to keep them as is and not introduce improved versions.
We, however, do want to simplify the code that handles them and this
change removes the transport abstraction layer that handles them.
They retain the behavior that unless the struct logger_list was opened
for logd, that the functions return -EINVAL.
The one exception to this is android_logger_clear(). If the struct
logger provided to this function was opened from a struct logger_list
that used pstore for its mode argument, this function will clear the
entire pstore log. This function does not respect the 'logId'
parameter of the struct logger, since that would not be possible.
This change removes this android_logger_clear() behavior and makes it
strictly for logd, for symmetry with the rest of the functions and due
to the lack of clarity regarding the 'logId' parameter of its input.
The only caller of this function, logcat, will clear pstore directly.
struct logger was built to encapsulate the information needed to
connect to a logger device from the old kernel logger. Now that we
only support reading from pstore and from logd, there is much less
information needed to be captured. Specifically, we only need to know
the log_id and whether or not it was opened as part of a pstore or
logd 'list'.
Test: liblog-unit-test
Test: logcat -c/-g/-G/-p/-P/-S work
Test: logcat -c works with -L
Test: logcat -g/-G/-p/-P/-S continue to fail with -L
Change-Id: I2c549b6f8539de94510e223949ab209ecc40e2d0
android_lookupEventTagNum added. Adds support for creating a new
log tag at runtime, registered to the logd service.
Tested on Hikey, all services stopped, shell only access, CPUs not
locked (there is enough repeatability on this platform).
$ /data/nativetest64/liblog-benchmarks/liblog-benchmarks BM_lookupEventTagNum
iterations ns/op
Precharge: start
Precharge: stop 231
NB: only Tag matching, linear lookup (as reference, before unordered_map)
BM_lookupEventTagNum 1000000 1017
NB: unordered_map with full Tag & Format lookup, but with Tag hashing
BM_lookupEventTagNum 2000000 683
NB: with full Tag & Format hash and lookup for matching
BM_lookupEventTagNum 2000000 814
NB: only Tag matching (Hail Mary path)
BM_lookupEventTagNum 5000000 471
Because the database can now be dynamic, we added reader/writer locks
which adds a 65ns (uncontended) premium on lookups, and switch to
check for an allocation adds 25ns (either open code, or using
string_view, no difference) which means our overall speed takes 90%
as long as the requests did before we switched to unordered_map.
Faster than before where we originally utilized binary lookup on
static content, but not by much. Dynamic updates that are not cached
locally take the following times to acquire long path to logd to
generate.
BM_lookupEventTag 20000000 139
BM_lookupEventTag_NOT 20000000 87
BM_lookupEventFormat 20000000 139
BM_lookupEventTagNum_logd_new 5000 335936
BM_lookupEventTagNum_logd_existing 10000 249226
The long path pickups are mitigated by the built-in caching, and
the public mapping in /dev/event-log-tags.
SideEffects: Event tags and signal handlers do not mix
Test: liblog benchmarks
Bug: 31456426
Change-Id: I69e6489d899cf35cdccffcee0d8d7cad469ada0a
