vrahane commented on code in PR #3400:
URL: https://github.com/apache/mynewt-core/pull/3400#discussion_r2076437891
##########
sys/log/full/src/log_cbmem.c:
##########
@@ -40,21 +51,61 @@ log_cbmem_append_body(struct log *log, const struct
log_entry_hdr *hdr,
.flat_buf = body,
.flat_len = body_len,
},
+#if MYNEWT_VAL(LOG_FLAGS_TRAILER_SUPPORT)
+ {
+ .flat_buf = trailer,
+ .flat_len = 0
+ },
+ {
+ .flat_buf = NULL,
+ .flat_len = 0,
+ },
},
- .count = 3,
+ .count = 5,
+#else
+ {
+ .flat_buf = NULL,
+ .flat_len = 0,
+ },
+ },
+ .count = 4,
+#endif
};
+#if MYNEWT_VAL(LOG_FLAGS_TRAILER_SUPPORT)
+ if (hdr->ue_flags & LOG_FLAGS_IMG_HASH) {
+ sg->entries[1].flat_len = LOG_IMG_HASHLEN;
+ }
+
+ if (hdr->ue_flags & LOG_FLAGS_TRAILER_SUPPORT) {
+ rc = log_trailer_append(log, trailer, &trailer_len, NULL, NULL);
Review Comment:
I see what you mean but the way cbmem is used we actually use the scatter
gather implementation to add optional data. For example: the image hash is also
added as one entry to the scatter gather array. So, that's what I did for the
trailer as well. There is no flat buffer implementation for logging to cbmem,
so, we do not really need to implement it that way. Unless you feel otherwise,
I would like to keep it this way for the sake of simplicity and consistency.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@mynewt.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
