| Age | Commit message (Collapse) | Author |
|---|
|
Use the following variant which was already used by most source files:
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
|
|
|
|
Username: deuteriumoxide Email: jacobshin313@gmail.com
|
|
The function rtems_rfs_buffer_sync() erroneously calls
rtems_disk_release(). This screws up the reference counting of the disk.
Close #3484.
|
|
rtems_rfs_dir_read searches the directory inode's entries list starting
at the specified offset until an empty entry (last entry) is encountered. It
fills in a struct dirent with the name of the entry, length of the name, ino of
the entry, and the absolute offset of the entry in the parent directory's
entries
list.
Unfortunately, the stock implementation of rtems_rfs_dir_read returns a
somewhat arbitrary offset (as dirent::d_off), while
rtems_rfs_dir_lookup_ino always returns the correct offset.
This change fixes that logic so the returned offset is accurate.
Tested by comparing the offset returned in dirent with the result of
rtems_rfs_dir_lookup_ino.
|
|
The bitmap allocation accounting logic in rtems-rfs-bitmaps.c is flawed
around control->free. Specifically:
In rtems_rfs_bitmap_map_set():
control->free is only decremented when its corresponding search bit is
toggled. This is wrong and will miss on average 31/32 set updates.
In rtems_rfs_bitmap_map_clear():
control->free is incremented unconditionally.
The correct behavior is:
When updating the map, check if the bit is already set/clear. Only update
control->free when the bit is toggled.
This change enforced the correct behavior.
Tested by inspecting the internal data structure.
|
|
In rtems_rfs_bitmap_map_clear_all(), control->free is set to 'elements',
which is the number of elements in the bitmap. This is incorrect, as
control->free should contain the number of free bits, not elements.
This change fixes the logic and resets control->free to a correct value.
|
|
This change fixes https://devel.rtems.org/ticket/3089.
Briefly, rtems_rfs_group.c contains conflicting conversions between
block numbers and group number and bit offset pairs. This caused the
actual bit stored on the bitmask to be one bit displaced from its
intended location.
For more details, please see the associated ticket.
Tested by inspecting the written bitmasks with and without this change.
|
|
Update #2843.
|
|
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.
|
|
Update #3082.
|
|
The RTEMS_BLKIO_SETBLKSIZE IO control expects an uint32_t parameter and
not a size_t which is 64-bits on 64-bit targets.
Update #3082.
|
|
Prepare for header file move to common include directory.
Update #3254.
|
|
Update #3132.
|
|
Added a mmap file handler to struct _rtems_filesystem_file_handlers_r.
Updated each file handler object to support the default mmap handler.
Updated mmap() to call the mmap handler for MAP_SHARED.
Added a mmap file handler for shm
Added support for MAP_ANON in mmap().
Updates #2859
|
|
Provide extentions to <inttpes.h> PRIxxx constants for more POSIX types.
Start with existing definitions found in RTEMS Project owned code
in cpukit/.
updates #2983.
|
|
Drop superfluous <stdlib.h> include from <rtems/diskdevs.h> since this
leads to conflicts with the latest Newlib in case this header file is
used in the FreeBSD kernel space, e.g. for USB mass storage support.
|
|
The permission is check by the upper layer.
|
|
Close #2433.
|
|
|
|
|
|
|
|
Use the fstat handler instead.
|
|
Closes #2139
|
|
|
|
|
|
warnings
This may actually be a problem in inttypes.h.
|
|
|
|
Return the first error if one or more happen when deleting an inode.
|
|
|
|
|
|
|
|
The readv() and writev() support was implemented in terms of multiple
calls to the read and write handlers. This imposes a problem on device
files which use an IO vector as single request entity. For example a
low-level network device (e.g. BPF(4)) may use an IO vector to create
one frame from multiple protocol layers each with its own IO vector
entry.
|
|
This is for the RFS file system. There is a bug in the
rtems_rfs_bitmap_create_search loop. It is supposed to iterate
over the range of bits in a search element ( usually 32 bits ),
so it should loop through bits 0 through 31. Instead it loops
through 0 - 32, causing some blocks not to be allocated. As in
PR 2163, this depends on the block size and number of blocks in
a file system. Block sizes and group sizes that are powers of 2
seem to work fine ( 512 byte blocks, 4096 block groups, etc ).
When the block sizes are not powers of 2, then this loop error
causes some of the blocks at the end of a group to be skipped,
preventing 100% of the blocks from being used. A simple test
for this and PR2163 is to create a RAM disk with block size
3900 and at least 1 full group ( 31200 blocks ). A file system
with these sizes will not be able to allocate 100% of the blocks.
|
|
This is for the RFS file system. The statvfs call reports 1 block free
when the file system is full because it does not account for the superblock
in its calculation of free blocks.
This is a simple fix that adjusts the number of blocks reported to account
for the superblock. We may want to wait for a more complete solution such
as locating the superblock in each group.
|
|
This is for the RFS file system. There is a bug in the group search
algorithm where it will skip groups, causing blocks to remain
unallocated. This is dependant on the size of the blocks and number
of blocks in a group, so it does not always show up. The fix corrects
the skipping of groups during the search, allowing all of the blocks
to be found.
|
|
Patch from Nick for this. Thanks.
|
|
|
|
|
|
Implement POSIX requirements in the high-level file system layer.
|
|
This area is protected by the RFS file system instance lock.
|
|
declaration, matching its definition
See https://www.rtems.org/bugzilla/show_bug.cgi?id=2137
|
|
|
|
the error.
The change lets the mrfs_fsrdwr test pass.
|
|
|
|
The two functions are independent of the POSIX API.
|
|
Change rtems-rfs to rtems_rfs
|
|
The output of the modules.html is much improved. Most
filesystem and POSIX API related groups are properly nested.
Some formatting issues were addressed as were multiple
inconsistencies.
|
|
http://www.google-melange.com/gci/task/view/google/gci2012/8120204
Patch committed with fixes for whitespace issues.
|
|
There were minor conflicts and the modifications that were
in the repo were favored over the modifications in the submitted
patch.
|
