From 5c4ee2109de6aab794696c693ecb12e9791ea2d9 Mon Sep 17 00:00:00 2001 From: Juerg Rast Date: Wed, 7 Mar 2018 21:52:43 +0100 Subject: [PATCH 1/2] Added a note about the callback functions Added a short section about the callback functions, based on the answers to issue #35 and #36 --- README.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/README.md b/README.md index 9c06a26..a3b13b0 100644 --- a/README.md +++ b/README.md @@ -120,6 +120,18 @@ really do anything to ensure that the data written to disk is machine portable. This is fine as long as all of the involved machines share endianness (little-endian) and don't have strange padding requirements. +In the configuration struct, the `prog` and `erase` function provided by the +user may return a `LFS_ERR_CORRUPT` error if the implementation already can +detect corrupt blocks. However, the wear leveling does not depend on the return +code of these functions, instead all data is read back and checked for +integrity. + +If your storage caches writes, make sure that the provided `sync` function +flushes all the data to memory and ensures that the next read fetches the data +from memory, otherwise data integrity can not be guaranteed. If the `write` +function does not perform caching, and therefore each `read` or `write` call +hits the memory, the `sync` function can simply return 0. + ## Reference material [DESIGN.md](DESIGN.md) - DESIGN.md contains a fully detailed dive into how From f72f6d6a051ea048ded3bcd6ec638a13cfe40b02 Mon Sep 17 00:00:00 2001 From: Christopher Haster Date: Mon, 12 Mar 2018 21:27:05 -0500 Subject: [PATCH 2/2] Removed out of date note about endianness --- README.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/README.md b/README.md index a3b13b0..e778a65 100644 --- a/README.md +++ b/README.md @@ -115,11 +115,6 @@ All littlefs have the potential to return a negative error code. The errors can be either one of those found in the `enum lfs_error` in [lfs.h](lfs.h), or an error returned by the user's block device operations. -It should also be noted that the current implementation of littlefs doesn't -really do anything to ensure that the data written to disk is machine portable. -This is fine as long as all of the involved machines share endianness -(little-endian) and don't have strange padding requirements. - In the configuration struct, the `prog` and `erase` function provided by the user may return a `LFS_ERR_CORRUPT` error if the implementation already can detect corrupt blocks. However, the wear leveling does not depend on the return