p[index], 1 <<
offset);
control->free--; // *WRONG, because map[index] did not change.*
rtems_rfs_buffer_mark_dirty (control->buffer); // UNNECESSARY, because
map[index] did not change.
On Thu, Oct 12, 2017 at 12:19 PM, Chris Johns wrote:
> On 12/10/17 11:46 am,
agree with my assertions in #2 above. Note the
name of "RTEMS_RFS_BITMAP_ELEMENT_SET" is slightly misleading. See my
points #5 for a clarification.
Thanks,
Fan
On Thu, Oct 12, 2017 at 10:35 AM, Chris Johns wrote:
> On 12/10/17 10:05 am, Fan Deng wrote:
> > Hi Chris,
> &g
_rfs_bitmap_map_index (bit);
> @@ -233,6 +235,7 @@ rtems_rfs_bitmap_map_clear (rtems_rfs_bitmap_control*
> control,
> search_map[index] = rtems_rfs_bitmap_clear (search_map[index], 1 <<
> offset);
> rtems_rfs_buffer_mark_dirty (control->buffer);
> control-&g
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 director
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_
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.
---
cpukit/lib
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, pl
