The briefs of the block device drivers and the PCI headers named a
topic, not the content of the file. Five libblock files carried the
same brief "Media implementation.". Four more carried "RAM disk block
device implementation.".
Write every brief in the style of the tree. A source brief starts with
"This source file contains" and names the functions the file defines
where there are at most three. A header brief starts with "This header
file provides". Put @file, @ingroup and @brief in this order.
The CAN and CAN FD stack keeps its briefs. Its contributors write them
in a style of their own.
Updates #5717.
Assisted-by: Claude:claude-opus-5 claude-code
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Fourteen sources in sapi sat in an API group. RTEMSAPI held the code
which implements the interface, not only the interface. Three of them
named RTEMSAPIClassicRBTrees, which no file defines. Five files in
libblock named libblock, which no file defines either. Three libblock
files wrote the group title after the group name.
Point the chain, profiling and timecounter sources at the Score groups
which already cover those topics. Point the counter, red-black tree and
red-black tree heap sources at their new implementation groups. Give
the five libblock files the group of the driver they belong to. Drop
the group title from the three @ingroup lines.
The header rbtree.h names the group RTEMSAPIRBTrees, which rbtree.h
itself defines.
Updates #5717.
Assisted-by: Claude:claude-opus-5 claude-code
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
The CAN and CAN FD stack used the group name CANFDStack. The media
server used the group name RTEMSMedia. No file defines either name, so
Doxygen dropped 20 files and five CAN subgroups from the group graph.
The header can.h also left the CANChip group open, so every later
declaration joined it.
Define CANFDStack in dev/can/can.h and add the interfaces of the header
to it. Close the CANChip group before the CANIoctl group starts.
Rename RTEMSMedia to RTEMSDeviceMedia and define it in media.h. Both
groups are children of RTEMSDeviceDrivers.
Updates #5717.
Assisted-by: Claude:claude-opus-5 claude-code
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Using sizeof(BASE_NAME) incorrectly targeted the null terminator instead
of the suffix character 'a', corrupting device names when configuring
multiple instances. Subtract 1 to properly index the character.
Fixes#5402.
In rtems_bdpart_register(), when create_logical_disk_name() fails to
allocate memory and returns NULL, the error code variable 'esc' was
incorrectly assigned 'sc' (which evaluates to RTEMS_SUCCESSFUL).
This caused the function to falsely return RTEMS_SUCCESSFUL even when
memory allocation failed. Fix it by assigning RTEMS_NO_MEMORY.
- added CRC check for rtems_fdisk_recover_block_mappings function
- Computes CRC of page data and compares with page descriptor
- Marks pages as bad if CRC mismatch occurs
On some BSP builds, the variable q was reported as used before
it was initialized. This is a false positive. The variable is now
initialized to NULL to prevent this.
This is intended to close any valid FDs that were opened, but 0 is also
a valid FD. This change ensures that a FD of 0 is also closed properly.
Coverity CID 1467408 (original)
Coverity CID 1616151 (followup)
off_by_one: Testing whether handle fd is strictly greater than zero is
suspicious. fd leaks when it is zero.
Adds a peek function that allows (for example) a file system to suggest
the next blocks that should be used for read ahead. This can increase
the read speed of fragmented files.
Update #3689
The shell has an 'fdisk' command which has sub-commands 'mount' and 'unmount'.
These two sub-commands have a bug which causes them to be not able
to mount anything. This proposed patch removes the buggy file
cpukit/libblock/src/bdpart-mount.c and the mount/unmount commands
from 'fdisk' as bug fix. The 'fdisk' command itself is not removed.
The reasons for removing the sub-commands (instead of fixing the issue) are:
1) The bug has been introduced on 2010-May-31 with commit
29e92b090c. Since ten years no one
can use this feature, nor has anybody complained about it.
2) Besides of the 'fdisk' 'mount' sub-command, the shell has the
usual 'mount' and 'unmount' commands which can serve as
substitutes.
3) There are additional minor issues (see further down) which needed to
be addressed when the file will be kept.
What follows below is the precise bug description.
The bug is in function rtems_bdpart_mount() which is only be used
by the 'fdisk' shell command to mount all partitions of a disk with a
single command:
> fdisk DISK_NAME mount
> mounts the file system of each partition of the disk
>
> fdisk DISK_NAME unmount
> unmounts the file system of each partition of the disk
The whole command does not work because in file
cpukit/libblock/src/bdpart-mount.c line 103 specifies the file system type
of each partition to be "msdos". Yet, "msdos" does not exist. The name
must be "dosfs".
Beside of this fundamental problem, there are more issues with the code
in bdpart-mount.c:
1) The function returns RTEMS_SUCCESSFUL despite the mount always fails.
2) The reason for errors is not written to the terminal.
3) The directory '/mnt' is created but not deleted later on (failure or not).
3) There is no documentation about this special 'fdisk' feature in the
RTEMS Shell Guide ('fdisk' is mentioned but its documentation is a
bit short):
https://docs.rtems.org/branches/master/shell/
file_and_directory.html#fdisk-format-disk
4) Only "msdos" formatted partitions can be mounted and all partitions
are mounted read-only. This is hard coded and cannot be changed by
options. Moreover, there is no information about this to the user of
the shell (i.e. using 'fdisk' mount requires insider knowledge).
How to reproduce:
1) For testing, I use the 'testsuites/samples/fileio.exe' sample with qemu:
> cd rtems
> env QEMU_AUDIO_DRV="none" qemu-system-arm -net none -nographic \
> -M realview-pbx-a9 -m 256M -kernel \
> build/arm/realview_pbx_a9_qemu/testsuites/samples/fileio.exe
2) Type any key to stop the timer and enter the sample tool.
Type 's' to enter the shell, login as 'root' with the password
shown in the terminal.
3) Type the following shell commands (they create a RAM disk,
partition it, register it, format it and try to mount it):
> mkrd
> fdisk /dev/rda fat32 16 write mbr
> fdisk /dev/rda register
> mkdos /dev/rda1
> fdisk /dev/rda mount
4) The last line above is the command which fails - without an error
message. There exists a '/mnt' directory but no '/mnt/rda1' directory
as it should be:
> ls -la /mnt
5) If you change line 103 of 'cpukit/libblock/src/bdpart-mount.c'
from "msdos" to "dosfs", compile and build the executable and
re-run the above test, '/mnt/rda1' exists (but the file system
is mounted read-only).
Close#4131
This patch does not only fix the compiler warning below. memcpy() is the
better function at this place as the terminating NUL character is never
copied here. Instead more characters will be appended to the
'logical_disk_name' later on.
../../../cpukit/libblock/src/bdpart-register.c:41:5:
warning: 'strncpy' output truncated before terminating nul copying
as many bytes from a string as its length [-Wstringop-truncation]
Currently if mount fails, a converter isn't destroyed. We have to take
care of two cases:
1. The user doesn't provide a converter.
In this case mounting a dosfs creates a default converter. This patch
makes sure that the converter is destroyed again if mount failes for
this case.
2. The user provides a converter.
In this case it's not sure that the dosfs specific routines are reached
because mount can fail before that. Therefore the user has to destroy
the converter himself again. This patch adds a documentation for that
and implements it in the media server.
Closes#4042.
This adds the possibility to request a retry in the media-listener if an
operation failed. Usefull for example if you want to automatically
reformat a disk if it wasn't possible to mount it.
A speciality of the RTEMS build system was the make preinstall step. It
copied header files from arbitrary locations into the build tree. The
header files were included via the -Bsome/build/tree/path GCC command
line option.
This has at least seven problems:
* The make preinstall step itself needs time and disk space.
* Errors in header files show up in the build tree copy. This makes it
hard for editors to open the right file to fix the error.
* There is no clear relationship between source and build tree header
files. This makes an audit of the build process difficult.
* The visibility of all header files in the build tree makes it
difficult to enforce API barriers. For example it is discouraged to
use BSP-specifics in the cpukit.
* An introduction of a new build system is difficult.
* Include paths specified by the -B option are system headers. This
may suppress warnings.
* The parallel build had sporadic failures on some hosts.
This patch removes the make preinstall step. All installed header
files are moved to dedicated include directories in the source tree.
Let @RTEMS_CPU@ be the target architecture, e.g. arm, powerpc, sparc,
etc. Let @RTEMS_BSP_FAMILIY@ be a BSP family base directory, e.g.
erc32, imx, qoriq, etc.
The new cpukit include directories are:
* cpukit/include
* cpukit/score/cpu/@RTEMS_CPU@/include
* cpukit/libnetworking
The new BSP include directories are:
* bsps/include
* bsps/@RTEMS_CPU@/include
* bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILIY@/include
There are build tree include directories for generated files.
The include directory order favours the most general header file, e.g.
it is not possible to override general header files via the include path
order.
The "bootstrap -p" option was removed. The new "bootstrap -H" option
should be used to regenerate the "headers.am" files.
Update #3254.
Sebastian Huber
Yang Zhang
Prakhar Kumar
Gedare Bloom
Joel Sherrill
Kinsey Moore
zak liang
Amar Takhar
Christian Mauderer
Frank Kühndel
Chris Johns