AudioHAL and SoundtriggerHAL is separeted HAL but running in thread with
same process id.
So, if both HAL try to open netlink socket using uevent_open_socket(),
secondly opening socket receives already-in-use error.
To prevent situation, set 0 to socket port id.
By the LINUX man page, "The kernel assigns the process ID to the first
netlink socket the process opens and assigns a unique nl_pid to every
netlink socket that the process subsequently creates."
Bug:163008274
Test: tested by opening netlink socket in AudioHAL and
SoundtriggerHAL both.
Signed-off-by: Gyeongtaek Lee <gt82.lee@samsung.com>
Change-Id: I5f9859e8dac749bf5d0998e825043c9988c202ba
This way, the profilers will know they have to reparse maps.
Bug: 163130539
Test: Verified updated unit tests pass.
Change-Id: I88a801ffdda12811eab5e4833dcf472f2d75c09a
Previously, chatty had logic that would skip a certain number of log
entries to satify pruning, but otherwise keep the reader connected.
This was a best-effort attempt at helping pruning and had additional
logic that handled further disruptions, if logd's memory was 2x the
allotted memory.
The new logic has two components:
1) memcpy() each individual log message in FlushTo() such that there
are no references to the underlying log data without a lock held.
Note, that this memcpy is completely negligible for performance.
2) In Prune(), immediately delete all log chunks required to reduce
memory to the allotted amount, which is now safe given 1). If readers
will lose logs, continue to print a warning.
This additionally makes the Clear() logic deterministic. It was
previously best effort in chatty, but will immediately and always
clear all logs for SerializedLogBuffer.
Bug: 163617910
Test: logging unit tests
Test: Prune() immediately frees buffers during high log pressure
Test: Clear() immediately frees buffers during high log pressure
Change-Id: I40fe9b791312af3dc256b166e5c34425f4ca51ac
See the comment in the code for more details. 'wrapped' readers are
uncommon and error prone, and this change makes them more reliable.
Its side effect is that wrapped readers will wake more often, but
they'll still be batched to a large degree.
Bug: 163617910
Test: logging unit tests
Test: logcat --wrap does the right thing
Change-Id: I4b6f8331ff7854787c97f821b2a5bf8d7da321c6
With a couple recent changes to APIs taking a const std::string&,
instead of a const char *, we switch to directly passing in a
reference to our string.
Test: TreeHugger
Change-Id: Id9f832dd5e3def28cfeaa0d3cda7da323332b16c
This reverts commit 4af349b072.
Reason for revert: post submit test logs too much fails after this
Bug: 163611679
Change-Id: If9939f3c9864dad67536d0c5481f662b9d07c58e
This function has been marked deprecated for quite some time, has no
users, and isn't in liblog.map.txt.
Test: build
Change-Id: Ic3bf47c780b18a5d4f1e997b9265be76049fb824
Merging sparse chunk can make sparse map block bigger than 4GiB,
that can't be covered by unsigned integer type. Fix this by
changing unsigned int to uint64_t type.
Test: sparse build
Bug: 162808120
Change-Id: Id4d3f88f9d531c25c3937c99b2c81efb915605ee
Signed-off-by: Hyeongseok Kim <hyeongseok@gmail.com>
Cc: hyeongseok.kim <hyeongseok.kim@lge.com>
liblog uses a non-blocking socket for sending messages to logd as a
performance/reliability trade-off, favoring not blocking processes
when they log over reliably tracking all logs.
This change asserts that the above is the wrong trade-off: that log
relability is more important than slight delays when logging. Further
points to consider:
1) The new logd implementation without chatty has lower latency and
less variance in its ::Log() function.
2) liblog also writes to /dev/pmsg0 and this call is already blocking.
3) Logging is already expensive and excess spam must be eliminated
regardless.
Bug: 151654749
Bug: 155922578
Bug: 160314220
Test: No messages are dropped by this socket
Change-Id: I163b7d51aa73a10978850f1868cb9fc4bf9ead1b
Open README.compression.md in a markdown viewer for details.
Test: vscode and gitiles render this correctly
Change-Id: Iaa0093dc565b5c6bb016c9e97248375f0906d0c8
The name "pre_gki_level" is causing some confusion because not all
devices launching with Android R are subject to the GKI requirement.
(See b/161563110#comment11.) E.g., devices that use a 4.14-based kernel
are exempt from GKI. However, the encryption requirements still apply.
Just use __ANDROID_API_Q__ directly instead.
No change in behavior.
Change-Id: I4242745ccc9f88e084a1adfab5796daa9bc59b6e
