most importantly, we do no longer use the LOG_FAC() and LOG_PRI() macro
names, which may conflict with systems names and may act other than
expected by a user.
... actually, they are microseconds. So the fractional part of the
timestamp was not properly formatted.
Thanks to Marius Tomaschwesky for the bug report and the patch idea.
When enabled, kernel message [timestamp] is converted for message time.
Default is to use receive time as in 5.8.x and before, because the clock
used to create the timestamp is not supposed to be as accurate as the
monotonic clock (depends on hardware and kernel) resulting in differences
between kernel and system messages which occurred at same time.
The Linux driver no longer supports outdated kernel symbol resolution,
which was disabled by default for very long. Also overall cleanup,
resulting in much smaller code. Linux and BSD are now covered by a
single small driver.
If the kernel time-stamps messages, time is now take from that
timestamp instead of the system time when the message was read. This
provides much better accuracy. Thanks to Lennart Poettering for
suggesting this feature and his help during implementation.
if systemd writes a kernel log entry with a non-kernel priority,
the priority recorded in the kernel log will be wrong. However,
it will be immediately followed by another priority (with the
kernel timestamp in between, if enabled). So imklog now tries
to see if there is a second PRI and, if so, uses it. Note that
we already support non-kernel PRIs in the kernel log, as this
was done in BSD for quite some while. HOWEVER the config
statement "$klogpermitnonkernelfacility on" must be used to
permit this (otherwise non kernel messages are dropped).
Sample of a such a message on a kernel without timestamping
enabled:
$ echo '<14>text' > /dev/kmsg
$ dmesg -r
<4><14>text
NOTE: support for timestamp is NOT YET ENABLED!
The capability has been added for module to specify that they do not
like being unloaded.
related bug tracker: http://bugzilla.adiscon.com/show_bug.cgi?id=222
Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
support for enhancing probability of memory addressing failure by
using non-NULL default value for malloced memory (optional, only if
requested by configure option). This helps to track down some
otherwise undetected issues within the testbench and is expected
to be very useful in the future.
... hopefully reducing the number of allocs/frees as well as overall
memory usage in a busy system (plus that these shared properties hopefully
remain in cache longer than its single-instance counterparts...)
This sets stage to enable use of the property-interface to speed
up things (mildly), the next step to be done. I have also fixed one
regression of yesterday's changes.
... plus a fix for a long-time bug in obj-types.h. That lead to
the object pointer only then to become NULL when the object was
actually destructed, I discovered this issue during
introduction of the pRcvFrom property in msg_t, but it potentially had other
effects, too. I am not sure if some experienced instability resulted from this
bug OR if its fix will cause harm to so-far "correctly" running code. The later
may very well be. Thus I will change it only for the current branch and also
the beta, but not in all old builds. Let's see how things evolve.
some things inside the message can be used over a large number of
messages and need to to be allocated and re-written every time. I now
begin to implement this as a "prop_t" object, first use for the inputName.
Some input modules are already converted, some others to go. Will do
a little performance check on the new method before I go further.
Also, this commit has some cleanup and a few bug fixes that prevented
compiliation in debug mode (I overlooked this as I did not compile
for debug, what I normally do, and the automatted test also does not
do that)
