ccollins476ad commented on issue #1173: Awkward log API requires padded buffer
   Thanks for the correction, Marko.  That makes sense.
   I propose the following changes:
   1. Modify the log entry header such that the `ue_level` field is split into 
two fields: "level" and "flags" (one nibble each).
   2. Define a `LOG_ENTRY_HDR_F_PADDED` flag.
   3. If this new flag is set in an entry, it indicates that the log entry body 
begins on the next flash-aligned address, rather than immediately after the log 
   4. Change the semantics of the `log_append{,_typed,_mbuf}` functions such 
that the provided payload does not contain room for a header.  Instead, these 
function define the entry header on the stack, fill it, and write it separately.
   * The over-the-air format of log commands and responses would not change.
   * I chose to split the `ue_level` field because I think 16 levels is plenty. 
 I also don't think it makes too much sense to allow an application to define 
custom "per-user" levels, since levels are necessarily monotonically 
increasing.  I.e., all custom levels would be more severe than "critical".
   To maintain backwards compatibility, we would need to either:
   1. Create newly named append functions with the new semantics, or
   2. Introduce a new log version or new syscfg setting to enable the new 

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