system_core/logd/LogTimes.cpp, branch replicant-6.0

logd: filters remove leading expire messages and rate

2015-06-05T17:20:55+00:00

(cherry pick from commit 047cc0729fd837a03b99db901941c1421ef15f96)

- Cleanup resulting from experience and feedback
- When filtering inside logd, drop any leading expire messages, they
  are cluttering up leading edge of tombstones (which filter by pid)
- Increase and introduce EXPIRE_RATELIMIT from 1 to 10 seconds
- Increase EXPIRE_THRESHOLD from 4 to 10 count
- Improve the expire messages from:
   logd : uid=1000(system) too chatty comm=com.google.android.phone,
                                                   expire 2800 lines
  change tag to be more descriptive, and reduce accusatory tone to:
   chatty : uid=1000(system) com.google.android.phone expire 2800
                                                               lines
- if the UID name forms a prefix for comm name, then drop UID name

Change-Id: Ied7cc04c0ab3ae02167649a0b97378e44ef7b588

logd: Cleanup

2015-05-13T16:22:56+00:00

(cherry pick from commit 7718778793b106498b931dd708a466cf3a6f6a0f)

- Android Coding Standard for Constructors
- Side effects NONE

Change-Id: I2cda9dd73f3ac3ab58f394015cb810820093d47b

logd: replace internal CLOCK_MONOTONIC use with sequence numbers

2015-03-18T19:43:23+00:00

- switch to simpler and faster internal sequence number, drops
  a syscall overhead on 32-bit platforms.
- add ability to break-out of flushTo loop with filter return -1
  allowing in reduction in reader overhead.

Change-Id: Ic5cb2b9afa4d9470153971fc9197b07279e2b79d

logd: Fix pruning

2015-01-14T19:12:47+00:00

In a scenario in which an on-line (blocking) client is running and
a clean is attempted (logcat -c), the following can be observed:

1) the on-line logger seems to freeze
2) any other clear attempt will have no effect

What is actually happening:

In this case prune function will "instruct" the oldest timeEntry
to skip a huge number (very close to ULONG_MAX) of messages, this
being the cause of 1.

Since the consumer thread will skip all the log entries, mStart
updating will also be skipped. So a new cleaning attempt will have
the same oldest entry, nothing will be done.

Fix description:
a. keep a separated skipAhead count for individual log buffers (log_id_t)
      LogTimeEntry::LogTimeEntry
      LogTimeEntry::FilterSecondPass
      LogTimeEntry::skipAhead
      LogTimeEntry::riggerSkip_Locked

b. update LogTimeEntry::mStart even if the current message is skipped
      LogTimeEntry::FilterSecondPass

c. while pruning, only take into account the LogTimeEntrys that are monitoring
   the log_id in question, and provide a public method of checking this.
      LogTimeEntry::isWatching
      LogTimeEntry::FilterFirstPass
      LogTimeEntry::FilterSecondPass

d. Reset the skip cont befor the client thtread starts to sleep, at this point
   we should be up to date.
      LogTimeEntry::cleanSkip_Locked
      LogTimeEntry::threadStart

Change-Id: I1b369dc5b02476e633e52578266a644e37e188a5
Signed-off-by: TraianX Schiau

logd: persistent reader threads

2014-08-12T18:59:35+00:00

(cherry picked from commit c113c5813ebd620e0bc60ece9a32ea14c08ea237)

Bug: 16822776
Change-Id: I5bea468a41089b51108880044f32e2b2df1278e7

logd: logcat unexpected EOF on slow consoles

2014-06-06T15:08:37+00:00

Change-Id: I3520aa05e080de85df352ef36ae16e0406311f3c

logd: add thread setname

2014-04-29T00:37:37+00:00

- permits easier determination of logd thread at
  fault in a stack trace from debuggerd.

Bug: 14275676
Change-Id: Iac2c523147e2bcce34ab7ddcecd02582c5fa7cc0

logd: transitory reader thread create should be detached

2014-04-04T20:12:56+00:00

Bug: 13692914
Change-Id: Ia7306e6e844ae9f17c6f594bf6b25f3148652570

logd: liblog: logcat: Arbitrary time to tail

2014-03-14T17:23:51+00:00

Change-Id: I10e8d92c933e31ee11e78d2d1114261a30c4be0e

logd: Adjust to match defacto coding style

2014-02-26T17:54:23+00:00

(cherry picked from commit c46f77bd2ad01f3a695416c4cf22d6a9738bb7b8)

Change-Id: I80685cdc7116e10c5a5a77abe856fd96804f9117