[PATCH v2 3/4] Add wpa_supplicant command in test suite.
Add wpa supplicant command in media01. --- testsuite/include/rtems/bsd/test/default-network-init.h | 3 ++- testsuite/media01/test_main.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/testsuite/include/rtems/bsd/test/default-network-init.h b/testsuite/include/rtems/bsd/test/default-network-init.h index 4d4e831..73c3944 100644 --- a/testsuite/include/rtems/bsd/test/default-network-init.h +++ b/testsuite/include/rtems/bsd/test/default-network-init.h @@ -367,7 +367,8 @@ Init(rtems_task_argument arg) &rtems_shell_TCPDUMP_Command, \ &rtems_shell_SYSCTL_Command, \ &rtems_shell_VMSTAT_Command, \ - &rtems_shell_WLANSTATS_Command + &rtems_shell_WLANSTATS_Command, \ + &rtems_shell_WPA_SUPPLICANT_Command #define CONFIGURE_SHELL_COMMAND_CPUUSE #define CONFIGURE_SHELL_COMMAND_PERIODUSE diff --git a/testsuite/media01/test_main.c b/testsuite/media01/test_main.c index b808ad6..f4aaea9 100644 --- a/testsuite/media01/test_main.c +++ b/testsuite/media01/test_main.c @@ -205,7 +205,8 @@ early_initialization(void) &rtems_shell_NETSTAT_Command, \ &rtems_shell_SYSCTL_Command, \ &rtems_shell_IFCONFIG_Command, \ - &rtems_shell_VMSTAT_Command + &rtems_shell_VMSTAT_Command, \ + &rtems_shell_WPA_SUPPLICANT_Command #define CONFIGURE_SHELL_COMMAND_CPUINFO #define CONFIGURE_SHELL_COMMAND_CPUUSE -- 2.7.4 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2 2/4] Port wpa supplicant to RTEMS.
Add wpa_supplicant lib support and shell command support in RTEMS.
---
builder.py | 1 +
freebsd/contrib/wpa/src/utils/os_unix.c| 11 +-
freebsd/contrib/wpa/wpa_supplicant/config.h| 3 +
freebsd/contrib/wpa/wpa_supplicant/main.c | 21 ++
libbsd.py | 286 +
libbsd_waf.py | 115 -
rtemsbsd/include/bsp/nexus-devices.h | 2 +
rtemsbsd/include/machine/rtems-bsd-commands.h | 2 +
.../include/machine/rtems-wpa_supplicant-mutex.h | 41 +++
rtemsbsd/include/rtems/netcmds-config.h| 2 +
rtemsbsd/rtems/rtems-bsd-shell-wpa_supplicant.c| 36 +++
rtemsbsd/rtems/rtems-wpa_supplicant_mutex.c| 47
12 files changed, 562 insertions(+), 5 deletions(-)
create mode 100644 rtemsbsd/include/machine/rtems-wpa_supplicant-mutex.h
create mode 100644 rtemsbsd/rtems/rtems-bsd-shell-wpa_supplicant.c
create mode 100644 rtemsbsd/rtems/rtems-wpa_supplicant_mutex.c
diff --git a/builder.py b/builder.py
index ae2e6ee..5124dc6 100755
--- a/builder.py
+++ b/builder.py
@@ -173,6 +173,7 @@ def includes():
return ['-Irtemsbsd/include',
'-Ifreebsd/sys',
'-Ifreebsd/sys/contrib/pf',
+'-Ifreebsd/crypto',
'-Ifreebsd/sys/net',
'-Ifreebsd/include',
'-Ifreebsd/lib',
diff --git a/freebsd/contrib/wpa/src/utils/os_unix.c
b/freebsd/contrib/wpa/src/utils/os_unix.c
index a3abce4..7f101d7 100644
--- a/freebsd/contrib/wpa/src/utils/os_unix.c
+++ b/freebsd/contrib/wpa/src/utils/os_unix.c
@@ -25,6 +25,11 @@
#include
#endif /* __MACH__ */
+#ifdef __rtems__
+#include
+#endif /* __rtems__ */
+
+
#include "os.h"
#include "common.h"
@@ -225,7 +230,7 @@ static int os_daemon(int nochdir, int noclose)
int os_daemonize(const char *pid_file)
{
-#if defined(__uClinux__) || defined(__sun__)
+#if defined(__uClinux__) || defined(__sun__) || defined(__rtems__)
return -1;
#else /* defined(__uClinux__) || defined(__sun__) */
#ifdef __FreeBSD__
@@ -282,6 +287,9 @@ int os_get_random(unsigned char *buf, size_t len)
if (TEST_FAIL())
return -1;
+#ifdef __rtems__
+ return getentropy(buf, len);
+#else /* __rtems__ */
f = fopen("/dev/urandom", "rb");
if (f == NULL) {
printf("Could not open /dev/urandom.\n");
@@ -292,6 +300,7 @@ int os_get_random(unsigned char *buf, size_t len)
fclose(f);
return rc != len ? -1 : 0;
+#endif /* __rtems__ */
}
diff --git a/freebsd/contrib/wpa/wpa_supplicant/config.h
b/freebsd/contrib/wpa/wpa_supplicant/config.h
index 627f38b..9de7e70 100644
--- a/freebsd/contrib/wpa/wpa_supplicant/config.h
+++ b/freebsd/contrib/wpa/wpa_supplicant/config.h
@@ -45,6 +45,9 @@
#include "common/ieee802_11_defs.h"
#include "common/ieee802_11_common.h"
+#ifdef __rtems__
+#include
+#endif /* __rtems__ */
struct wpa_cred {
/**
diff --git a/freebsd/contrib/wpa/wpa_supplicant/main.c
b/freebsd/contrib/wpa/wpa_supplicant/main.c
index 0e86b93..40950d2 100644
--- a/freebsd/contrib/wpa/wpa_supplicant/main.c
+++ b/freebsd/contrib/wpa/wpa_supplicant/main.c
@@ -19,6 +19,11 @@
#include "driver_i.h"
#include "p2p_supplicant.h"
+#ifdef __rtems__
+#include
+#include
+#include
+#endif /* __rtems__ */
static void usage(void)
{
@@ -154,6 +159,22 @@ static void wpa_supplicant_fd_workaround(int start)
#endif /* __linux__ */
}
+#ifdef __rtems__
+#include
+
+static int
+main(int argc, char **argv);
+
+int rtems_bsd_command_wpa_supplicant(int argc, char **argv)
+{
+ int exit_code;
+ rtems_status_code sc;
+
+ exit_code = rtems_bsd_program_call_main("wpa_supplicant", main, argc,
argv);
+
+ return exit_code;
+}
+#endif /* __rtems__ */
int main(int argc, char *argv[])
{
diff --git a/libbsd.py b/libbsd.py
index 471fb65..6cf10bf 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -3959,6 +3959,291 @@ def usr_sbin_tcpdump(mm):
return mod
#
+# /usr/sbin/wpa_supplicant
+#
+def usr_sbin_wpa_supplicant(mm):
+mod = builder.Module('usr_sbin_wpa_supplicant')
+mod.addUserSpaceHeaderFiles(
+[
+'contrib/wpa/wpa_supplicant/ap.h',
+'contrib/wpa/wpa_supplicant/blacklist.h',
+'contrib/wpa/wpa_supplicant/bss.h',
+'contrib/wpa/wpa_supplicant/config.h',
+'contrib/wpa/wpa_supplicant/config_ssid.h',
+'contrib/wpa/wpa_supplicant/ctrl_iface.h',
+'contrib/wpa/wpa_supplicant/driver_i.h',
+'contrib/wpa/wpa_supplicant/gas_query.h',
+'contrib/wpa/wpa_supplicant/hs20_supplicant.h',
+'contrib/wpa/wpa_supplicant/interworking.h',
+'contrib/wpa/wpa_supplicant/mesh.h',
+'contrib/wpa/wpa_supplicant/mesh_mpm.h',
+'contrib/wpa/wpa_supplicant/mesh_rsn.h',
+'contrib/wpa/wpa_suppl
[PATCH v2 4/4] Add wpa_supplicant_fork command.
Add fork command for wpa supplicant to start a new task.
---
freebsd/contrib/wpa/wpa_supplicant/main.c | 65 ++
libbsd.py | 1 +
libbsd_waf.py | 1 +
rtemsbsd/include/machine/rtems-bsd-commands.h | 2 +
rtemsbsd/include/rtems/netcmds-config.h| 2 +
.../rtems/rtems-bsd-shell-wpa_supplicant_fork.c| 36
testsuite/media01/test_main.c | 3 +-
7 files changed, 109 insertions(+), 1 deletion(-)
create mode 100644 rtemsbsd/rtems/rtems-bsd-shell-wpa_supplicant_fork.c
diff --git a/freebsd/contrib/wpa/wpa_supplicant/main.c
b/freebsd/contrib/wpa/wpa_supplicant/main.c
index 40950d2..23092a6 100644
--- a/freebsd/contrib/wpa/wpa_supplicant/main.c
+++ b/freebsd/contrib/wpa/wpa_supplicant/main.c
@@ -22,6 +22,8 @@
#ifdef __rtems__
#include
#include
+#define RTEMS_BSD_PROGRAM_NO_MALLOC_WRAP
+#define RTEMS_BSD_PROGRAM_NO_STRDUP_WRAP
#include
#endif /* __rtems__ */
@@ -174,6 +176,69 @@ int rtems_bsd_command_wpa_supplicant(int argc, char **argv)
return exit_code;
}
+
+struct myparams {
+ int argc;
+ char ** argv;
+};
+
+static void
+new_wpa_supplicant_task(rtems_task_argument arg)
+{
+ int argc;
+ char ** argv;
+ int i;
+
+ struct myparams *params = (struct myparams *)arg;
+ argc = params->argc;
+ argv = params->argv;
+
+ rtems_bsd_command_wpa_supplicant(argc, argv);
+
+ for (i = 0; i < params->argc; i++) {
+ free(params->argv[i]);
+ }
+ free(params->argv);
+ free(params);
+
+ rtems_task_delete( RTEMS_SELF );
+}
+
+int rtems_bsd_command_wpa_supplicant_fork(int argc, char **argv)
+{
+ rtems_status_code sc;
+ rtems_id id;
+ int i;
+
+ struct myparams *params = malloc(sizeof(struct myparams));
+ if (params == NULL)
+ return NULL;
+
+ params->argc = argc;
+ params->argv = malloc((argc + 1) * sizeof(argv[0]));
+ if (params->argv == NULL)
+ return NULL;
+
+ for (i = 0; i < argc; i++) {
+ params->argv[i] = strdup(argv[i]);
+ if (params->argv[i] == NULL)
+ return NULL;
+ }
+ params->argv[argc] = NULL;
+
+ sc = rtems_task_create(
+ rtems_build_name('W', 'P', 'A', 'S'),
+ RTEMS_MAXIMUM_PRIORITY - 1,
+ 8 * RTEMS_MINIMUM_STACK_SIZE,
+ RTEMS_DEFAULT_MODES,
+ RTEMS_FLOATING_POINT,
+ &id
+ );
+ assert(sc == RTEMS_SUCCESSFUL);
+
+ sc = rtems_task_start(id, new_wpa_supplicant_task, params);
+ assert(sc == RTEMS_SUCCESSFUL);
+}
#endif /* __rtems__ */
int main(int argc, char *argv[])
diff --git a/libbsd.py b/libbsd.py
index 6cf10bf..5ec2f91 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -4238,6 +4238,7 @@ def usr_sbin_wpa_supplicant(mm):
[
'rtems/rtems-bsd-shell-wpa_supplicant.c',
'rtems/rtems-wpa_supplicant_mutex.c',
+'rtems/rtems-bsd-shell-wpa_supplicant_fork.c',
],
mm.generator['source']()
)
diff --git a/libbsd_waf.py b/libbsd_waf.py
index 63a0f48..29405d3 100644
--- a/libbsd_waf.py
+++ b/libbsd_waf.py
@@ -2311,6 +2311,7 @@ def build(bld):
'rtemsbsd/rtems/rtems-bsd-shell-vmstat.c',
'rtemsbsd/rtems/rtems-bsd-shell-wlanstats.c',
'rtemsbsd/rtems/rtems-bsd-shell-wpa_supplicant.c',
+ 'rtemsbsd/rtems/rtems-bsd-shell-wpa_supplicant_fork.c',
'rtemsbsd/rtems/rtems-bsd-syscall-api.c',
'rtemsbsd/rtems/rtems-kernel-assert.c',
'rtemsbsd/rtems/rtems-kernel-autoconf.c',
diff --git a/rtemsbsd/include/machine/rtems-bsd-commands.h
b/rtemsbsd/include/machine/rtems-bsd-commands.h
index 03a09bc..32aba44 100644
--- a/rtemsbsd/include/machine/rtems-bsd-commands.h
+++ b/rtemsbsd/include/machine/rtems-bsd-commands.h
@@ -64,6 +64,8 @@ int rtems_bsd_command_dhcpcd(int argc, char **argv);
int rtems_bsd_command_wpa_supplicant(int argc, char **argv);
+int rtems_bsd_command_wpa_supplicant_fork(int argc, char **argv);
+
int rtems_bsd_command_tcpdump(int argc, char **argv);
int rtems_bsd_command_sysctl(int argc, char **argv);
diff --git a/rtemsbsd/include/rtems/netcmds-config.h
b/rtemsbsd/include/rtems/netcmds-config.h
index 046c859..4af4323 100644
--- a/rtemsbsd/include/rtems/netcmds-config.h
+++ b/rtemsbsd/include/rtems/netcmds-config.h
@@ -41,6 +41,8 @@ extern rtems_shell_cmd_t rtems_shell_TCPDUMP_Command;
extern rtems_shell_cmd_t rtems_shell_WPA_SUPPLICANT_Command;
+extern rtems_shell_cmd_t rtems_shell_WPA_SUPPLICANT_FORK_Command;
+
extern rtems_shell_cmd_t rtems_shell_SYSCTL_Command;
extern rtems_shell_cmd_t rtems_shell_VMSTAT_Command;
diff --git a/rtemsbsd/rtems/rtems-bsd-shell-wpa_supplicant_fork.c
b/rtemsbsd/rtems/rtems-bsd-shell-wpa_supplica
Re: RTEMS milestones 4.13 and 5.0?
On 11/10/17 11:30 pm, Sebastian Huber wrote: > > milestones 4.13 and 5.0 don't fit the new version scheme: > > https://devel.rtems.org/wiki/Developer/Release#RTEMSRelease5SeriesAndHigherNumbering > > > I suggest to rename the 5.0 milestone to 5.1 and move all 4.13 tickets to 5.1. > A change to the major revision number requires a major change. The reality is 4.12 should be 5.0. The release and what it contains has grown considerable and we are currently attempting to converge on stability across all hosts and architectures before we branch. Looking at 4.12 now it appears to me to be a good 5.0 candidate so should this happen or is it too late? We have planned the move to 5.0 to be a build system change. The work to make this important and needed change is not small and I cannot do it without funding and I do not have any for this work. Moving to 5.0 after 4.12 without something major may result in a long wait while planned 5.0 changes are implemented. As a result we will have smaller things hanging on the development branch that should be released as we have with 4.12 now. We added 4.13 as a way to keep us keep moving with releases while we figure out now to make the build system change. I do not like having 4.13 but I do not see another path. Jumping to 5.0 is a solution. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] bsp/atsam: Allow to change optimization settings.
On 12/10/17 12:00 am, Sebastian Huber wrote: > Module:rtems > Branch:master > Commit:16fcd56a42dfdef514350ab6297137e2c863afa1 > Changeset: > http://git.rtems.org/rtems/commit/?id=16fcd56a42dfdef514350ab6297137e2c863afa1 > > Author:Christian Mauderer > Date: Wed Oct 11 15:38:14 2017 +0200 > > bsp/atsam: Allow to change optimization settings. > > Allow to overwrite the optimization settings during configuration. > > --- > > c/src/lib/libbsp/arm/atsam/make/custom/atsamv.cfg | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/c/src/lib/libbsp/arm/atsam/make/custom/atsamv.cfg > b/c/src/lib/libbsp/arm/atsam/make/custom/atsamv.cfg > index 06892f9..0a2437f 100644 > --- a/c/src/lib/libbsp/arm/atsam/make/custom/atsamv.cfg > +++ b/c/src/lib/libbsp/arm/atsam/make/custom/atsamv.cfg > @@ -4,7 +4,6 @@ RTEMS_CPU = arm > > CPU_CFLAGS = -mthumb -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard > > -CFLAGS_OPTIMIZE_V = -O2 -g > -CFLAGS_OPTIMIZE_V += -ffunction-sections -fdata-sections > +CFLAGS_OPTIMIZE_V ?= -O2 -g -ffunction-sections -fdata-sections This is a really nice change. Should all the BSP's be changed? I see a 104 instances in the code and the change could be scripted. Being inconsistent on something that could be consistent across all BSPs is confusing to all users. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] bsp/atsam: Allow to change optimization settings.
Am 12.10.2017 um 18:06 schrieb Chris Johns: > On 12/10/17 12:00 am, Sebastian Huber wrote: >> Module:rtems >> Branch:master >> Commit:16fcd56a42dfdef514350ab6297137e2c863afa1 >> Changeset: >> http://git.rtems.org/rtems/commit/?id=16fcd56a42dfdef514350ab6297137e2c863afa1 >> >> Author:Christian Mauderer >> Date: Wed Oct 11 15:38:14 2017 +0200 >> >> bsp/atsam: Allow to change optimization settings. >> >> Allow to overwrite the optimization settings during configuration. >> >> --- >> >> c/src/lib/libbsp/arm/atsam/make/custom/atsamv.cfg | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/c/src/lib/libbsp/arm/atsam/make/custom/atsamv.cfg >> b/c/src/lib/libbsp/arm/atsam/make/custom/atsamv.cfg >> index 06892f9..0a2437f 100644 >> --- a/c/src/lib/libbsp/arm/atsam/make/custom/atsamv.cfg >> +++ b/c/src/lib/libbsp/arm/atsam/make/custom/atsamv.cfg >> @@ -4,7 +4,6 @@ RTEMS_CPU = arm >> >> CPU_CFLAGS = -mthumb -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard >> >> -CFLAGS_OPTIMIZE_V = -O2 -g >> -CFLAGS_OPTIMIZE_V += -ffunction-sections -fdata-sections >> +CFLAGS_OPTIMIZE_V ?= -O2 -g -ffunction-sections -fdata-sections > > > This is a really nice change. Should all the BSP's be changed? > > I see a 104 instances in the code and the change could be scripted. > > Being inconsistent on something that could be consistent across all BSPs is > confusing to all users. > > Chris > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > Hello Chris, the change is just similar to some other BSPs (like or1k or realview). If we want to offer something like that for all BSPs, it might would be a better idea to split the flags up (what I haven't done here). I think the -ffunction-sections -fdata-sections is allways necessary? Some BSPs have some other options too like an additional -fomit-frame-pointer in rbtx4925 or a -mmultiple in mcp750. So if a user would want to use that environment variable to change optimization, the value wouldn't be consistent across BSPs. A consistent solution could be to split it up like in or1k: CFLAGS_OPTIMIZE_V ?= -O0 -g CFLAGS_OPTIMIZE_V += -ffunction-sections -fdata-sections The general optimization could be overwritten with CFLAGS_OPTIMIZE_V and the BSP-specific parts would be added in the second line. What do you think? Kind regards Christian Mauderer ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Fixes bitmap allocation accounting logic in rtems-rfs-bitmaps.c
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-bitmaps.c
+++ b/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
@@ -196,9 +196,9 @@ rtems_rfs_bitmap_map_set (rtems_rfs_bitmap_control* control,
search_map = control->search_bits;
index = rtems_rfs_bitmap_map_index (bit);
offset = rtems_rfs_bitmap_map_offset (bit);
- map[index] = rtems_rfs_bitmap_set (map[index], 1 << offset);
- if (rtems_rfs_bitmap_match(map[index], RTEMS_RFS_BITMAP_ELEMENT_SET))
+ if (!rtems_rfs_bitmap_match(map[index], RTEMS_RFS_BITMAP_ELEMENT_SET))
{
+map[index] = rtems_rfs_bitmap_set (map[index], 1 << offset);
bit = index;
index = rtems_rfs_bitmap_map_index (bit);
offset = rtems_rfs_bitmap_map_offset (bit);
@@ -226,6 +226,8 @@ rtems_rfs_bitmap_map_clear (rtems_rfs_bitmap_control*
control,
search_map= control->search_bits;
index = rtems_rfs_bitmap_map_index (bit);
offset= rtems_rfs_bitmap_map_offset (bit);
+ if (rtems_rfs_bitmap_match(map[index], RTEMS_RFS_BITMAP_ELEMENT_SET))
+ {
map[index]= rtems_rfs_bitmap_clear (map[index], 1 << offset);
bit = index;
index = rtems_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->free++;
+ }
return 0;
}
Chris
On 10/10/17 4:28 pm, Fan Deng wrote:
> 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.
> ---
> cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c | 40
> +---
> 1 file changed, 26 insertions(+), 14 deletions(-)
>
> diff --git a/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
> b/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
> index 15a9050133..c0c6921db1 100644
> --- a/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
> +++ b/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
> @@ -183,11 +183,12 @@ int
> rtems_rfs_bitmap_map_set (rtems_rfs_bitmap_control* control,
>rtems_rfs_bitmap_bit bit)
> {
> - rtems_rfs_bitmap_map map;
> - rtems_rfs_bitmap_map search_map;
> - int index;
> - int offset;
> - int rc;
> + rtems_rfs_bitmap_map map;
> + rtems_rfs_bitmap_map search_map;
> + int index;
> + int offset;
> + int rc;
> + rtems_rfs_bitmap_element element;
>rc = rtems_rfs_bitmap_load_map (control, &map);
>if (rc > 0)
> return rc;
> @@ -196,15 +197,20 @@ rtems_rfs_bitmap_map_set (rtems_rfs_bitmap_control*
> control,
>search_map = control->search_bits;
>index = rtems_rfs_bitmap_map_index (bit);
>offset = rtems_rfs_bitmap_map_offset (bit);
> - map[index] = rtems_rfs_bitmap_set (map[index], 1 << offset);
> + element= map[index];
> + map[index] = rtems_rfs_bitmap_set (element, 1 << offset);
> + // If the element does not change, the bit was already set. There will be
> no
> + // further action to take.
> + if (rtems_rfs_bitmap_match(element, map[index]))
> + return 0;
> + control->free--;
> + rtems_rfs_buffer_mark_dirty (control->buffer);
>if (rtems_rfs_bitmap_match(map[index], RTEMS_RFS_BITMAP_ELEMENT_SET))
>{
> bit = index;
> index = rtems_rfs_bitmap_map_index (bit);
> offset = rtems_rfs_bitmap_map_offset (bit);
> search_map[index] = rtems_rfs_bitmap_set (search_map[index], 1 <<
> offset);
> -control->free--;
> -rtems_rfs_buffer_mark_dirty (control->buffer);
>}
>return 0;
> }
> @@ -213,11 +219,12 @@ int
> rtems_rfs_bitmap_map_clear (rtems_rfs_bitmap_control* control,
> rtems_rfs_bitmap_bit bit)
> {
> - rtems_rfs_bitmap_map map;
> - rtems_rfs_bitmap_map search_map;
> - int index;
> - int offset;
> - int rc;
> + rtems_rfs_bitmap_map map;
> + rtems_rfs_bitmap_map search_map;
> + int index;
> + int offset;
> + int rc;
> + rtems_rfs_bitmap_el
Re: [PATCH] Fixes bitmap allocation accounting logic in rtems-rfs-bitmaps.c
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 we are explicitly updating the 'offset' bit in
map[index]. That bit should be updated regardless.
2) rtems_rfs_bitmap_map_clear:
Same problem, whether we modify map[index] should not depend on if
map[index] == RTEMS_RFS_BITMAP_ELEMENT_SET.
I believe my patch corrects the logic flaw and is the right fix. Please let
me know if you have any further questions, and I will be happy to explain
in detail.
Thanks,
Fan
On Thu, Oct 12, 2017 at 9:48 AM, Chris Johns wrote:
> 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-bitmaps.c
> +++ b/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
> @@ -196,9 +196,9 @@ rtems_rfs_bitmap_map_set (rtems_rfs_bitmap_control*
> control,
>search_map = control->search_bits;
>index = rtems_rfs_bitmap_map_index (bit);
>offset = rtems_rfs_bitmap_map_offset (bit);
> - map[index] = rtems_rfs_bitmap_set (map[index], 1 << offset);
> - if (rtems_rfs_bitmap_match(map[index], RTEMS_RFS_BITMAP_ELEMENT_SET))
> + if (!rtems_rfs_bitmap_match(map[index], RTEMS_RFS_BITMAP_ELEMENT_SET))
>{
> +map[index] = rtems_rfs_bitmap_set (map[index], 1 << offset);
> bit = index;
> index = rtems_rfs_bitmap_map_index (bit);
> offset = rtems_rfs_bitmap_map_offset (bit);
> @@ -226,6 +226,8 @@ rtems_rfs_bitmap_map_clear (rtems_rfs_bitmap_control*
> control,
>search_map= control->search_bits;
>index = rtems_rfs_bitmap_map_index (bit);
>offset= rtems_rfs_bitmap_map_offset (bit);
> + if (rtems_rfs_bitmap_match(map[index], RTEMS_RFS_BITMAP_ELEMENT_SET))
> + {
> map[index]= rtems_rfs_bitmap_clear (map[index], 1 << offset);
> bit = index;
> index = rtems_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->free++;
> + }
>return 0;
> }
>
> Chris
>
> On 10/10/17 4:28 pm, Fan Deng wrote:
> > 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.
> > ---
> > cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c | 40
> +---
> > 1 file changed, 26 insertions(+), 14 deletions(-)
> >
> > diff --git a/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
> b/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
> > index 15a9050133..c0c6921db1 100644
> > --- a/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
> > +++ b/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
> > @@ -183,11 +183,12 @@ int
> > rtems_rfs_bitmap_map_set (rtems_rfs_bitmap_control* control,
> >rtems_rfs_bitmap_bit bit)
> > {
> > - rtems_rfs_bitmap_map map;
> > - rtems_rfs_bitmap_map search_map;
> > - int index;
> > - int offset;
> > - int rc;
> > + rtems_rfs_bitmap_map map;
> > + rtems_rfs_bitmap_map search_map;
> > + int index;
> > + int offset;
> > + int rc;
> > + rtems_rfs_bitmap_element element;
> >rc = rtems_rfs_bitmap_load_map (control, &map);
> >if (rc > 0)
> > return rc;
> > @@ -196,15 +197,20 @@ rtems_rfs_bitmap_map_set
> (rtems_rfs_bitmap_control* control,
> >search_map = control->search_bits;
> >index = rtems_rfs_bitmap_map_index (bit);
> >offset = rtems_rfs_bitmap_map_offset (bit);
> > - map[index] = rtems_rfs_bitmap_set (map[index], 1 << offset);
> > + element= map[index];
> > + map[index] = rtems_rfs_bitmap_set (element, 1 << offset);
> > + // If the element does not change, the bit was already set. There
> will be no
> > + // further action to take.
> > + if (rtems_rfs_bitmap_match(element, map[index]))
> > + return 0;
> > + control->free--;
> > + rtems_rfs_buffer_mark_d
Re: [PATCH] Fixes bitmap allocation accounting logic in rtems-rfs-bitmaps.c
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 value of map[index] is
> RTEMS_RFS_BITMAP_ELEMENT_SET.
Your change has:
- map[index] = rtems_rfs_bitmap_set (map[index], 1 << offset);
+ element= map[index];
+ map[index] = rtems_rfs_bitmap_set (element, 1 << offset);
+ // If the element does not change, the bit was already set. There will be no
+ // further action to take.
+ if (rtems_rfs_bitmap_match(element, map[index]))
+ return 0;
The change gets a copy of the uint32_t value from the map and then updates the
map setting the bit. The change then checks to see if the original bit in the
map is set (match returns true) and if set you exit the function. I see this
being the same as the code in my patch where I only proceed to do anything if
the bit is not set in the map:
- map[index] = rtems_rfs_bitmap_set (map[index], 1 << offset);
- if (rtems_rfs_bitmap_match(map[index], RTEMS_RFS_BITMAP_ELEMENT_SET))
+ if (!rtems_rfs_bitmap_match(map[index], RTEMS_RFS_BITMAP_ELEMENT_SET))
{
If the bit is not set you enter the code to handle a map bit being set. You
have:
+ control->free--;
+ rtems_rfs_buffer_mark_dirty (control->buffer);
if (rtems_rfs_bitmap_match(map[index], RTEMS_RFS_BITMAP_ELEMENT_SET))
{
Given you have set the `map[index]` earlier the if test will always pass and I
suspect the compiler will know this and dead code eliminate it.
> This is not quite right, as we are explicitly updating the 'offset' bit in
> map[index]. That bit should be updated regardless.
Why update the bit if it is already set? I seem to be missing something here.
The map is just an array of 32bit unsigned ints.
>
> 2) rtems_rfs_bitmap_map_clear:
> Same problem, whether we modify map[index] should not depend on if map[index]
> ==
> RTEMS_RFS_BITMAP_ELEMENT_SET.
Sure, once we agree on the set the clear should fall out of it.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] bsp/atsam: Allow to change optimization settings.
On 12/10/17 9:36 am, Christian Mauderer wrote: > Am 12.10.2017 um 18:06 schrieb Chris Johns: >> On 12/10/17 12:00 am, Sebastian Huber wrote: >>> @@ -4,7 +4,6 @@ RTEMS_CPU = arm >>> >>> CPU_CFLAGS = -mthumb -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard >>> >>> -CFLAGS_OPTIMIZE_V = -O2 -g >>> -CFLAGS_OPTIMIZE_V += -ffunction-sections -fdata-sections >>> +CFLAGS_OPTIMIZE_V ?= -O2 -g -ffunction-sections -fdata-sections >> >> >> This is a really nice change. Should all the BSP's be changed? >> >> I see a 104 instances in the code and the change could be scripted. >> >> Being inconsistent on something that could be consistent across all BSPs is >> confusing to all users. >> > > the change is just similar to some other BSPs (like or1k or realview). > It is a great idea and I think useful for all users of RTEMS. > If we want to offer something like that for all BSPs, it might would be > a better idea to split the flags up (what I haven't done here). Yes it might pay to split them up. > I think the -ffunction-sections -fdata-sections is allways necessary? I am not sure which archs can use the function and data sections. It is the `?=` I like. > Some BSPs > have some other options too like an additional -fomit-frame-pointer in > rbtx4925 or a -mmultiple in mcp750. So if a user would want to use that > environment variable to change optimization, the value wouldn't be > consistent across BSPs. Ah ok. > > A consistent solution could be to split it up like in or1k: > > CFLAGS_OPTIMIZE_V ?= -O0 -g > CFLAGS_OPTIMIZE_V += -ffunction-sections -fdata-sections > > The general optimization could be overwritten with CFLAGS_OPTIMIZE_V and > the BSP-specific parts would be added in the second line. > > What do you think? > The or1k solution looks good. What if we did something like: CFLAGS_OPTIMIZE_V ?= -O0 CFLAGS_DEBUG_V ?= -g CFLAGS_OPTIMIZE_V += $(CFLAGS_DEBUG_V) -ffunction-sections -fdata-sections Is that too much? It would make documenting what this does simpler. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] Return invalid mode for !preempt and interrupt disable modes when SMP
This impacts rtems_task_mode() and rtems_task_create().
updates #3000.
---
c/src/ada/rtems.ads | 3 ++-
cpukit/rtems/include/rtems/rtems/status.h | 10 --
cpukit/rtems/src/statustext.c | 1 +
cpukit/rtems/src/taskcreate.c | 19 ---
cpukit/rtems/src/taskmode.c | 19 +--
testsuites/smptests/smpunsupported01/init.c | 6 +++---
6 files changed, 43 insertions(+), 15 deletions(-)
diff --git a/c/src/ada/rtems.ads b/c/src/ada/rtems.ads
index 2b59c74..cd23185 100644
--- a/c/src/ada/rtems.ads
+++ b/c/src/ada/rtems.ads
@@ -10,7 +10,7 @@
--RTEMS initialization and configuration are called from
--the BSP side, therefore should never be called from ADA.
--
--- COPYRIGHT (c) 1997-2011.
+-- COPYRIGHT (c) 1997-2011, 2017.
-- On-Line Applications Research Corporation (OAR).
--
-- The license and distribution terms for this file may in
@@ -351,6 +351,7 @@ pragma Elaborate_Body (RTEMS);
Internal_Error, -- RTEMS inconsistency detected
No_Memory,-- no memory left in heap
IO_Error, -- driver IO error
+ Invalid_Mode, -- invalid mode for RTEMS configuration
Proxy_Blocking-- internal multiprocessing only
);
diff --git a/cpukit/rtems/include/rtems/rtems/status.h
b/cpukit/rtems/include/rtems/rtems/status.h
index c54404b..ede43cc 100644
--- a/cpukit/rtems/include/rtems/rtems/status.h
+++ b/cpukit/rtems/include/rtems/rtems/status.h
@@ -10,7 +10,7 @@
* executive directives.
*/
-/* COPYRIGHT (c) 1989-2013.
+/* COPYRIGHT (c) 1989-2017.
* On-Line Applications Research Corporation (OAR).
*
* The license and distribution terms for this file may be
@@ -170,6 +170,12 @@ typedef enum {
*/
RTEMS_IO_ERROR = 27,
/**
+ * This is the status to indicate an invalid mode was specified.
+ * This can occur when using a mode that is not supported in
+ * the current RTEMS functional configuration.
+ */
+ RTEMS_INVALID_MODE = 28,
+ /**
* This is the status is used internally to RTEMS when performing
* operations on behalf of remote tasks. This is referred to as
* proxying operations and this status indicates that the operation
@@ -177,7 +183,7 @@ typedef enum {
*
* @note This status will @b NOT be returned to the user.
*/
- RTEMS_PROXY_BLOCKING = 28
+ RTEMS_PROXY_BLOCKING = 29
} rtems_status_code;
/**
diff --git a/cpukit/rtems/src/statustext.c b/cpukit/rtems/src/statustext.c
index f701ebd..f2af24f 100644
--- a/cpukit/rtems/src/statustext.c
+++ b/cpukit/rtems/src/statustext.c
@@ -53,6 +53,7 @@ static const char *const status_code_text[] = {
"RTEMS_INTERNAL_ERROR",
"RTEMS_NO_MEMORY",
"RTEMS_IO_ERROR",
+ "RTEMS_INVALID_MODE",
"RTEMS_PROXY_BLOCKING"
};
diff --git a/cpukit/rtems/src/taskcreate.c b/cpukit/rtems/src/taskcreate.c
index 2695382..7a68c6f 100644
--- a/cpukit/rtems/src/taskcreate.c
+++ b/cpukit/rtems/src/taskcreate.c
@@ -6,7 +6,7 @@
*/
/*
- * COPYRIGHT (c) 1989-2014,2016.
+ * COPYRIGHT (c) 1989-2014,2016,2017.
* On-Line Applications Research Corporation (OAR).
*
* The license and distribution terms for this file may be
@@ -50,15 +50,28 @@ rtems_status_code rtems_task_create(
RTEMS_API_Control *api;
ASR_Information *asr;
-
if ( !id )
return RTEMS_INVALID_ADDRESS;
if ( !rtems_is_name_valid( name ) )
return RTEMS_INVALID_NAME;
+#if defined(RTEMS_SMP)
+ /*
+ * Per task preemption and interrupt disable are unsafe and not
+ * supported on SMP configurations.
+ */
+ if ( rtems_configuration_is_smp_enabled() ) {
+if ( !_Modes_Is_preempt(initial_modes) )
+ return RTEMS_INVALID_MODE;
+
+if ( _Modes_Get_interrupt_level(initial_modes) != 0 )
+ return RTEMS_INVALID_MODE;
+ }
+#endif
+
/*
- * Core Thread Initialize insures we get the minimum amount of
+ * Core Thread Initialize ensures we get the minimum amount of
* stack space.
*/
diff --git a/cpukit/rtems/src/taskmode.c b/cpukit/rtems/src/taskmode.c
index a345409..d26fdc2 100644
--- a/cpukit/rtems/src/taskmode.c
+++ b/cpukit/rtems/src/taskmode.c
@@ -6,7 +6,7 @@
*/
/*
- * COPYRIGHT (c) 1989-2014.
+ * COPYRIGHT (c) 1989-2014,2017.
* On-Line Applications Research Corporation (OAR).
*
* The license and distribution terms for this file may be
@@ -64,10 +64,10 @@ rtems_status_code rtems_task_mode(
*/
preempt_enabled = false;
if ( mask & RTEMS_PREEMPT_MASK ) {
-#if defined( RTEMS_SMP )
-if ( rtems_configuration_is_smp_enabled() &&
- !_Modes_Is_preempt( mode_set ) ) {
- return RTEMS_NOT_IMPLEMENTED;
+#if defined(RTEMS_SMP)
+if ( rtems_configuration_is_smp_enabled() ) {
+ if ( !_Modes_Is_preempt( mode_set ) )
+return RTEMS_INVALID_MODE;
}
#endif
bool is_preempt_enabled = _Modes_Is_pre
[PATCH] Return invalid mode for !preempt and interrupt disable modes when SMP
This impacts rtems_task_mode() and rtems_task_create(). Closes #3000. --- c-user/directive_status_codes.rst | 4 c-user/task_manager.rst | 8 2 files changed, 12 insertions(+) diff --git a/c-user/directive_status_codes.rst b/c-user/directive_status_codes.rst index 420a0a0..a08ad1d 100644 --- a/c-user/directive_status_codes.rst +++ b/c-user/directive_status_codes.rst @@ -75,6 +75,10 @@ The directives are: - RTEMS inconsistency detected * - ``RTEMS_NO_MEMORY`` - could not get enough memory + * - ``RTEMS_IO_ERROR`` + - a driver error occurred + * - ``RTEMS_INVALID_MODE`` + - attempted to set a task mode that is unavailable in SMP configurations .. raw:: latex diff --git a/c-user/task_manager.rst b/c-user/task_manager.rst index 426a91f..e52ab74 100644 --- a/c-user/task_manager.rst +++ b/c-user/task_manager.rst @@ -618,6 +618,10 @@ DIRECTIVE STATUS CODES: - ``id`` is NULL * - ``RTEMS_INVALID_NAME`` - invalid task name + * - ``RTEMS_INVALID_MODE`` +- non-preemption mode not available in SMP configurations + * - ``RTEMS_INVALID_MODE`` +- interrupt disable portion of mode not available in SMP configurations * - ``RTEMS_INVALID_PRIORITY`` - invalid task priority * - ``RTEMS_MP_NOT_CONFIGURED`` @@ -1256,6 +1260,10 @@ DIRECTIVE STATUS CODES: * - ``RTEMS_SUCCESSFUL`` - task mode set successfully + * - ``RTEMS_INVALID_MODE`` +- non-preemption mode not available in SMP configurations + * - ``RTEMS_INVALID_MODE`` +- interrupt disable portion of mode not available in SMP configurations * - ``RTEMS_INVALID_ADDRESS`` - ``previous_mode_set`` is NULL -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Fixes bitmap allocation accounting logic in rtems-rfs-bitmaps.c
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 bitmap store bits?
By storing bits in an array of rtems_rfs_bitmap_element objects.
Each rtems_rfs_bitmap_element is 32bit. So the number of elements is
control->size / 32.
3) What is map[index]?
'index' is calculated as 'bit / 32' and is the offset into the block buffer
of the element that contains the 'bit'. So map[index] is the value of the
element that contains the 'bit'.
4) What is 'offset'?
'offset' is calculated as 'bit % 32'. It locates the 'bit' in the element
that contains it.
5) What is RTEMS_RFS_BITMAP_ELEMENT_SET
This is a constant. If map[index] == RTEMS_RFS_BITMAP_ELEMENT_SET, all bits
in this element (map[index]) are set. It is used to check that condition
and *update the search map*.
Now let's see what your change does:
- map[index] = rtems_rfs_bitmap_set (map[index], 1 << offset);
- if (rtems_rfs_bitmap_match(map[index], RTEMS_RFS_BITMAP_ELEMENT_SET))
+ if (!rtems_rfs_bitmap_match(map[index], RTEMS_RFS_BITMAP_ELEMENT_SET))
{
Your change:
1. First updates map[index] to set the bit.
2. Compares the updated map[index] with RTEMS_RFS_BITMAP_ELEMENT_SET. Note
this:
- *DOES NOT* check whether the original bit was set.
- *DOES NOT* have a way to check if the bit was previously set, as
map[index] has already been overwritten.
- *DOES* check whether all bits in map[index] are set.
Please let me know if you 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,
> >
>
> 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 value of map[index] is
> > RTEMS_RFS_BITMAP_ELEMENT_SET.
>
> Your change has:
>
> - map[index] = rtems_rfs_bitmap_set (map[index], 1 << offset);
> + element= map[index];
> + map[index] = rtems_rfs_bitmap_set (element, 1 << offset);
> + // If the element does not change, the bit was already set. There will
> be no
> + // further action to take.
> + if (rtems_rfs_bitmap_match(element, map[index]))
> + return 0;
>
> The change gets a copy of the uint32_t value from the map and then updates
> the
> map setting the bit. The change then checks to see if the original bit in
> the
> map is set (match returns true) and if set you exit the function. I see
> this
> being the same as the code in my patch where I only proceed to do anything
> if
> the bit is not set in the map:
>
> - map[index] = rtems_rfs_bitmap_set (map[index], 1 << offset);
> - if (rtems_rfs_bitmap_match(map[index], RTEMS_RFS_BITMAP_ELEMENT_SET))
> + if (!rtems_rfs_bitmap_match(map[index], RTEMS_RFS_BITMAP_ELEMENT_SET))
> {
>
> If the bit is not set you enter the code to handle a map bit being set.
> You have:
>
> + control->free--;
> + rtems_rfs_buffer_mark_dirty (control->buffer);
> if (rtems_rfs_bitmap_match(map[index], RTEMS_RFS_BITMAP_ELEMENT_SET))
> {
>
> Given you have set the `map[index]` earlier the if test will always pass
> and I
> suspect the compiler will know this and dead code eliminate it.
>
> > This is not quite right, as we are explicitly updating the 'offset' bit
> in
> > map[index]. That bit should be updated regardless.
>
> Why update the bit if it is already set? I seem to be missing something
> here.
> The map is just an array of 32bit unsigned ints.
>
> >
> > 2) rtems_rfs_bitmap_map_clear:
> > Same problem, whether we modify map[index] should not depend on if
> map[index] ==
> > RTEMS_RFS_BITMAP_ELEMENT_SET.
>
> Sure, once we agree on the set the clear should fall out of it.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Fixes bitmap allocation accounting logic in rtems-rfs-bitmaps.c
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
> range of [0, control->size - 1].
>
> 2) How does the bitmap store bits?
> By storing bits in an array of rtems_rfs_bitmap_element objects.
> Each rtems_rfs_bitmap_element is 32bit. So the number of elements is
> control->size / 32.
>
> 3) What is map[index]?
> 'index' is calculated as 'bit / 32' and is the offset into the block buffer of
> the element that contains the 'bit'. So map[index] is the value of the element
> that contains the 'bit'.
>
> 4) What is 'offset'?
> 'offset' is calculated as 'bit % 32'. It locates the 'bit' in the element that
> contains it.
>
> 5) What is RTEMS_RFS_BITMAP_ELEMENT_SET
> This is a constant. If map[index] == RTEMS_RFS_BITMAP_ELEMENT_SET, all bits in
> this element (map[index]) are set. It is used to check that condition and
> _update the search map_.
Yes the match is doing something like this. The actual match is made more
complicated because the physical state of a set bit can be controlled.
> Now let's see what your change does:
>
> - map[index] = rtems_rfs_bitmap_set (map[index], 1 << offset);
> - if (rtems_rfs_bitmap_match(map[index], RTEMS_RFS_BITMAP_ELEMENT_SET))
> + if (!rtems_rfs_bitmap_match(map[index], RTEMS_RFS_BITMAP_ELEMENT_SET))
> {
>
> Your change:
> 1. First updates map[index] to set the bit.
I moved the set which is a bug in the code in master in my patch I posed. I did
not paste that bit to the next post, I am sorry about that. Here is the fragment
with the moved set included:
- map[index] = rtems_rfs_bitmap_set (map[index], 1 << offset);
- if (rtems_rfs_bitmap_match(map[index], RTEMS_RFS_BITMAP_ELEMENT_SET))
+ if (!rtems_rfs_bitmap_match(map[index], RTEMS_RFS_BITMAP_ELEMENT_SET))
{
+map[index] = rtems_rfs_bitmap_set (map[index], 1 << offset);
> 2. Compares the updated map[index] with RTEMS_RFS_BITMAP_ELEMENT_SET. Note
> this:
> - *DOES NOT* check whether the original bit was set.
It does because the set was moved.
> - *DOES NOT* have a way to check if the bit was previously set, as
> map[index] has already been overwritten.
> - *DOES* check whether all bits in map[index] are set.
>
> Please let me know if you 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.
As above the set state of a bit can be a physical 0 or 1 depending on the build
configuration of the RFS.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Fixes bitmap allocation accounting logic in rtems-rfs-bitmaps.c
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 (only the bit at offset=0 is clear)
- calling rtems_rfs_bitmap_map_set with the bit: index=0 offset=1
In rtems_rfs_bitmap_map_set()
- The if condition rtems_rfs_bitmap_match(map[index],
RTEMS_RFS_BITMAP_ELEMENT_SET) is *false*
- the following if body executes:
map[index] = rtems_rfs_bitmap_set (map[index], 1 << offset); //
map[index] *remains the same* because the bit at offset=1 was set before
the call.
bit = index;
index = rtems_rfs_bitmap_map_index (bit);
offset = rtems_rfs_bitmap_map_offset (bit);
search_map[index] = rtems_rfs_bitmap_set (search_map[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, 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
> > range of [0, control->size - 1].
> >
> > 2) How does the bitmap store bits?
> > By storing bits in an array of rtems_rfs_bitmap_element objects.
> > Each rtems_rfs_bitmap_element is 32bit. So the number of elements is
> > control->size / 32.
> >
> > 3) What is map[index]?
> > 'index' is calculated as 'bit / 32' and is the offset into the block
> buffer of
> > the element that contains the 'bit'. So map[index] is the value of the
> element
> > that contains the 'bit'.
> >
> > 4) What is 'offset'?
> > 'offset' is calculated as 'bit % 32'. It locates the 'bit' in the
> element that
> > contains it.
> >
> > 5) What is RTEMS_RFS_BITMAP_ELEMENT_SET
> > This is a constant. If map[index] == RTEMS_RFS_BITMAP_ELEMENT_SET, all
> bits in
> > this element (map[index]) are set. It is used to check that condition and
> > _update the search map_.
>
> Yes the match is doing something like this. The actual match is made more
> complicated because the physical state of a set bit can be controlled.
>
> > Now let's see what your change does:
> >
> > - map[index] = rtems_rfs_bitmap_set (map[index], 1 << offset);
> > - if (rtems_rfs_bitmap_match(map[index],
> RTEMS_RFS_BITMAP_ELEMENT_SET))
> > + if (!rtems_rfs_bitmap_match(map[index],
> RTEMS_RFS_BITMAP_ELEMENT_SET))
> > {
> >
> > Your change:
> > 1. First updates map[index] to set the bit.
>
> I moved the set which is a bug in the code in master in my patch I posed.
> I did
> not paste that bit to the next post, I am sorry about that. Here is the
> fragment
> with the moved set included:
>
> - map[index] = rtems_rfs_bitmap_set (map[index], 1 << offset);
> - if (rtems_rfs_bitmap_match(map[index], RTEMS_RFS_BITMAP_ELEMENT_SET))
> + if (!rtems_rfs_bitmap_match(map[index], RTEMS_RFS_BITMAP_ELEMENT_SET))
>{
> +map[index] = rtems_rfs_bitmap_set (map[index], 1 << offset);
>
> > 2. Compares the updated map[index] with RTEMS_RFS_BITMAP_ELEMENT_SET.
> Note this:
> > - *DOES NOT* check whether the original bit was set.
>
> It does because the set was moved.
>
> > - *DOES NOT* have a way to check if the bit was previously set, as
> > map[index] has already been overwritten.
> > - *DOES* check whether all bits in map[index] are set.
> >
> > Please let me know if you 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.
>
> As above the set state of a bit can be a physical 0 or 1 depending on the
> build
> configuration of the RFS.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Google Code-In Mentors Needed
Hi For RTEMS to participate in Google Code-In, we will need mentors. Being a GCI mentor is different from being a GSoC or SOCIS mentor. The tasks are not large like the summer projects in those programs. They are small tasks which any RTEMS user or developer (including GSoC students) can provide guidance and review. Tasks are geared to take from hours to a few days. An example repeatable task is doing the hello world. Any number of GCI students can do that. Other tasks could include adding Doxygen headers or formatting manuals. The mentoring is on demand and you can pitch in for just part of the program. Help is needed and appreciated. Ask questions on list if you have them. Thanks. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] psxclockrealtime01: New test
Update #3182.
---
testsuites/psxtests/Makefile.am| 1 +
testsuites/psxtests/configure.ac | 1 +
testsuites/psxtests/psxclockrealtime01/Makefile.am | 19 ++
testsuites/psxtests/psxclockrealtime01/init.c | 304 +
.../psxclockrealtime01/psxclockrealtime01.doc | 16 ++
.../psxclockrealtime01/psxclockrealtime01.scn | 2 +
6 files changed, 343 insertions(+)
create mode 100644 testsuites/psxtests/psxclockrealtime01/Makefile.am
create mode 100644 testsuites/psxtests/psxclockrealtime01/init.c
create mode 100644
testsuites/psxtests/psxclockrealtime01/psxclockrealtime01.doc
create mode 100644
testsuites/psxtests/psxclockrealtime01/psxclockrealtime01.scn
diff --git a/testsuites/psxtests/Makefile.am b/testsuites/psxtests/Makefile.am
index cccdb39118..2a74470d60 100644
--- a/testsuites/psxtests/Makefile.am
+++ b/testsuites/psxtests/Makefile.am
@@ -36,6 +36,7 @@ endif
_SUBDIRS += psxclock
if HAS_POSIX
_SUBDIRS += psxclock01
+_SUBDIRS += psxclockrealtime01
_SUBDIRS += psxconcurrency01
_SUBDIRS += psxcond01
_SUBDIRS += psxcond02
diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/configure.ac
index 96a0149302..7243bfdbb5 100644
--- a/testsuites/psxtests/configure.ac
+++ b/testsuites/psxtests/configure.ac
@@ -140,6 +140,7 @@ psxcleanup01/Makefile
psxcleanup02/Makefile
psxclock/Makefile
psxclock01/Makefile
+psxclockrealtime01/Makefile
psxconcurrency01/Makefile
psxcond01/Makefile
psxcond02/Makefile
diff --git a/testsuites/psxtests/psxclockrealtime01/Makefile.am
b/testsuites/psxtests/psxclockrealtime01/Makefile.am
new file mode 100644
index 00..d0b1a76dbe
--- /dev/null
+++ b/testsuites/psxtests/psxclockrealtime01/Makefile.am
@@ -0,0 +1,19 @@
+rtems_tests_PROGRAMS = psxclockrealtime01
+psxclockrealtime01_SOURCES = init.c
+
+dist_rtems_tests_DATA = psxclockrealtime01.scn psxclockrealtime01.doc
+
+include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg
+include $(top_srcdir)/../automake/compile.am
+include $(top_srcdir)/../automake/leaf.am
+
+AM_CPPFLAGS += -I$(top_srcdir)/../support/include
+
+LINK_OBJS = $(psxclockrealtime01_OBJECTS)
+LINK_LIBS = $(psxclockrealtime01_LDLIBS)
+
+psxclockrealtime01$(EXEEXT): $(psxclockrealtime01_OBJECTS)
$(psxclockrealtime01_DEPENDENCIES)
+ @rm -f psxclockrealtime01$(EXEEXT)
+ $(make-exe)
+
+include $(top_srcdir)/../automake/local.am
diff --git a/testsuites/psxtests/psxclockrealtime01/init.c
b/testsuites/psxtests/psxclockrealtime01/init.c
new file mode 100644
index 00..f5a05056a7
--- /dev/null
+++ b/testsuites/psxtests/psxclockrealtime01/init.c
@@ -0,0 +1,304 @@
+/*
+ * Copyright (c) 2017 embedded brains GmbH. All rights reserved.
+ *
+ * embedded brains GmbH
+ * Dornierstr. 4
+ * 82178 Puchheim
+ * Germany
+ *
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.com/license/LICENSE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef __rtems__
+#include "tmacros.h"
+#else /* __rtems__ */
+#include
+#define rtems_test_assert(x) assert(x)
+#endif /* __rtems__ */
+
+const char rtems_test_name[] = "PSXCLOCKREALTIME 1";
+
+typedef struct {
+ int value;
+ pthread_mutex_t mtx;
+ pthread_cond_t cnd;
+} event;
+
+typedef enum {
+ ACTION_NONE,
+ ACTION_MTX_LOCK,
+ ACTION_CND_WAIT,
+ ACTION_RW_RDLOCK,
+ ACTION_RW_WRLOCK,
+ ACTION_SEM_WAIT,
+ ACTION_TERMINATE
+} test_action;
+
+typedef struct {
+ pthread_t worker;
+ event action;
+ event done;
+ pthread_mutex_t mtx;
+ pthread_mutex_t mtx2;
+ pthread_cond_t cnd;
+ pthread_rwlock_t rw;
+ sem_t sem;
+ int counter[ACTION_TERMINATE + 1];
+} test_context;
+
+static test_context test_instance;
+
+static void event_init(event *e)
+{
+ int eno;
+
+ eno = pthread_mutex_init(&e->mtx, NULL);
+ rtems_test_assert(eno == 0);
+
+ eno = pthread_cond_init(&e->cnd, NULL);
+ rtems_test_assert(eno == 0);
+}
+
+static void event_destroy(event *e)
+{
+ int eno;
+
+ eno = pthread_mutex_destroy(&e->mtx);
+ rtems_test_assert(eno == 0);
+
+ eno = pthread_cond_destroy(&e->cnd);
+ rtems_test_assert(eno == 0);
+}
+
+static void event_post(event *e, int value)
+{
+ int eno;
+
+ eno = pthread_mutex_lock(&e->mtx);
+ rtems_test_assert(eno == 0);
+
+ e->value = value;
+
+ eno = pthread_cond_signal(&e->cnd);
+ rtems_test_assert(eno == 0);
+
+ eno = pthread_mutex_unlock(&e->mtx);
+ rtems_test_assert(eno == 0);
+}
+
+static int event_get(event *e)
+{
+ int eno;
+ int value;
+
+ eno = pthread_mutex_lock(&e->mtx);
+ rtems_test_assert(eno == 0);
+
+ while (true) {
+value = e->value;
+
+if (value != 0) {
+ e->value = 0;
+ break;
+}
+
+eno = pthread_cond_wait(&e->cnd, &e->mtx);
+rtems_test_assert(eno == 0);
+ }
+
+ eno = pthread_mutex_unlock(&e->mtx);
+ rtems_test_assert(eno == 0);
+
+ return value;
+}
+
+st
Re: [PATCH] Return invalid mode for !preempt and interrupt disable modes when SMP
On 12/10/17 20:45, Joel Sherrill wrote: - RTEMS_PROXY_BLOCKING = 28 + RTEMS_PROXY_BLOCKING = 29 I would not change existing status code values. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS milestones 4.13 and 5.0?
On 12/10/17 16:24, Chris Johns wrote: On 11/10/17 11:30 pm, Sebastian Huber wrote: milestones 4.13 and 5.0 don't fit the new version scheme: https://devel.rtems.org/wiki/Developer/Release#RTEMSRelease5SeriesAndHigherNumbering I suggest to rename the 5.0 milestone to 5.1 and move all 4.13 tickets to 5.1. A change to the major revision number requires a major change. In the new version scheme the major number changes with every release. The reality is 4.12 should be 5.0. The release and what it contains has grown considerable and we are currently attempting to converge on stability across all hosts and architectures before we branch. Looking at 4.12 now it appears to me to be a good 5.0 candidate so should this happen or is it too late? We have planned the move to 5.0 to be a build system change. The work to make this important and needed change is not small and I cannot do it without funding and I do not have any for this work. Moving to 5.0 after 4.12 without something major may result in a long wait while planned 5.0 changes are implemented. As a result we will have smaller things hanging on the development branch that should be released as we have with 4.12 now. We added 4.13 as a way to keep us keep moving with releases while we figure out now to make the build system change. I do not like having 4.13 but I do not see another path. Jumping to 5.0 is a solution. Using 5.1 for the next release is probably less confusing for users since a lot of stuff changed (current master would be 5.0.0, release is 5.1.0, branch version after release is 5.1.1). Someone would have to do this number change. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] bsp/atsam: Allow to change optimization settings.
Am 12.10.2017 um 19:42 schrieb Chris Johns: > On 12/10/17 9:36 am, Christian Mauderer wrote: >> Am 12.10.2017 um 18:06 schrieb Chris Johns: >>> On 12/10/17 12:00 am, Sebastian Huber wrote: @@ -4,7 +4,6 @@ RTEMS_CPU = arm CPU_CFLAGS = -mthumb -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard -CFLAGS_OPTIMIZE_V = -O2 -g -CFLAGS_OPTIMIZE_V += -ffunction-sections -fdata-sections +CFLAGS_OPTIMIZE_V ?= -O2 -g -ffunction-sections -fdata-sections >>> >>> >>> This is a really nice change. Should all the BSP's be changed? >>> >>> I see a 104 instances in the code and the change could be scripted. >>> >>> Being inconsistent on something that could be consistent across all BSPs is >>> confusing to all users. >>> >> >> the change is just similar to some other BSPs (like or1k or realview). >> > > It is a great idea and I think useful for all users of RTEMS. OK. It felt a little bit like a hack to me (using an environment variable during configure) but if you think it would be an improvement, I wouldn't offend. > >> If we want to offer something like that for all BSPs, it might would be >> a better idea to split the flags up (what I haven't done here). > > Yes it might pay to split them up. > >> I think the -ffunction-sections -fdata-sections is allways necessary? > > I am not sure which archs can use the function and data sections. It is the > `?=` > I like. Like you noted, I'm not sure too. It just seems that every BSP sets them. I'm also not sure why some BSPs have additional options and whether they are necessary. So for me it would currently be only possible to leave all other options untouched. > >> Some BSPs >> have some other options too like an additional -fomit-frame-pointer in >> rbtx4925 or a -mmultiple in mcp750. So if a user would want to use that >> environment variable to change optimization, the value wouldn't be >> consistent across BSPs. > > Ah ok. > >> >> A consistent solution could be to split it up like in or1k: >> >> CFLAGS_OPTIMIZE_V ?= -O0 -g >> CFLAGS_OPTIMIZE_V += -ffunction-sections -fdata-sections >> >> The general optimization could be overwritten with CFLAGS_OPTIMIZE_V and >> the BSP-specific parts would be added in the second line. >> >> What do you think? >> > > The or1k solution looks good. What if we did something like: > >CFLAGS_OPTIMIZE_V ?= -O0 >CFLAGS_DEBUG_V ?= -g >CFLAGS_OPTIMIZE_V += $(CFLAGS_DEBUG_V) -ffunction-sections -fdata-sections > > Is that too much? It would add two options instead of one. Maybe we should just put the -g to the default options in every BSP. It only increases the size of the binaries on the development host. If it is necessary to have some very small binaries, it is still possible to strip them. So I can't think of a case where -g hurts someone. So I would rather use a CFLAGS_OPTIMIZE_V ?= -O0 CFLAGS_OPTIMIZE_V += -g -ffunction-sections -fdata-sections > > It would make documenting what this does simpler. To be honest: I wouldn't be sure where the documentation should go. Do we have some guide about how to configure and compile a BSP? Regards Christian -- embedded brains GmbH Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
