More trailing whilespace removal

3 files changed, 184 insertions, 184 deletions

diff --git a/nuttx/fs/nxffs/Kconfig b/nuttx/fs/nxffs/Kconfig
index b666bb1c7..6cc45906a 100644
--- a/nuttx/fs/nxffs/Kconfig
+++ b/nuttx/fs/nxffs/Kconfig
@@ -83,7 +83,7 @@ config NXFFS_ERASEDSTATE
 	hex "FLASH erased state"
 	default 0xff
 	---help---
-		The erased state of FLASH. 
+		The erased state of FLASH.
 		This must have one of the values of 0xff or 0x00.
 		Default: 0xff.
 
diff --git a/nuttx/fs/nxffs/README.txt b/nuttx/fs/nxffs/README.txt
index a10fb97a5..af631a94b 100644
--- a/nuttx/fs/nxffs/README.txt
+++ b/nuttx/fs/nxffs/README.txt
@@ -1,180 +1,180 @@
-NXFFS README

-^^^^^^^^^^^^

-

-This README file contains information about the implemenation of the NuttX

-wear-leveling FLASH file system, NXFFS.

-

-Contents:

-

-  General NXFFS organization

-  General operation

-  Headers

-  NXFFS Limitations

-  Multiple Writers

-  ioctls

-  Things to Do

-

-General NXFFS organization

-==========================

-

-The following example assumes 4 logical blocks per FLASH erase block.  The

-actual relationship is determined by the FLASH geometry reported by the MTD

-driver.

-

-ERASE LOGICAL                   Inodes begin with a inode header.  inode may

-BLOCK BLOCK       CONTENTS      be marked as "deleted," pending re-packing.

-  n   4*n     --+--------------+

-                |BBBBBBBBBBBBBB| Logic block header

-                |IIIIIIIIIIIIII| Inodes begin with a inode header

-                |DDDDDDDDDDDDDD| Data block containing inode data block

-                | (Inode Data) |

-      4*n+1   --+--------------+

-                |BBBBBBBBBBBBBB| Logic block header

-                |DDDDDDDDDDDDDD| Inodes may consist of multiple data blocks

-                | (Inode Data) |

-                |IIIIIIIIIIIIII| Next inode header

-                |              | Possibly a few unused bytes at the end of a block

-      4*n+2   --+--------------+

-                |BBBBBBBBBBBBBB| Logic block header

-                |DDDDDDDDDDDDDD|

-                | (Inode Data) |

-      4*n+3   --+--------------+

-                |BBBBBBBBBBBBBB| Logic block header

-                |IIIIIIIIIIIIII| Next inode header

-                |DDDDDDDDDDDDDD|

-                | (Inode Data) |

- n+1  4*(n+1) --+--------------+

-                |BBBBBBBBBBBBBB| Logic block header

-                |              | All FLASH is unused after the end of the final

-                |              | inode.

-              --+--------------+

-

-General operation

-=================

-

-  Inodes are written starting at the beginning of FLASH.  As inodes are

-  deleted, they are marked as deleted but not removed.  As new inodes are

-  written, allocations  proceed to toward the end of the FLASH -- thus,

-  supporting wear leveling by using all FLASH blocks equally.

-

-  When the FLASH becomes full (no more space at the end of the FLASH), a

-  re-packing operation must be performed:  All inodes marked deleted are

-  finally removed and the remaining inodes are packed at the beginning of

-  the FLASH.  Allocations then continue at the freed FLASH memory at the

-  end of the FLASH.

-

-Headers

-=======

-  BLOCK HEADER:

-    The block header is used to determine if the block has every been

-    formatted and also indicates bad blocks which should never be used.

-

-  INODE HEADER:

-    Each inode begins with an inode header that contains, among other things,

-    the name of the inode, the offset to the first data block, and the

-    length of the inode data.

-

-    At present, the only kind of inode support is a file.  So for now, the

-    term file and inode are interchangeable.

-

-  INODE DATA HEADER:

-    Inode data is enclosed in a data header.  For a given inode, there

-    is at most one inode data block per logical block.  If the inode data

-    spans more than one logical block, then the inode data may be enclosed

-    in multiple data blocks, one per logical block.

-

-NXFFS Limitations

-=================

-

-This implementation is very simple as, as a result, has several limitations

-that you should be aware before opting to use NXFFS:

-

-1. Since the files are contiguous in FLASH and since allocations always

-   proceed toward the end of the FLASH, there can only be one file opened

-   for writing at a time.  Multiple files may be opened for reading.

-

-2. Files may not be increased in size after they have been closed.  The

-   O_APPEND open flag is not supported.

-

-3. Files are always written sequential.  Seeking within a file opened for

-   writing will not work.

-

-4. There are no directories, however, '/' may be used within a file name

-   string providing some illusion of directories.

-

-5. Files may be opened for reading or for writing, but not both: The O_RDWR

-   open flag is not supported.

-

-6. The re-packing process occurs only during a write when the free FLASH

-   memory at the end of the FLASH is exhausted.  Thus, occasionally, file

-   writing may take a long time.

-

-7. Another limitation is that there can be only a single NXFFS volume

-   mounted at any time.  This has to do with the fact that we bind to

-   an MTD driver (instead of a block driver) and bypass all of the normal

-   mount operations.

-

-Multiple Writers

-================

-

-As mentioned in the limitations above, there can be only one file opened

-for writing at a time.  If one thread has a file opened for writing and

-another thread attempts to open a file for writing, then that second

-thread will be blocked and will have to wait for the first thread to

-close the file.

-

-Such behavior may or may not be a problem for your application, depending

-(1) how long the first thread keeps the file open for writing and (2) how

-critical the behavior of the second thread is.  Note that writing to FLASH

-can always trigger a major FLASH reorganization and, hence, there is no

-way to guarantee the first condition: The first thread may have the file

-open for a long time even if it only intends to write a small amount.

-

-Also note that a deadlock condition would occur if the SAME thread

-attempted to open two files for writing.  The thread would would be

-blocked waiting for itself to close the first file.

-

-ioctls

-======

-

-The file system supports to ioctls:

-

-FIOC_REFORMAT:  Will force the flash to be erased and a fresh, empty

-  NXFFS file system to be written on it.

-FIOC_OPTIMIZE:  Will force immediate repacking of the file system.  This

-  will increase the amount of wear on the FLASH if you use this!

-

-Things to Do

-============

-

-- The statfs() implementation is minimal.  It whould have some calcuation

-  of the f_bfree, f_bavail, f_files, f_ffree return values.

-- There are too many allocs and frees.  More structures may need to be

-  pre-allocated.

-- The file name is always extracted and held in allocated, variable-length

-  memory.  The file name is not used during reading and eliminating the

-  file name in the entry structure would improve performance.

-- There is a big inefficiency in reading.  On each read, the logic searches

-  for the read position from the beginning of the file each time.  This

-  may be necessary whenever an lseek() is done, but not in general.  Read

-  performance could be improved by keeping FLASH offset and read positional

-  information in the read open file structure.

-- Fault tolerance must be improved.  We need to be absolutely certain that

-  any FLASH errors do not cause the file system to behavior incorrectly.

-- Wear leveling might be improved (?).  Files are re-packed at the front

-  of FLASH as part of the clean-up operation.  However, that means the files

-  that are not modified often become fixed in place at the beginning of

-  FLASH.  This reduces the size of the pool moving files at the end of the

-  FLASH.  As the file system becomes more filled with fixed files at the

-  front of the device, the level of wear on the blocks at the end of the

-  FLASH increases.

-- When the time comes to reorganization the FLASH, the system may be

-  inavailable for a long time.  That is a bad behavior.  What is needed,

-  I think, is a garbage collection task that runs periodically so that

-  when the big reorganizaiton event occurs, most of the work is already

-  done.  That garbarge collection should search for valid blocks that no

-  longer contain valid data.  It should pre-erase them, put them in

-  a good but empty state... all ready for file system re-organization.

- 

-

-

+NXFFS README
+^^^^^^^^^^^^
+
+This README file contains information about the implemenation of the NuttX
+wear-leveling FLASH file system, NXFFS.
+
+Contents:
+
+  General NXFFS organization
+  General operation
+  Headers
+  NXFFS Limitations
+  Multiple Writers
+  ioctls
+  Things to Do
+
+General NXFFS organization
+==========================
+
+The following example assumes 4 logical blocks per FLASH erase block.  The
+actual relationship is determined by the FLASH geometry reported by the MTD
+driver.
+
+ERASE LOGICAL                   Inodes begin with a inode header.  inode may
+BLOCK BLOCK       CONTENTS      be marked as "deleted," pending re-packing.
+  n   4*n     --+--------------+
+                |BBBBBBBBBBBBBB| Logic block header
+                |IIIIIIIIIIIIII| Inodes begin with a inode header
+                |DDDDDDDDDDDDDD| Data block containing inode data block
+                | (Inode Data) |
+      4*n+1   --+--------------+
+                |BBBBBBBBBBBBBB| Logic block header
+                |DDDDDDDDDDDDDD| Inodes may consist of multiple data blocks
+                | (Inode Data) |
+                |IIIIIIIIIIIIII| Next inode header
+                |              | Possibly a few unused bytes at the end of a block
+      4*n+2   --+--------------+
+                |BBBBBBBBBBBBBB| Logic block header
+                |DDDDDDDDDDDDDD|
+                | (Inode Data) |
+      4*n+3   --+--------------+
+                |BBBBBBBBBBBBBB| Logic block header
+                |IIIIIIIIIIIIII| Next inode header
+                |DDDDDDDDDDDDDD|
+                | (Inode Data) |
+ n+1  4*(n+1) --+--------------+
+                |BBBBBBBBBBBBBB| Logic block header
+                |              | All FLASH is unused after the end of the final
+                |              | inode.
+              --+--------------+
+
+General operation
+=================
+
+  Inodes are written starting at the beginning of FLASH.  As inodes are
+  deleted, they are marked as deleted but not removed.  As new inodes are
+  written, allocations  proceed to toward the end of the FLASH -- thus,
+  supporting wear leveling by using all FLASH blocks equally.
+
+  When the FLASH becomes full (no more space at the end of the FLASH), a
+  re-packing operation must be performed:  All inodes marked deleted are
+  finally removed and the remaining inodes are packed at the beginning of
+  the FLASH.  Allocations then continue at the freed FLASH memory at the
+  end of the FLASH.
+
+Headers
+=======
+  BLOCK HEADER:
+    The block header is used to determine if the block has every been
+    formatted and also indicates bad blocks which should never be used.
+
+  INODE HEADER:
+    Each inode begins with an inode header that contains, among other things,
+    the name of the inode, the offset to the first data block, and the
+    length of the inode data.
+
+    At present, the only kind of inode support is a file.  So for now, the
+    term file and inode are interchangeable.
+
+  INODE DATA HEADER:
+    Inode data is enclosed in a data header.  For a given inode, there
+    is at most one inode data block per logical block.  If the inode data
+    spans more than one logical block, then the inode data may be enclosed
+    in multiple data blocks, one per logical block.
+
+NXFFS Limitations
+=================
+
+This implementation is very simple as, as a result, has several limitations
+that you should be aware before opting to use NXFFS:
+
+1. Since the files are contiguous in FLASH and since allocations always
+   proceed toward the end of the FLASH, there can only be one file opened
+   for writing at a time.  Multiple files may be opened for reading.
+
+2. Files may not be increased in size after they have been closed.  The
+   O_APPEND open flag is not supported.
+
+3. Files are always written sequential.  Seeking within a file opened for
+   writing will not work.
+
+4. There are no directories, however, '/' may be used within a file name
+   string providing some illusion of directories.
+
+5. Files may be opened for reading or for writing, but not both: The O_RDWR
+   open flag is not supported.
+
+6. The re-packing process occurs only during a write when the free FLASH
+   memory at the end of the FLASH is exhausted.  Thus, occasionally, file
+   writing may take a long time.
+
+7. Another limitation is that there can be only a single NXFFS volume
+   mounted at any time.  This has to do with the fact that we bind to
+   an MTD driver (instead of a block driver) and bypass all of the normal
+   mount operations.
+
+Multiple Writers
+================
+
+As mentioned in the limitations above, there can be only one file opened
+for writing at a time.  If one thread has a file opened for writing and
+another thread attempts to open a file for writing, then that second
+thread will be blocked and will have to wait for the first thread to
+close the file.
+
+Such behavior may or may not be a problem for your application, depending
+(1) how long the first thread keeps the file open for writing and (2) how
+critical the behavior of the second thread is.  Note that writing to FLASH
+can always trigger a major FLASH reorganization and, hence, there is no
+way to guarantee the first condition: The first thread may have the file
+open for a long time even if it only intends to write a small amount.
+
+Also note that a deadlock condition would occur if the SAME thread
+attempted to open two files for writing.  The thread would would be
+blocked waiting for itself to close the first file.
+
+ioctls
+======
+
+The file system supports to ioctls:
+
+FIOC_REFORMAT:  Will force the flash to be erased and a fresh, empty
+  NXFFS file system to be written on it.
+FIOC_OPTIMIZE:  Will force immediate repacking of the file system.  This
+  will increase the amount of wear on the FLASH if you use this!
+
+Things to Do
+============
+
+- The statfs() implementation is minimal.  It whould have some calcuation
+  of the f_bfree, f_bavail, f_files, f_ffree return values.
+- There are too many allocs and frees.  More structures may need to be
+  pre-allocated.
+- The file name is always extracted and held in allocated, variable-length
+  memory.  The file name is not used during reading and eliminating the
+  file name in the entry structure would improve performance.
+- There is a big inefficiency in reading.  On each read, the logic searches
+  for the read position from the beginning of the file each time.  This
+  may be necessary whenever an lseek() is done, but not in general.  Read
+  performance could be improved by keeping FLASH offset and read positional
+  information in the read open file structure.
+- Fault tolerance must be improved.  We need to be absolutely certain that
+  any FLASH errors do not cause the file system to behavior incorrectly.
+- Wear leveling might be improved (?).  Files are re-packed at the front
+  of FLASH as part of the clean-up operation.  However, that means the files
+  that are not modified often become fixed in place at the beginning of
+  FLASH.  This reduces the size of the pool moving files at the end of the
+  FLASH.  As the file system becomes more filled with fixed files at the
+  front of the device, the level of wear on the blocks at the end of the
+  FLASH increases.
+- When the time comes to reorganization the FLASH, the system may be
+  inavailable for a long time.  That is a bad behavior.  What is needed,
+  I think, is a garbage collection task that runs periodically so that
+  when the big reorganizaiton event occurs, most of the work is already
+  done.  That garbarge collection should search for valid blocks that no
+  longer contain valid data.  It should pre-erase them, put them in
+  a good but empty state... all ready for file system re-organization.
+
+
+
diff --git a/nuttx/fs/nxffs/nxffs.h b/nuttx/fs/nxffs/nxffs.h
index 9b7bdc4ce..5882cf3e3 100644
--- a/nuttx/fs/nxffs/nxffs.h
+++ b/nuttx/fs/nxffs/nxffs.h
@@ -561,7 +561,7 @@ off_t nxffs_iotell(FAR struct nxffs_volume_s *volume);
  * Returned Value:
  *   Zero is returned on success.  Otherwise, a negated errno indicating the
  *   nature of the failure.
- *   
+ *
  * Defined in nxffs_cache.c
  *
  ****************************************************************************/
@@ -603,7 +603,7 @@ void nxffs_freeentry(FAR struct nxffs_entry_s *entry);
  *   offset - The FLASH memory offset to begin searching.
  *   entry  - A pointer to memory provided by the caller in which to return
  *     the inode description.
- *  
+ *
  * Returned Value:
  *   Zero is returned on success. Otherwise, a negated errno is returned
  *   that indicates the nature of the failure.
@@ -987,7 +987,7 @@ int nxffs_wrblkhdr(FAR struct nxffs_volume_s *volume,
  * Input Parameters:
  *   volume - Describes the NXFFS volume.
  *   datlen  - A memory location to return the data block length.
- *  
+ *
  * Returned Value:
  *   Zero is returned on success. Otherwise, a negated errno is returned
  *   that indicates the nature of the failure.