Wyatt Hepler | 0d4c916 | 2021-05-26 09:27:22 -0700 | [diff] [blame] | 1 | .. _module-pw_log-protobuf: |
| 2 | |
| 3 | ------------------- |
| 4 | The pw_log protobuf |
| 5 | ------------------- |
| 6 | ``pw_log`` defines a protocol buffer for storing and transmitting log messages. |
| 7 | The protobuf is optimized to be maximally efficient. |
| 8 | |
| 9 | Fields |
| 10 | ====== |
| 11 | The ``pw_log`` protobuf is defined in ``log.proto``. |
| 12 | |
| 13 | .. literalinclude:: log.proto |
| 14 | :language: protobuf |
| 15 | :lines: 14- |
| 16 | |
| 17 | Timestamps |
| 18 | ---------- |
| 19 | Timestamps are specified in implementation-defined ticks. Ticks could be |
| 20 | milliseconds, microsends, or any arbitrary duration derived from the device’s |
| 21 | clock. |
| 22 | |
| 23 | For many applications, the timestamp field can be interpreted based on the prior |
| 24 | knowledge of the system. For example, ``timestamp`` might be known to be |
| 25 | milliseconds since boot for one core or microseconds since boot for another. |
| 26 | |
| 27 | If desired, a project could collect information about clock parameters |
| 28 | separately from ``pw_log``, and use that to interpret log timestamps. For |
| 29 | example, they may call an RPC that returns a ``pw_chrono`` ``ClockParamters`` |
| 30 | protobuf. The values from that could be used to interpret timestamp from that |
| 31 | device. |
| 32 | |
| 33 | The ``pw_log`` proto contains two timestamp fields, only one of which may be set |
| 34 | at a time: |
| 35 | |
| 36 | - ``timestamp`` – Absolute time when message was logged. |
| 37 | - ``time_since_last_entry`` – When the message was logged, relative |
| 38 | to the previously encoded log message. This is used when multiple log entries |
| 39 | are sent in a single ``LogEntries`` proto. The previous log entry must use the |
| 40 | same time source. If logs with multiple time sources are intermingled in a |
| 41 | single ``LogEntries`` proto, they must use an absolute timestamp each time the |
| 42 | time source changes. |
| 43 | |
| 44 | Optionally tokenized text fields |
| 45 | -------------------------------- |
| 46 | Several fields in the ``pw_log`` proto store text. Examples include ``message`` |
| 47 | and ``thread_name``. These fields may contain either plain or tokenized text, |
| 48 | either of which is represented as a single bytes field. These fields are marked |
| 49 | with a protocol buffer option so the ``pw_tokenizer.proto`` module can detect |
| 50 | and detokenize tokenized fields as appropriate. |
| 51 | |
| 52 | See :ref:`module-pw_tokenizer-proto` for details. |
Prashanth Swaminathan | 8015cec | 2021-06-04 10:00:40 -0700 | [diff] [blame] | 53 | |
| 54 | Utility functions |
| 55 | ----------------- |
| 56 | Conversion into the ``log.proto`` format from a tokenized log message can be |
| 57 | performed using the ``pw_log/proto_utils.h`` headers. Given tokenized data and |
| 58 | a payload, the headers provide a quick way to encode to the LogEntry protobuf. |
| 59 | |
| 60 | .. code-block:: cpp |
| 61 | |
| 62 | #include "pw_log/proto_utils.h" |
| 63 | |
| 64 | extern "C" void pw_tokenizer_HandleEncodedMessageWithPayload( |
| 65 | pw_tokenizer_Payload payload, const uint8_t data[], size_t size) { |
| 66 | pw::log_tokenized::Metadata metadata(payload); |
| 67 | std::byte log_buffer[kLogBufferSize]; |
| 68 | |
| 69 | Result<ConstByteSpan> result = EncodeTokenizedLog( |
| 70 | metadata, |
| 71 | std::as_bytes(std::span(data, size)), |
| 72 | log_buffer); |
| 73 | if (result.ok()) { |
| 74 | // This makes use of the encoded log proto and is custom per-product. |
| 75 | // It should be implemented by the caller and is not in Pigweed. |
| 76 | EmitProtoLogEntry(result.value()); |
| 77 | } |
| 78 | } |
| 79 | |