[ 
https://issues.apache.org/jira/browse/MYNEWT-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840833#comment-15840833
 ] 

ASF subversion and git services commented on MYNEWT-568:
--------------------------------------------------------

Commit e93908011066eab5cd9e6f2c2102fc36f049c58b in incubator-mynewt-core's 
branch refs/heads/develop from [~ccollins476]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-core.git;h=e939080 
]

MYNEWT-568 log - Increase index to uint32 (was:16)

For the most part, this change is backwards compatible. The new behavior
is:

    /* If   lo_ts == -1: Only access last log entry;
     * Elif lo_ts == 0:  Don't filter by timestamp;
     * Else:             Only access entries whose ts >= lo_ts.
     */
    int64_t lo_ts;

    /* Only access entries whose index >= lo_index. */
    uint32_t lo_index;

So, the timestamp is still used as the primary key if a nonzero value is
specified. If 0 is specified, only the index is used to filter entries.

There is one compatibility-breaking change: the "logs show" command
retrieves all entries whose index is greater than or equal to the
specified index value. Prior to this change, the command only retrieved
entries whose index is greater. This change was made so that there is a
reliable means of getting an entry with an index of 0.


> logs - Increase idx to 32 bits
> ------------------------------
>
>                 Key: MYNEWT-568
>                 URL: https://issues.apache.org/jira/browse/MYNEWT-568
>             Project: Mynewt
>          Issue Type: Improvement
>            Reporter: Christopher Collins
>            Assignee: Christopher Collins
>             Fix For: v1_0_0_beta2
>
>
> * Increase log entry's index field to 32 bits.
> * In newtmgr read log command, the index is the only criterion for selecting 
> the start point of the read (don't use timestamp anymore).
> * On startup, read the last entry from each flash log to determine the index 
> of the next entry.  This is to ensure the next entry written has the correct 
> sequence number.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to