ccollins476ad commented on issue #1173: Awkward log API requires padded buffer
   Looking into this a bit more, I discovered a few things:
   1. The `log_append_mbuf` and `log_append_mbuf_typed` functions assume a 
flash write size of 1.  So these won't work on some hardware.
   2. A lot of our system relies on the fact that the header and body are 
adjacent in a log entry.  So my idea of inserting padding as needed after the 
entry header would cause quite a headache.
   Re: 2- Specifically, the `log_read()` function fills a buffer with data from 
the log, starting with the log entry header.  The caller then skips past the 
header in the buffer to access the message body.  This is problematic if there 
might be padding after the header.  This issue also affects log walks; a 
typical walk callback reads the current entry using `log_read()`.
   We could add a "header-size" callback to `struct log_handler`.  Using this, 
the caller could know where the log body begins.
   Alternatively, the `log_read()` function could return two pieces of data:
   1. The entry header (`struct log_entry_hdr`)
   2. Part of the message body (length equal to number of bytes requested)
   So, the caller would specify the number of body bytes to read, and would 
always get back the full header and the specified number of body bytes.

This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

With regards,
Apache Git Services

Reply via email to