38eadbb575
Follow up commit for [1] in response to the request to make the mount behaviour configurable whether the number of free clusters is read from the fsinfo section or computed (as the white paper suggests). Default is the original behaviour of NUTTX, just read fsinfo. [1] https://github.com/apache/incubator-nuttx/pull/3760
230 lines
9.5 KiB
Plaintext
230 lines
9.5 KiB
Plaintext
#
|
|
# For a description of the syntax of this configuration file,
|
|
# see the file kconfig-language.txt in the NuttX tools repository.
|
|
#
|
|
|
|
config FS_FAT
|
|
bool "FAT file system"
|
|
default n
|
|
depends on !DISABLE_MOUNTPOINT
|
|
---help---
|
|
Enable FAT filesystem support
|
|
|
|
if FS_FAT
|
|
|
|
config FAT_COMPUTE_FSINFO
|
|
bool "FAT compute free space in FSINFO at mount time"
|
|
default n
|
|
---help---
|
|
Enables the computation of free clusters at mount time as suggested by the
|
|
white paper for FAT. The standard behavior of Nuttx is to trust the stored
|
|
value and only recompute it once required. This works if the file system
|
|
is never mounted to another OS. SD-cards which are mounted to Windows to
|
|
modify the content might report wrong space after reinserting it to Nuttx.
|
|
It is recommended to activate this setting if the "SD-Card" is swapped
|
|
between systems.
|
|
|
|
config FAT_LCNAMES
|
|
bool "FAT upper/lower names"
|
|
default n
|
|
---help---
|
|
Enable use of the NT-style upper/lower case 8.3
|
|
file name support.
|
|
|
|
config FAT_LFN
|
|
bool "FAT long file names"
|
|
default n
|
|
---help---
|
|
Enable FAT long file names. NOTE: Microsoft claims
|
|
patents on FAT long file name technology. Please read the
|
|
disclaimer in the top-level NOTICE file and only enable this
|
|
feature if you understand these issues.
|
|
|
|
config FAT_MAXFNAME
|
|
int "FAT maximum file name size"
|
|
depends on FAT_LFN
|
|
default 32
|
|
range 12 255
|
|
---help---
|
|
If FAT_LFN is defined, then the default, maximum long file
|
|
name is 255 bytes. This can eat up a lot of memory (especially stack
|
|
space). If you are willing to live with some non-standard, short long
|
|
file names, then define this value to be something more reasonable. A
|
|
good choice would be the same value as selected for NAME_MAX which will
|
|
limit the visibility of longer file names anyway.
|
|
|
|
This setting may not exceed NAME_MAX. That will be verified at compile
|
|
time. The minimum values is 12 due to assumptions in internal logic.
|
|
|
|
config FAT_LFN_ALIAS_HASH
|
|
bool "Use faster method for forming long filename 8.3 alias"
|
|
depends on FAT_LFN
|
|
default n
|
|
---help---
|
|
Long filenames on FAT filesystems have associated 8.3 character alias
|
|
short filenames. The traditional form of these is FILENA~1.EXT with
|
|
a running count of the number of similar names. However creating this
|
|
unique count can take several seconds if there are many similarly named
|
|
files in the directory. Enabling FAT_LFN_ALIAS_HASH uses an alternative
|
|
format of FI0123~1.TXT where the four digits are a hash of the original
|
|
filename. This method is similar to what is used by Windows 2000 and
|
|
later.
|
|
|
|
config FAT_LFN_UTF8
|
|
bool "Allow UTF8 long filenames"
|
|
depends on FAT_LFN
|
|
default n
|
|
---help---
|
|
UTF8 long filenames are accepted and converted to UCS2.
|
|
|
|
config FAT_LFN_ALIAS_TRAILCHARS
|
|
int "Number of trailing characters to use for 8.3 alias"
|
|
depends on FAT_LFN
|
|
default 0
|
|
---help---
|
|
Traditional format for long filename 8.3 aliases takes first 6
|
|
characters of long filename. If this option is set to N > 0,
|
|
NuttX will instead take first 6-N and last N characters to form
|
|
the short name. This is useful for filenames like "datafile12.txt"
|
|
where the first characters would always remain the same.
|
|
|
|
config FS_FATTIME
|
|
bool "FAT timestamps"
|
|
default n
|
|
---help---
|
|
Support FAT date and time. NOTE: There is not
|
|
much sense in supporting FAT date and time unless you have a
|
|
hardware RTC or other way to get the time and date.
|
|
|
|
config FAT_FORCE_INDIRECT
|
|
bool "Force direct transfers"
|
|
default n
|
|
---help---
|
|
Normally, the default behavior for the FAT file system is to perform
|
|
data transfers indirectly though specially allocated sector buffers
|
|
or, under certain circumstances, directly through user provided
|
|
buffers . These circumstances are: (1) The transfer is being
|
|
performed from the beginning of a sector (2) the user-provided
|
|
buffer will hold the full sector of data.
|
|
|
|
Some hardware, however, may require special DMA-capable memory or
|
|
specially aligned memory in order to perform the transfers. In this
|
|
case, there may be no circumstance where the user buffer can be used.
|
|
Selecting this option will disable all attempts to use the user-
|
|
provided buffer: All transfers will be force to be performed
|
|
indirectly through the FAT file systems sector buffers.
|
|
|
|
Note: This will have the negative impact of: (1) An extra data
|
|
copy to transfer the data between the user buffer and the FAT file
|
|
systems internal sector buffers, and (2) A loss of performance
|
|
because I/O will be limited to one sector at a time.
|
|
|
|
This would typically be used with CONFIG_FAT_DMAMEMORY so that
|
|
special memory allocators are also used and transfers are also
|
|
performed using only that specially allocated memory.
|
|
CONFIG_FAT_DMAMEMORY, on the other hand, is often used without
|
|
CONFIG_FAT_FORCE_INDIRECT when the user memory buffers may come
|
|
from mixed locations, some of which are DMA-able and some of
|
|
which are not. But CONFIG_FAT_FORCE_INDIRECT could be used
|
|
without CONFIG_FAT_DMAMEMORY if there is, for example, only a
|
|
memory alignment constraints.
|
|
|
|
FORCE_ DMA DIRECT EXAMPLE USAGE
|
|
INDIRECT MEMORY RETRY
|
|
Y Y * Use specially allocated memory;
|
|
Never use caller provided buffer
|
|
Y N * Not recommended
|
|
N Y ** Special memory required; user memory
|
|
has mixed capability; sometimes
|
|
caller memory is not usable
|
|
N N Y No special memory but there are
|
|
alignment requirements; return is
|
|
caller buffer is not properly aligned
|
|
N N N User memory can always be used for
|
|
transfer.
|
|
|
|
* CONFIG_DIRECT_RETRY cannot be selected with CONFIG_FORCE_INDIRECT
|
|
** CONFIG_DIRECT_RETRY is automatically selected with CONFIG_DMA_MEMORY
|
|
|
|
config FAT_DMAMEMORY
|
|
bool "DMA memory allocator"
|
|
default n
|
|
select FAT_DIRECT_RETRY if !FAT_FORCE_INDIRECT
|
|
---help---
|
|
The FAT file system allocates two I/O buffers for data transfer, each
|
|
are the size of one device sector. One of the buffers is allocated
|
|
once for each FAT volume that is mounted; the other buffers are
|
|
allocated each time a FAT file is opened.
|
|
|
|
Some hardware, however, may require special DMA-capable memory in
|
|
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
|
|
corresponding function that will be called to free the DMA-capable
|
|
memory.
|
|
|
|
FORCE_ DMA DIRECT EXAMPLE USAGE
|
|
INDIRECT MEMORY RETRY
|
|
Y Y * Use specially allocated memory;
|
|
Never use caller provided buffer
|
|
Y N * Not recommended
|
|
N Y ** Special memory required; user memory
|
|
has mixed capability; sometimes
|
|
caller memory is not usable
|
|
N N Y No special memory but there are
|
|
alignment requirements; return is
|
|
caller buffer is not properly aligned
|
|
N N N User memory can always be used for
|
|
transfer.
|
|
|
|
* CONFIG_DIRECT_RETRY cannot be selected with CONFIG_FORCE_INDIRECT
|
|
** CONFIG_DIRECT_RETRY is automatically selected with CONFIG_DMA_MEMORY
|
|
|
|
config FAT_DIRECT_RETRY
|
|
bool "Direct transfer retry"
|
|
default y if FAT_DMAMEMORY
|
|
default n if !FAT_DMAMEMORY
|
|
depends on !FAT_FORCE_INDIRECT
|
|
---help---
|
|
The FAT file system contains internal, well aligned sector buffers
|
|
for indirect data transfer. These transfers are indirect in the
|
|
sense that that the actual transfer occurs into/out of the sector
|
|
buffers and an additional copy is necessary to/from the user-
|
|
provided I/O buffers. But under certain conditions, the FAT file
|
|
system will use the caller-provided I/O buffers directly to improve
|
|
efficiency. Those conditions are (1) CONFIG_FAT_FORCE_INDIRECT is
|
|
not defined, (2) The access is to/from the beginning of a sector,
|
|
and (3) the user provided buffer is large enough to hold an entire
|
|
sector.
|
|
|
|
The lower level SDIO driver may have, certain requirements on the
|
|
memory buffer in order to perform the transfer. Perhaps special
|
|
DMA memory should be used (with CONFIG_FAT_DMAMEMORY) or perhaps
|
|
some special memory alignment is required to interface with the
|
|
hardware.
|
|
|
|
If this option is selected, then the FAT file system will first
|
|
try the user provided I/O buffer under above conditions. If the
|
|
transfer fails with -EFAULT. then the FAT file system will try one
|
|
more time using the internal sector buffers.
|
|
|
|
FORCE_ DMA DIRECT EXAMPLE USAGE
|
|
INDIRECT MEMORY RETRY
|
|
Y Y * Use specially allocated memory;
|
|
Never use caller provided buffer
|
|
Y N * Not recommended
|
|
N Y ** Special memory required; user memory
|
|
has mixed capability; sometimes
|
|
caller memory is not usable
|
|
N N Y No special memory but there are
|
|
alignment requirements; return is
|
|
caller buffer is not properly aligned
|
|
N N N User memory can always be used for
|
|
transfer.
|
|
|
|
* CONFIG_DIRECT_RETRY cannot be selected with CONFIG_FORCE_INDIRECT
|
|
** CONFIG_DIRECT_RETRY is automatically selected with CONFIG_DMA_MEMORY
|
|
|
|
endif # FAT
|