Yes the physical state can vary depending on the configuration of the RFS.
But that is not my point here.
Let's see an example:
Assuming
- set = physical 1, so RTEMS_RFS_BITMAP_ELEMENT_SET = UINT32_MAX
- map[index]=0b
1110
On 12/10/17 11:46 am, Fan Deng wrote:
> Thanks Chris!
>
> First of all let's make sure a few points are clarified:
>
> 1) What should rtems_rfs_bitmap_map_set(control, bit) do?
> - 'control' is a handle to the bitmap.
> - 'bit' is the offset of the bit to set in the bitmap. 'bit' should be in the
Thanks Chris!
First of all let's make sure a few points are clarified:
1) What should rtems_rfs_bitmap_map_set(control, bit) do?
- 'control' is a handle to the bitmap.
- 'bit' is the offset of the bit to set in the bitmap. 'bit' should be in
the range of [0, control->size - 1].
2) How does the b
On 12/10/17 10:05 am, Fan Deng wrote:
> Hi Chris,
>
Thanks for quick response.
> Based on my understanding, the patch in your email is different:
>
> 1) rtems_rfs_bitmap_map_set:
> By changing negating the if condition, the updated logic only modifies the
> element map[index] when the original
Hi Chris,
Based on my understanding, the patch in your email is different:
1) rtems_rfs_bitmap_map_set:
By changing negating the if condition, the updated logic only modifies the
element map[index] when the original value of map[index] is
RTEMS_RFS_BITMAP_ELEMENT_SET.
This is not quite right, as
Hi,
Many thanks for post the patches. The other patches look fine. I am wondering
is this is equivalent to what you have?
diff --git a/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
b/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
index 15a9050133..d14082691a 100644
--- a/cpukit/libfs/src/rfs/rtems-rfs-bit
