In nuttx the mode parameter to open is not required but in Linux,
and per the POSIX spec, mode is required if the O_CREAT flag is
passed.
The mode flags are different for NuttX and Linux so a new set of
PX4 defines was added:
PX4_O_MODE_777 - read, write, execute for user, group and other
PX4_O_MODE_666 - read, and write for user, group and other
PX4_O_MODE_600 - read, and write for user
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
Set a default path relative to current dir for the posix target.
Running make posixrun will create the required directoroes and then run
mainapp from its build location.
PX4_ROOTFSDIR is set to nothing for nuttx.
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
The dataman module now works under linux using /tmp/dataman as the
file path. Two files from NuttX were added to the Linux impl for
single linked queue handling.
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
The data manager dynamically allocates relatively small work item blocks
on an as needed basis. It never frees these, instead maintaining then in
a list of available block for reuse when needed. Even if these blocks
are small, the are required at non-deterministic times and can end up
scattered in memory thus causing memory fragmentation. In order to
mitigate this problems work item blocks are allocated in groups of 8 in
contiguous memory to reduce the number of scattered memory allocations.
In reality, based on current usage, rarely will more than one group of 8
be allocated.
Introduce SYS_RESTART_TYPE parameter having one of 3 values: boot
restart, inflight restart, or unknown restart, and defaulting to unknown
restart.
px4io.cpp sets this parameter according to the type of restart detected.
dataman.c retrieves this parameter and clears data entries according to
their persistence level. Does nothing if unknown restart.
When the data manager was first designed each file record contained a 2
byte header and an 126 byte data section, resulting in a record length
of 128 bytes. Along the way it was decided to add 2 spare bytes to the
record header, but regrettably the data section was not correspondingly
reduced in size so we end up with a record length of 130 bytes. This is
bad since it does not align with SD card flash sectors and results in
more erase/write flash cycles than necessary thus reducing the SD cards
life.
This update reduced the data section of the data manager to 124,
resulting in an optimal record length of 128 bytes.
In order to avoid the reuse of data previously written data in the old
format, which could result in catastrophic misinterpretation, the data
manager file is checked at startup. If it is found to be in the old
format, it is deleted and recreated with in the new record length. In
this case previously stored data is lost, but that is far safer than the
unpredictable result of using the old file.
