summaryrefslogtreecommitdiff
path: root/nuttx/fs
diff options
context:
space:
mode:
Diffstat (limited to 'nuttx/fs')
-rw-r--r--nuttx/fs/fat/Kconfig2
-rw-r--r--nuttx/fs/fat/fs_fat32.c4
-rw-r--r--nuttx/fs/fat/fs_fat32.h2
-rw-r--r--nuttx/fs/mmap/README.txt156
-rw-r--r--nuttx/fs/nxffs/nxffs.h2
-rw-r--r--nuttx/fs/nxffs/nxffs_block.c4
-rw-r--r--nuttx/fs/nxffs/nxffs_cache.c2
-rw-r--r--nuttx/fs/nxffs/nxffs_pack.c10
-rw-r--r--nuttx/fs/nxffs/nxffs_read.c4
-rw-r--r--nuttx/fs/nxffs/nxffs_unlink.c2
-rw-r--r--nuttx/fs/nxffs/nxffs_write.c2
11 files changed, 95 insertions, 95 deletions
diff --git a/nuttx/fs/fat/Kconfig b/nuttx/fs/fat/Kconfig
index 1831efc77..3f322c626 100644
--- a/nuttx/fs/fat/Kconfig
+++ b/nuttx/fs/fat/Kconfig
@@ -57,7 +57,7 @@ config FAT_DMAMEMORY
allocated each time a FAT file is opened.
Some hardware, however, may require special DMA-capable memory in
- order to perform the the transfers. If FAT_DMAMEMORY is defined
+ order to perform the transfers. If FAT_DMAMEMORY is defined
then the architecture-specific hardware must provide the functions
fat_dma_alloc() and fat_dma_free(): fat_dmalloc() will allocate
DMA-capable memory of the specified size; fat_dmafree() is the
diff --git a/nuttx/fs/fat/fs_fat32.c b/nuttx/fs/fat/fs_fat32.c
index a6981d088..7cfa7a8bc 100644
--- a/nuttx/fs/fat/fs_fat32.c
+++ b/nuttx/fs/fat/fs_fat32.c
@@ -1548,12 +1548,12 @@ static int fat_readdir(struct inode *mountpt, struct fs_dirent_s *dir)
{
/* The name was successfully extracted. Re-read the
* attributes: If this is long directory entry, then the
- * attributes that we need will be the the final, short file
+ * attributes that we need will be the final, short file
* name entry and not in the directory entry where we started
* looking for the file name. We can be assured that, on
* success, fat_dirname2path() will leave the short file name
* entry in the cache regardless of the kind of directory
- * entry. We simply have to re-read it to cover the the long
+ * entry. We simply have to re-read it to cover the long
* file name case.
*/
diff --git a/nuttx/fs/fat/fs_fat32.h b/nuttx/fs/fat/fs_fat32.h
index 81f3f4675..4c20e5c95 100644
--- a/nuttx/fs/fat/fs_fat32.h
+++ b/nuttx/fs/fat/fs_fat32.h
@@ -687,7 +687,7 @@
* allocated each time a FAT file is opened.
*
* Some hardware, however, may require special DMA-capable memory in
- * order to perform the the transfers. If CONFIG_FAT_DMAMEMORY is defined
+ * order to perform the transfers. If CONFIG_FAT_DMAMEMORY is defined
* then the architecture-specific hardware must provide the funtions
* fat_dma_alloc() and fat_dma_free() as prototyped below: fat_dmalloc()
* will allocate DMA-capable memory of the specified size; fat_dmafree()
diff --git a/nuttx/fs/mmap/README.txt b/nuttx/fs/mmap/README.txt
index cf4c51e9e..3e97650b3 100644
--- a/nuttx/fs/mmap/README.txt
+++ b/nuttx/fs/mmap/README.txt
@@ -1,78 +1,78 @@
-fs/mmap README File
-===================
-
-NuttX operates in a flat open address space and is focused on MCUs that do
-support Memory Management Units (MMUs). Therefore, NuttX generally does not
-require mmap() functionality and the MCUs generally cannot support true
-memory-mapped files.
-
-However, memory mapping of files is the mechanism used by NXFLAT, the NuttX
-tiny binary format, to get files into memory in order to execute them.
-mmap() support is therefore required to support NXFLAT. There are two
-conditions where mmap() can be supported:
-
-1. mmap can be used to support eXecute In Place (XIP) on random access media
- under the following very restrictive conditions:
-
- a. The filesystem supports the FIOC_MMAP ioctl command. Any file
- system that maps files contiguously on the media should support
- this ioctl. (vs. file system that scatter files over the media
- in non-contiguous sectors). As of this writing, ROMFS is the
- only file system that meets this requirement.
-
- b. The underlying block driver supports the BIOC_XIPBASE ioctl
- command that maps the underlying media to a randomly accessible
- address. At present, only the RAM/ROM disk driver does this.
-
- Some limitations of this approach are as follows:
-
- a. Since no real mapping occurs, all of the file contents are "mapped"
- into memory.
-
- b. All mapped files are read-only.
-
- c. There are no access privileges.
-
-2. If CONFIG_FS_RAMMAP is defined in the configuration, then mmap() will
- support simulation of memory mapped files by copying files whole
- into RAM. These copied files have some of the properties of
- standard memory mapped files. There are many, many exceptions
- exceptions, however. Some of these include:
-
- a. The goal is to have a single region of memory that represents a single
- file and can be shared by many threads. That is, given a filename a
- thread should be able to open the file, get a file descriptor, and
- call mmap() to get a memory region. Different file descriptors opened
- with the same file path should get the same memory region when mapped.
-
- The limitation in the current design is that there is insufficient
- knowledge to know that these different file descriptors correspond to
- the same file. So, for the time being, a new memory region is created
- each time that rammap() is called. Not very useful!
-
- b. The entire mapped portion of the file must be present in memory.
- Since it is assumed the the MCU does not have an MMU, on-demanding
- paging in of file blocks cannot be supported. Since the while mapped
- portion of the file must be present in memory, there are limitations
- in the size of files that may be memory mapped (especially on MCUs
- with no significant RAM resources).
-
- c. All mapped files are read-only. You can write to the in-memory image,
- but the file contents will not change.
-
- d. There are no access privileges.
-
- e. Since there are no processes in NuttX, all mmap() and munmap()
- operations have immediate, global effects. Under Linux, for example,
- munmap() would eliminate only the mapping with a process; the mappings
- to the same file in other processes would not be effected.
-
- f. Like true mapped file, the region will persist after closing the file
- descriptor. However, at present, these ram copied file regions are
- *not* automatically "unmapped" (i.e., freed) when a thread is terminated.
- This is primarily because it is not possible to know how many users
- of the mapped region there are and, therefore, when would be the
- appropriate time to free the region (other than when munmap is called).
-
- NOTE: Note, if the design limitation of a) were solved, then it would be
- easy to solve exception d) as well.
+fs/mmap README File
+===================
+
+NuttX operates in a flat open address space and is focused on MCUs that do
+support Memory Management Units (MMUs). Therefore, NuttX generally does not
+require mmap() functionality and the MCUs generally cannot support true
+memory-mapped files.
+
+However, memory mapping of files is the mechanism used by NXFLAT, the NuttX
+tiny binary format, to get files into memory in order to execute them.
+mmap() support is therefore required to support NXFLAT. There are two
+conditions where mmap() can be supported:
+
+1. mmap can be used to support eXecute In Place (XIP) on random access media
+ under the following very restrictive conditions:
+
+ a. The filesystem supports the FIOC_MMAP ioctl command. Any file
+ system that maps files contiguously on the media should support
+ this ioctl. (vs. file system that scatter files over the media
+ in non-contiguous sectors). As of this writing, ROMFS is the
+ only file system that meets this requirement.
+
+ b. The underlying block driver supports the BIOC_XIPBASE ioctl
+ command that maps the underlying media to a randomly accessible
+ address. At present, only the RAM/ROM disk driver does this.
+
+ Some limitations of this approach are as follows:
+
+ a. Since no real mapping occurs, all of the file contents are "mapped"
+ into memory.
+
+ b. All mapped files are read-only.
+
+ c. There are no access privileges.
+
+2. If CONFIG_FS_RAMMAP is defined in the configuration, then mmap() will
+ support simulation of memory mapped files by copying files whole
+ into RAM. These copied files have some of the properties of
+ standard memory mapped files. There are many, many exceptions
+ exceptions, however. Some of these include:
+
+ a. The goal is to have a single region of memory that represents a single
+ file and can be shared by many threads. That is, given a filename a
+ thread should be able to open the file, get a file descriptor, and
+ call mmap() to get a memory region. Different file descriptors opened
+ with the same file path should get the same memory region when mapped.
+
+ The limitation in the current design is that there is insufficient
+ knowledge to know that these different file descriptors correspond to
+ the same file. So, for the time being, a new memory region is created
+ each time that rammap() is called. Not very useful!
+
+ b. The entire mapped portion of the file must be present in memory.
+ Since it is assumed that the MCU does not have an MMU, on-demanding
+ paging in of file blocks cannot be supported. Since the while mapped
+ portion of the file must be present in memory, there are limitations
+ in the size of files that may be memory mapped (especially on MCUs
+ with no significant RAM resources).
+
+ c. All mapped files are read-only. You can write to the in-memory image,
+ but the file contents will not change.
+
+ d. There are no access privileges.
+
+ e. Since there are no processes in NuttX, all mmap() and munmap()
+ operations have immediate, global effects. Under Linux, for example,
+ munmap() would eliminate only the mapping with a process; the mappings
+ to the same file in other processes would not be effected.
+
+ f. Like true mapped file, the region will persist after closing the file
+ descriptor. However, at present, these ram copied file regions are
+ *not* automatically "unmapped" (i.e., freed) when a thread is terminated.
+ This is primarily because it is not possible to know how many users
+ of the mapped region there are and, therefore, when would be the
+ appropriate time to free the region (other than when munmap is called).
+
+ NOTE: Note, if the design limitation of a) were solved, then it would be
+ easy to solve exception d) as well.
diff --git a/nuttx/fs/nxffs/nxffs.h b/nuttx/fs/nxffs/nxffs.h
index 80e34939c..b2ac44b9c 100644
--- a/nuttx/fs/nxffs/nxffs.h
+++ b/nuttx/fs/nxffs/nxffs.h
@@ -670,7 +670,7 @@ extern off_t nxffs_inodeend(FAR struct nxffs_volume_s *volume,
* Name: nxffs_verifyblock
*
* Description:
- * Assure the the provided (logical) block number is in the block cache
+ * Assure that the provided (logical) block number is in the block cache
* and that it has a valid block header (i.e., proper magic and
* marked good)
*
diff --git a/nuttx/fs/nxffs/nxffs_block.c b/nuttx/fs/nxffs/nxffs_block.c
index 6701b6e6b..a0f76766a 100644
--- a/nuttx/fs/nxffs/nxffs_block.c
+++ b/nuttx/fs/nxffs/nxffs_block.c
@@ -74,7 +74,7 @@
* Name: nxffs_verifyblock
*
* Description:
- * Assure the the provided (logical) block number is in the block cache
+ * Assure that the provided (logical) block number is in the block cache
* and that it has a valid block header (i.e., proper magic and
* marked good)
*
@@ -94,7 +94,7 @@ int nxffs_verifyblock(FAR struct nxffs_volume_s *volume, off_t block)
FAR struct nxffs_block_s *blkhdr;
int ret;
- /* Make sure the the block is in the cache */
+ /* Make sure that the block is in the cache */
ret = nxffs_rdcache(volume, block);
if (ret < 0)
diff --git a/nuttx/fs/nxffs/nxffs_cache.c b/nuttx/fs/nxffs/nxffs_cache.c
index 0cc97980e..059c1e729 100644
--- a/nuttx/fs/nxffs/nxffs_cache.c
+++ b/nuttx/fs/nxffs/nxffs_cache.c
@@ -251,7 +251,7 @@ int nxffs_getc(FAR struct nxffs_volume_s *volume, uint16_t reserve)
}
while (ret != OK);
- /* Return the the character at this offset. Note that on return,
+ /* Return the character at this offset. Note that on return,
* iooffset could point to the byte outside of the current block.
*/
diff --git a/nuttx/fs/nxffs/nxffs_pack.c b/nuttx/fs/nxffs/nxffs_pack.c
index 5a82ae4fd..4fe3fb681 100644
--- a/nuttx/fs/nxffs/nxffs_pack.c
+++ b/nuttx/fs/nxffs/nxffs_pack.c
@@ -260,7 +260,7 @@ static inline off_t nxffs_mediacheck(FAR struct nxffs_volume_s *volume,
* pack - The volume packing state structure.
* froffset - On input, this is the location where we should be searching
* for the location to begin packing. On successful return, froffset
- * will be set the the offset in FLASH where the first inode should be
+ * will be set to the offset in FLASH where the first inode should be
* copied to. If -ENOSPC is returned -- meaning that the FLASH is full
* -- then no packing can be performed. In this case, then the free
* flash offset is returned through this location.
@@ -939,7 +939,7 @@ static inline int nxffs_packblock(FAR struct nxffs_volume_s *volume,
nxffs_packtransfer(volume, pack);
/* Now, either the (1) src block has been fully transferred, (2) all
- * of the source data has been transferred, or (3) the the destination
+ * of the source data has been transferred, or (3) the destination
* block is full, .. or all three.
*
* Check if all of the bytes in the source inode have been transferred.
@@ -1121,7 +1121,7 @@ nxffs_setupwriter(FAR struct nxffs_volume_s *volume,
*
* Writing is performed at the end of the free FLASH region and this
* implemenation is restricted to a single writer. The new inode is not
- * written to FLASH until the the writer is closed and so will not be
+ * written to FLASH until the writer is closed and so will not be
* found by nxffs_packblock().
*
* Input Parameters:
@@ -1192,7 +1192,7 @@ static inline int nxffs_packwriter(FAR struct nxffs_volume_s *volume,
nxffs_packtransfer(volume, pack);
/* Now, either the (1) src block has been fully transferred, (2) all
- * of the source data has been transferred, or (3) the the destination
+ * of the source data has been transferred, or (3) the destination
* block is full, .. or all three.
*
* Check if all of the bytes in the source inode have been transferred.
@@ -1473,7 +1473,7 @@ start_pack:
/* Writing is performed at the end of the free
* FLASH region and this implemenation is restricted
* to a single writer. The new inode is not
- * written to FLASH until the the writer is closed
+ * written to FLASH until the writer is closed
* and so will not be found by nxffs_packblock().
*/
diff --git a/nuttx/fs/nxffs/nxffs_read.c b/nuttx/fs/nxffs/nxffs_read.c
index b638dbfd4..a97c09263 100644
--- a/nuttx/fs/nxffs/nxffs_read.c
+++ b/nuttx/fs/nxffs/nxffs_read.c
@@ -127,7 +127,7 @@ static ssize_t nxffs_rdseek(FAR struct nxffs_volume_s *volume,
datstart = datend;
datend += blkentry->datlen;
- /* Offset to search for the the next data block */
+ /* Offset to search for the next data block */
offset = blkentry->hoffset + SIZEOF_NXFFS_DATA_HDR + blkentry->datlen;
}
@@ -418,7 +418,7 @@ int nxffs_rdblkhdr(FAR struct nxffs_volume_s *volume, off_t offset,
uint16_t dlen;
int ret;
- /* Make sure the the block containing the data block header is in the cache */
+ /* Make sure that the block containing the data block header is in the cache */
nxffs_ioseek(volume, offset);
ret = nxffs_rdcache(volume, volume->ioblock);
diff --git a/nuttx/fs/nxffs/nxffs_unlink.c b/nuttx/fs/nxffs/nxffs_unlink.c
index 73b0f360a..8c8553025 100644
--- a/nuttx/fs/nxffs/nxffs_unlink.c
+++ b/nuttx/fs/nxffs/nxffs_unlink.c
@@ -122,7 +122,7 @@ int nxffs_rminode(FAR struct nxffs_volume_s *volume, FAR const char *name)
nxffs_ioseek(volume, entry.hoffset);
- /* Make sure the the block is in the cache */
+ /* Make sure that the block is in the cache */
ret = nxffs_rdcache(volume, volume->ioblock);
if (ret < 0)
diff --git a/nuttx/fs/nxffs/nxffs_write.c b/nuttx/fs/nxffs/nxffs_write.c
index bf32b0fb4..756ac7467 100644
--- a/nuttx/fs/nxffs/nxffs_write.c
+++ b/nuttx/fs/nxffs/nxffs_write.c
@@ -745,7 +745,7 @@ int nxffs_wrverify(FAR struct nxffs_volume_s *volume, size_t size)
}
}
- /* If we get here, then we have looked at every byte in the the block
+ /* If we get here, then we have looked at every byte in the block
* and did not find any sequence of erased bytes long enough to hold
* the object. Skip to the next, valid block.
*/
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-20 17:52:50 +0000