date:20200813

Re: [PATCH 1/2] Confstr Port for RTEMS

2020-08-13 Thread Chris Johns

On 13/8/20 3:54 pm, Sebastian Huber wrote:
> On 12/08/2020 21:07, Gedare Bloom wrote:
> 
>> Chris, Christian, Sebastian:
>>
>> I think it would be best if one of you may have insight on this touching 
>> libbsd.
> Is libbsd really the right place for this function? Do we need the ability to
> synchronize it with FreeBSD? Are FreeBSD and RTEMS similar enough to share an
> implementation of confstr()?

Good question, I am not sure. What is the list of `names` we have to support?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 0/8] Test Framework: Support Fixture Test Plans

2020-08-13 Thread Sebastian Huber

The functions T_push_fixture() and T_pop_fixture() were added to support
nested fixtures.  This enables test building blocks.  The patch set adds
fixture-specific test plans to allow the use of test plans with nested
fixtures.

Sebastian Huber (8):
  libtest: Change fixture scope method
  libtest: Add output buffer drain and fill
  libtest: Add T_do_is_runner()
  libtest: Add T_puts()
  libtest: Use line buffer in T_check()
  libtest: Add T_check_steps()
  libtest: Add fixture steps
  libtest: Change T_step() and T_assert_step()

 cpukit/include/rtems/test.h   |  31 +-
 cpukit/libtest/t-test.c   | 480 +++---
 testsuites/libtests/ttest01/init.c|   2 +-
 testsuites/libtests/ttest01/test-destructor.c |   2 +-
 testsuites/libtests/ttest01/test-fixture.c|  42 +-
 testsuites/libtests/ttest01/test-plan.c   |   6 +-
 testsuites/libtests/ttest02/init.c|   7 +-
 testsuites/smptests/smpmulticast01/init.c |  16 +-
 8 files changed, 371 insertions(+), 215 deletions(-)

-- 
2.26.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 5/8] libtest: Use line buffer in T_check()

2020-08-13 Thread Sebastian Huber

Update #3199.
---
 cpukit/libtest/t-test.c | 117 +---
 1 file changed, 86 insertions(+), 31 deletions(-)

diff --git a/cpukit/libtest/t-test.c b/cpukit/libtest/t-test.c
index ce9af0498b..26fe988b11 100644
--- a/cpukit/libtest/t-test.c
+++ b/cpukit/libtest/t-test.c
@@ -614,14 +614,36 @@ T_file(const T_check_context *t)
return file + 1;
 }
 
+static const char T_planned_step_fmt[] = "planned step (%u)";
+
+static void
+T_check_putc(int c, void *arg)
+{
+   T_putchar_string_context *sctx;
+   size_t n;
+
+   sctx = arg;
+   n = sctx->n;
+
+   if (n > 0) {
+   char *s;
+
+   s = sctx->s;
+   *s = (char)c;
+   sctx->s = s + 1;
+   sctx->n = n - 1;
+   }
+}
+
 void
 T_check(const T_check_context *t, bool ok, ...)
 {
T_context *ctx;
va_list ap;
-   char scope[T_SCOPE_SIZE];
-   size_t len;
+   char line[T_LINE_SIZE];
unsigned int step;
+   int line_number;
+   const char *fmt;
 
ctx = &T_instance;
 
@@ -631,52 +653,85 @@ T_check(const T_check_context *t, bool ok, ...)
step = UINT_MAX;
}
 
-   len = T_scope(ctx, scope, sizeof(scope) - 1);
-   scope[len] = '\0';
+   va_start(ap, ok);
+   line[0] = '\0';
+   line_number = -1;
+   fmt = NULL;
 
if ((t->flags & T_CHECK_STEP_FLAG) != 0 &&
 step != T_CHECK_STEP_FROM_FLAGS(t->flags)) {
T_add_failure(ctx);
-   T_printf("F:%u:%i:%s:%s:%i:planned step (%u)\n", step,
-   T_cpu(), scope, T_file(t),
-   t->line, T_CHECK_STEP_FROM_FLAGS(t->flags));
+   line[0] = 'F';
+   line_number = t->line;
+   fmt = T_planned_step_fmt;
} else if (!ok) {
T_add_failure(ctx);
 
if (ctx->verbosity >= T_NORMAL) {
-   if ((t->flags & T_CHECK_QUIET) == 0) {
-   T_printf("F:%u:%i:%s:%s:%i",
-   step, T_cpu(), scope, T_file(t), t->line);
-   } else if (t->line >= 0) {
-   T_printf("F:*:%i:%s:%s:%i", T_cpu(), scope,
-   T_file(t), t->line);
-   } else {
-   T_printf("F:*:%i:%s:%s:*", T_cpu(), scope,
-   T_file(t));
-   }
+   line[0] = 'F';
+   line_number = t->line;
 
if ((t->flags & T_CHECK_FMT) != 0) {
-   const char *fmt;
-
-   T_printf(":");
-
-   va_start(ap, ok);
fmt = va_arg(ap, const char *);
-   T_vprintf(fmt, ap);
-   va_end(ap);
}
+   }
+   } else if ((t->flags & T_CHECK_QUIET) == 0 &&
+   ctx->verbosity >= T_VERBOSE) {
+   line[0] = 'P';
+   line_number = t->line;
+   }
+
+   if (line[0] != '\0') {
+   T_putchar_string_context sctx;
+   size_t chunk;
 
-   T_printf("\n");
+   sctx.n = sizeof(line) - 1;
+   sctx.s = &line[1];
+   T_check_putc(':', &sctx);
+
+   if (step != UINT_MAX) {
+   _IO_Printf(T_check_putc, &sctx, "%u", step);
+   } else {
+   T_check_putc('*', &sctx);
}
 
-   if ((t->flags & T_CHECK_STOP) != 0) {
-   T_do_stop(ctx);
+   _IO_Printf(T_check_putc, &sctx, ":%i:", T_cpu());
+   chunk = T_scope(ctx, sctx.s, sctx.n);
+   sctx.s += chunk;
+   sctx.n -= chunk;
+   T_check_putc(':', &sctx);
+   chunk = T_str_copy(sctx.s, T_file(t), sctx.n);
+   sctx.s += chunk;
+   sctx.n -= chunk;
+   T_check_putc(':', &sctx);
+
+   if (line_number >= 0) {
+   _IO_Printf(T_check_putc, &sctx, "%i", line_number);
+   } else {
+   T_check_putc('*', &sctx);
}
-   } else if ((t->flags & T_CHECK_QUIET) == 0 &&
-   ctx->verbosity >= T_VERBOSE) {
-   T_printf("P:%u:%i:%s:%s:%i\n", step, T_cpu(), scope, T_file(t),
-   t->line);
+
+   if (fmt != NULL) {
+   if (fmt == T_planned_step_fmt) {
+   T_check_putc(':', &sctx);
+   _IO_Printf(T_check_putc, &sctx, fmt,
+   T_CHECK_STEP_FROM_FLAGS(t->flags));
+   } else {
+   T_check_putc(':', &sctx);
+   _IO_Vprintf

[PATCH 1/8] libtest: Change fixture scope method

2020-08-13 Thread Sebastian Huber

Return the produced character count.  There is no need for a NUL
termination.

Update #3199.
---
 cpukit/include/rtems/test.h|   9 +-
 cpukit/libtest/t-test.c| 136 -
 testsuites/libtests/ttest01/test-fixture.c |   8 +-
 3 files changed, 86 insertions(+), 67 deletions(-)

diff --git a/cpukit/include/rtems/test.h b/cpukit/include/rtems/test.h
index 18aafbcf7c..a3900c1285 100644
--- a/cpukit/include/rtems/test.h
+++ b/cpukit/include/rtems/test.h
@@ -62,7 +62,7 @@ typedef struct T_fixture {
void (*setup)(void *);
void (*stop)(void *);
void (*teardown)(void *);
-   void (*scope)(void *, char *, size_t);
+   size_t (*scope)(void *, char *, size_t);
void *initial_context;
 } T_fixture;
 
@@ -2324,14 +2324,19 @@ T_NO_RETURN void T_stop(void);
  *
  * @param second_indices is an array of indices defining which descriptive
  *   string is used for each entry in the description table.
+ *
+ * @return Returns the characters consumed from the buffer for the produced
+ *   scope.
  */
-void T_get_scope(
+size_t T_get_scope(
   const char * const * const *desc,
   char *buf,
   size_t n,
   const size_t *second_indices
 );
 
+size_t T_str_copy(char *, const char *, size_t);
+
 #ifdef __rtems__
 #define T_TEST_CASE_FIXTURE(name, fixture) \
 void T_case_body_##name(void); \
diff --git a/cpukit/libtest/t-test.c b/cpukit/libtest/t-test.c
index 999b8770d0..b1b5253bb5 100644
--- a/cpukit/libtest/t-test.c
+++ b/cpukit/libtest/t-test.c
@@ -244,9 +244,26 @@ T_cpu(void)
 #endif
 }
 
+size_t
+T_str_copy(char *dst, const char *src, size_t n)
+{
+   size_t i;
+
+   i = 0;
+
+   while (*src != '\0' && i < n) {
+   *dst = *src;
+   ++dst;
+   ++src;
+   ++i;
+   }
+
+   return i;
+}
+
 #if defined(__rtems__)
-static const char *
-T_object_name_to_string(Objects_Name name, char *buf)
+static size_t
+T_object_name_to_string(char *dst, Objects_Name name, size_t n)
 {
uint32_t on;
size_t i;
@@ -260,18 +277,18 @@ T_object_name_to_string(Objects_Name name, char *buf)
 
c = (unsigned char)(on >> s);
 
-   if (c >= '!' && c <= '~') {
-   buf[i] = (char)c;
+   if (c >= '!' && c <= '~' && i < n) {
+   *dst = (char)c;
+   ++dst;
++i;
}
}
 
-   buf[i] = '\0';
-   return buf;
+   return i;
 }
 
-static const char *
-T_thread_name(const Thread_Control *th, char *buf)
+static size_t
+T_thread_name(char *dst, const Thread_Control *th, size_t n)
 {
if (th != NULL) {
const char *name;
@@ -279,23 +296,21 @@ T_thread_name(const Thread_Control *th, char *buf)
name = th->Join_queue.Queue.name;
 
if (name != NULL && name[0] != '\0') {
-   return name;
-   } else {
-   return T_object_name_to_string(th->Object.name, buf);
+   return T_str_copy(dst, name, n);
}
-   } else {
-   buf[0] = '?';
-   buf[1] = '\0';
-   return buf;
+
+   return T_object_name_to_string(dst, th->Object.name, n);
}
+
+   return T_str_copy(dst, "?", n);
 }
 #endif
 
-static const char *
-T_scope(T_context *ctx, char *buf)
+static size_t
+T_scope(T_context *ctx, char *dst, size_t n)
 {
-   const char *r;
T_fixture_node *node;
+   size_t len;
 
 #if defined(__rtems__)
ISR_Level level;
@@ -309,31 +324,26 @@ T_scope(T_context *ctx, char *buf)
 
executing = _Per_CPU_Get_executing(cpu_self);
_ISR_Local_enable(level);
-   r = T_thread_name(executing, buf);
+   len = T_thread_name(dst, executing, n);
} else {
_ISR_Local_enable(level);
-   buf[0] = 'I';
-   buf[1] = 'S';
-   buf[2] = 'R';
-   buf[3] = '\0';
-   r = buf;
+   len = T_str_copy(dst, "ISR", n);
}
+
 #elif defined(__linux__)
static __thread char name[128];
 
-   (void)buf;
-
if (name[0] == '\0') {
pthread_getname_np(pthread_self(), name, sizeof(name));
}
 
-   r = &name[0];
+   len = T_str_copy(dst, name, n);
 #else
-   buf[0] = '?';
-   buf[1] = '\0';
-   r = buf;
+   len = T_str_copy(dst, "?", n);
 #endif
 
+   dst += len;
+   n -= len;
node = &ctx->case_fixture;
 
do {
@@ -342,17 +352,18 @@ T_scope(T_context *ctx, char *buf)
fixture = node->fixture;
 
if (fixture != NULL && fixture->scope != NULL) {
-   size_t n;
+   size_t m;
 
-   n = strlen(r);
-   (*fixture->

[PATCH 6/8] libtest: Add T_check_steps()

2020-08-13 Thread Sebastian Huber

Update #3199.
---
 cpukit/libtest/t-test.c | 31 +--
 1 file changed, 13 insertions(+), 18 deletions(-)

diff --git a/cpukit/libtest/t-test.c b/cpukit/libtest/t-test.c
index 26fe988b11..21e9afe190 100644
--- a/cpukit/libtest/t-test.c
+++ b/cpukit/libtest/t-test.c
@@ -49,8 +49,6 @@
 
 #define T_LINE_SIZE 128
 
-#define T_SCOPE_SIZE 64
-
 typedef struct {
pthread_spinlock_t lock;
char *buf;
@@ -937,6 +935,17 @@ T_do_case_begin(T_context *ctx, const T_case_context *tc)
}
 }
 
+static void
+T_check_steps(unsigned int planned_steps, unsigned int steps,
+unsigned int failures)
+{
+   if (planned_steps != UINT_MAX && planned_steps != steps &&
+   failures == 0) {
+   T_check(&T_special, false, "actual steps (%u), "
+   "planned steps (%u)", steps, planned_steps);
+   }
+}
+
 static void
 T_do_case_end(T_context *ctx, const T_case_context *tc)
 {
@@ -976,23 +985,9 @@ T_do_case_end(T_context *ctx, const T_case_context *tc)
memory_order_relaxed);
failures = atomic_fetch_add_explicit(&ctx->failures, 0,
memory_order_relaxed);
+   T_check_steps(planned_steps, steps, failures);
 
-   if (planned_steps != UINT_MAX && planned_steps != steps &&
-   failures == 0) {
-   ++failures;
-
-   if (ctx->verbosity >= T_NORMAL) {
-   char scope[T_SCOPE_SIZE];
-   size_t len;
-
-   len = T_scope(ctx, scope, sizeof(scope) - 1);
-   scope[len] = '\0';
-   T_printf("F:*:%i:%s:*:*:actual steps (%u), "
-   "planned steps (%u)\n", T_cpu(),
-   scope, steps, planned_steps);
-   }
-   }
-
+   failures = atomic_load_explicit(&ctx->failures, memory_order_relaxed);
delta = (*config->now)() - ctx->case_begin_time;
T_do_log(ctx, T_QUIET, "E:%s:N:%u:F:%u:D:%s\n",
tc->name, steps, failures, T_time_to_string_us(delta, ts));
-- 
2.26.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 8/8] libtest: Change T_step() and T_assert_step()

2020-08-13 Thread Sebastian Huber

Normally, the expected test step must be a compile time constant.  Allow
variable expected test steps for the T_step() and T_assert_step().  This
can be used in for parameterized test loops with individual fixtures.

Remove the ability to use custom failure messages due to some
implementation constraints.

Update #3199.
---
 cpukit/include/rtems/test.h   | 17 +++--
 cpukit/libtest/t-test.c   | 11 +++
 testsuites/libtests/ttest01/test-destructor.c |  2 +-
 testsuites/libtests/ttest01/test-plan.c   |  6 +++---
 testsuites/smptests/smpmulticast01/init.c | 16 
 5 files changed, 34 insertions(+), 18 deletions(-)

diff --git a/cpukit/include/rtems/test.h b/cpukit/include/rtems/test.h
index 95e078ceff..ccab6c4a95 100644
--- a/cpukit/include/rtems/test.h
+++ b/cpukit/include/rtems/test.h
@@ -2168,12 +2168,17 @@ void T_check_rsc_success(const T_check_context *, 
uint32_t);
 
 void T_plan(unsigned int);
 
-#define T_step(...) \
-T_flags_true(T_CHECK_STEP(T_VA_ARGS_FIRST(__VA_ARGS__)), \
-true T_VA_ARGS_MORE(__VA_ARGS__))
-#define T_step_assert(...) \
-T_flags_true(T_CHECK_STEP(T_VA_ARGS_FIRST(__VA_ARGS__)) | T_CHECK_STOP, \
-true T_VA_ARGS_MORE(__VA_ARGS__))
+void T_check_step(const T_check_context *, unsigned int);
+
+#define T_flags_step(a, flags) \
+{  \
+   static const T_check_context T_check_instance = {   \
+   T_FILE_NAME, __LINE__, (flags) | T_CHECK_FMT }; \
+   T_check_step(&T_check_instance, a); \
+}
+
+#define T_step(e) T_flags_step(e, 0)
+#define T_step_assert(e) T_flags_step(e, T_CHECK_STOP)
 
 /**
  * @defgroup RTEMSTestFrameworkTime Time Services
diff --git a/cpukit/libtest/t-test.c b/cpukit/libtest/t-test.c
index 306f9439c4..c12b2d4f41 100644
--- a/cpukit/libtest/t-test.c
+++ b/cpukit/libtest/t-test.c
@@ -550,6 +550,17 @@ void T_plan(unsigned int planned_steps)
expected);
 }
 
+void
+T_check_step(const T_check_context *t, unsigned int expected)
+{
+   T_check_context tt;
+
+   tt = *t;
+   tt.flags |= T_CHECK_STEP(expected);
+   T_check(&tt, true, "actual step is not equal to expected step (%u)",
+   expected);
+}
+
 void
 T_case_register(T_case_context *tc)
 {
diff --git a/testsuites/libtests/ttest01/test-destructor.c 
b/testsuites/libtests/ttest01/test-destructor.c
index 71b14c08f6..0a2f650ed2 100644
--- a/testsuites/libtests/ttest01/test-destructor.c
+++ b/testsuites/libtests/ttest01/test-destructor.c
@@ -4,7 +4,7 @@ static void
 destroy(T_destructor *dtor)
 {
(void)dtor;
-   T_step(0, "destroy");
+   T_step(0);
 }
 
 T_TEST_CASE(destructor)
diff --git a/testsuites/libtests/ttest01/test-plan.c 
b/testsuites/libtests/ttest01/test-plan.c
index 155704c478..4a550f34fa 100644
--- a/testsuites/libtests/ttest01/test-plan.c
+++ b/testsuites/libtests/ttest01/test-plan.c
@@ -28,10 +28,10 @@ T_TEST_CASE(double_plan)
 
 T_TEST_CASE(steps)
 {
-   T_step(0, "a");
+   T_step(0);
T_plan(3);
-   T_step(1, "b");
-   T_step(2, "c");
+   T_step(1);
+   T_step(2);
 }
 
 #include "t-self-test.h"
diff --git a/testsuites/smptests/smpmulticast01/init.c 
b/testsuites/smptests/smpmulticast01/init.c
index b6ee9f93cc..f5ed70952a 100644
--- a/testsuites/smptests/smpmulticast01/init.c
+++ b/testsuites/smptests/smpmulticast01/init.c
@@ -432,17 +432,17 @@ static Per_CPU_Job job_order_jobs[TEST_JOB_ORDER_JOBS];
 
 static void job_order_handler_0(void *arg)
 {
-  T_step(1, "invalid job order");
+  T_step(1);
 }
 
 static void job_order_handler_1(void *arg)
 {
-  T_step(2, "invalid job order");
+  T_step(2);
 }
 
 static void job_order_handler_2(void *arg)
 {
-  T_step(3, "invalid job order");
+  T_step(3);
 }
 
 static const Per_CPU_Job_context job_order_contexts[TEST_JOB_ORDER_JOBS] = {
@@ -464,7 +464,7 @@ T_TEST_CASE(JobOrder)
 _Per_CPU_Add_job(cpu_self, &job_order_jobs[i]);
   }
 
-  T_step(0, "wrong job processing time");
+  T_step(0);
   _SMP_Send_message(_Per_CPU_Get_index(cpu_self), SMP_MESSAGE_PERFORM_JOBS);
   _Thread_Dispatch_enable(cpu_self);
 }
@@ -475,13 +475,13 @@ static Per_CPU_Job 
add_job_in_job_jobs[TEST_ADD_JOB_IN_JOB_JOBS];
 
 static void add_job_in_job_handler_0(void *arg)
 {
-  T_step(1, "invalid job order");
+  T_step(1);
   _Per_CPU_Add_job(_Per_CPU_Get(), &add_job_in_job_jobs[1]);
 }
 
 static void add_job_in_job_handler_1(void *arg)
 {
-  T_step(3, "invalid job order");
+  T_step(3);
 }
 
 static const Per_CPU_Job_context
@@ -503,9 +503,9 @@ T_TEST_CASE(AddJobInJob)
   }
 
   _Per_CPU_Add_job(cpu_self, &add_job_in_job_jobs[0]);
-  T_step(0, "wrong job processing time");
+  T_step(0);
   _SMP_Send_message(_Per_CPU_Get_index(cpu_self), SMP_MESSAGE_PERFORM_JOBS);
-  T_step(2, "wrong job processing time");
+  T_step(2);
   _SMP_Send_message(_Per_CPU_Get_in

[PATCH 2/8] libtest: Add output buffer drain and fill

2020-08-13 Thread Sebastian Huber

Update #3199.
---
 cpukit/libtest/t-test.c | 60 -
 1 file changed, 35 insertions(+), 25 deletions(-)

diff --git a/cpukit/libtest/t-test.c b/cpukit/libtest/t-test.c
index b1b5253bb5..e8d0542c31 100644
--- a/cpukit/libtest/t-test.c
+++ b/cpukit/libtest/t-test.c
@@ -143,15 +143,12 @@ T_snprintf(char *s, size_t n, char const *fmt, ...)
return len;
 }
 
-static int
-T_vprintf_direct(char const *fmt, va_list ap)
+static void
+T_output_buffer_drain(T_context *ctx)
 {
-   T_context *ctx;
unsigned int head;
unsigned int tail;
 
-   ctx = &T_instance;
-
head = atomic_load_explicit(&ctx->buf_head, memory_order_acquire);
tail = atomic_load_explicit(&ctx->buf_tail, memory_order_relaxed);
 
@@ -161,32 +158,16 @@ T_vprintf_direct(char const *fmt, va_list ap)
}
 
atomic_store_explicit(&ctx->buf_tail, tail, memory_order_relaxed);
-
-   return _IO_Vprintf(ctx->putchar, ctx->putchar_arg, fmt, ap);
 }
 
-static int
-T_vprintf_buffered(char const *fmt, va_list ap)
+static unsigned int
+T_output_buffer_fill(T_context *ctx, const char *buf, unsigned int len)
 {
-   unsigned int len;
-   T_context *ctx;
-   char buf[T_LINE_SIZE];
-   T_putchar_string_context sctx = {
-   .s = buf,
-   .n = sizeof(buf)
-   };
unsigned int head;
unsigned int tail;
unsigned int mask;
unsigned int capacity;
 
-   len = (unsigned int)_IO_Vprintf(T_putchar_string, &sctx, fmt, ap);
-
-   if (len >= sizeof(buf)) {
-   len = sizeof(buf) - 1;
-   }
-
-   ctx = &T_instance;
pthread_spin_lock(&ctx->lock);
head = atomic_load_explicit(&ctx->buf_head, memory_order_relaxed);
tail = atomic_load_explicit(&ctx->buf_tail, memory_order_relaxed);
@@ -195,7 +176,7 @@ T_vprintf_buffered(char const *fmt, va_list ap)
 
if (len <= capacity) {
unsigned int todo;
-   char *c;
+   const char *c;
 
todo = len;
c = buf;
@@ -215,7 +196,36 @@ T_vprintf_buffered(char const *fmt, va_list ap)
}
 
pthread_spin_unlock(&ctx->lock);
-   return (int)len;
+   return len;
+}
+
+static int
+T_vprintf_direct(char const *fmt, va_list ap)
+{
+   T_context *ctx;
+
+   ctx = &T_instance;
+   T_output_buffer_drain(ctx);
+   return _IO_Vprintf(ctx->putchar, ctx->putchar_arg, fmt, ap);
+}
+
+static int
+T_vprintf_buffered(char const *fmt, va_list ap)
+{
+   char buf[T_LINE_SIZE];
+   T_putchar_string_context sctx = {
+   .s = buf,
+   .n = sizeof(buf)
+   };
+   unsigned int len;
+
+   len = (unsigned int)_IO_Vprintf(T_putchar_string, &sctx, fmt, ap);
+
+   if (len >= sizeof(buf)) {
+   len = sizeof(buf) - 1;
+   }
+
+   return (int)T_output_buffer_fill(&T_instance, buf, len);
 }
 
 int
-- 
2.26.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 7/8] libtest: Add fixture steps

2020-08-13 Thread Sebastian Huber

Support a new test plan for each nested fixture.

Update #3199.
---
 cpukit/include/rtems/test.h|  3 +
 cpukit/libtest/t-test.c| 83 ++
 testsuites/libtests/ttest01/init.c |  2 +-
 testsuites/libtests/ttest01/test-fixture.c | 34 -
 testsuites/libtests/ttest02/init.c |  7 +-
 5 files changed, 80 insertions(+), 49 deletions(-)

diff --git a/cpukit/include/rtems/test.h b/cpukit/include/rtems/test.h
index 212d4a5ae2..95e078ceff 100644
--- a/cpukit/include/rtems/test.h
+++ b/cpukit/include/rtems/test.h
@@ -71,6 +71,9 @@ typedef struct T_fixture_node {
struct T_fixture_node *previous;
const T_fixture *fixture;
void *context;
+   unsigned int next_planned_steps;
+   unsigned int next_steps;
+   unsigned int failures;
 } T_fixture_node;
 
 #define T_ARRAY_SIZE(array) (sizeof(array) / sizeof((array)[0]))
diff --git a/cpukit/libtest/t-test.c b/cpukit/libtest/t-test.c
index 21e9afe190..306f9439c4 100644
--- a/cpukit/libtest/t-test.c
+++ b/cpukit/libtest/t-test.c
@@ -68,6 +68,7 @@ typedef struct {
atomic_uint steps;
atomic_uint failures;
jmp_buf case_begin_context;
+   unsigned int fixture_steps;
unsigned int overall_cases;
unsigned int overall_steps;
unsigned int overall_failures;
@@ -633,6 +634,32 @@ T_check_putc(int c, void *arg)
}
 }
 
+static void
+T_check_print_steps(T_context *ctx, T_putchar_string_context *sctx,
+unsigned int step)
+{
+   T_fixture_node *node;
+
+   node = &ctx->case_fixture;
+
+   while (true) {
+   node = node->previous;
+
+   if (node != NULL) {
+   _IO_Printf(T_check_putc, sctx, "%u.",
+   node->next_steps);
+   } else {
+   break;
+   }
+   }
+
+   if (step != UINT_MAX) {
+   _IO_Printf(T_check_putc, sctx, "%u", step);
+   } else {
+   T_check_putc('*', sctx);
+   }
+}
+
 void
 T_check(const T_check_context *t, bool ok, ...)
 {
@@ -686,13 +713,7 @@ T_check(const T_check_context *t, bool ok, ...)
sctx.n = sizeof(line) - 1;
sctx.s = &line[1];
T_check_putc(':', &sctx);
-
-   if (step != UINT_MAX) {
-   _IO_Printf(T_check_putc, &sctx, "%u", step);
-   } else {
-   T_check_putc('*', &sctx);
-   }
-
+   T_check_print_steps(ctx, &sctx, step);
_IO_Printf(T_check_putc, &sctx, ":%i:", T_cpu());
chunk = T_scope(ctx, sctx.s, sctx.n);
sctx.s += chunk;
@@ -887,8 +908,6 @@ T_do_run_initialize(const T_config *config)
ctx->putchar = config->putchar;
ctx->putchar_arg = config->putchar_arg;
ctx->verbosity = config->verbosity;
-   atomic_store_explicit(&ctx->steps, 0, memory_order_relaxed);
-   atomic_store_explicit(&ctx->failures, 0, memory_order_relaxed);
ctx->overall_cases = 0;
ctx->overall_steps = 0;
ctx->overall_failures = 0;
@@ -919,6 +938,7 @@ T_do_case_begin(T_context *ctx, const T_case_context *tc)
memory_order_relaxed);
atomic_store_explicit(&ctx->steps, 0, memory_order_relaxed);
atomic_store_explicit(&ctx->failures, 0, memory_order_relaxed);
+   ctx->fixture_steps = 0;
 
T_actions_forward(config, T_EVENT_CASE_EARLY, tc->name);
T_do_log(ctx, T_NORMAL, "B:%s\n", tc->name);
@@ -950,33 +970,18 @@ static void
 T_do_case_end(T_context *ctx, const T_case_context *tc)
 {
const T_config *config;
-   T_fixture_node *node;
unsigned int planned_steps;
unsigned int steps;
unsigned int failures;
T_time delta;
T_time_string ts;
 
-   config = ctx->config;
-   node = ctx->fixtures;
-   ctx->fixtures = NULL;
-
-   while (node != NULL) {
-   const T_fixture *fixture;
-   T_fixture_node *dead;
-
-   fixture = node->fixture;
-
-   if (fixture != NULL && fixture->teardown != NULL) {
-   (*fixture->teardown)(node->context);
-   }
-
-   dead = node;
-   node = node->next;
-   memset(dead, 0, sizeof(*dead));
+   while (ctx->fixtures != NULL) {
+   T_pop_fixture();
}
 
T_call_destructors(ctx);
+   config = ctx->config;
T_actions_backward(config, T_EVENT_CASE_END, tc->name);
 
planned_steps = atomic_fetch_add_explicit(&ctx->planned_steps,
@@ -989,6 +994,7 @@ T_do_case_end(T_context *ctx, const T_case_context *tc)
 
failures = atomic_load_explicit(&ctx->failures, memory_order_relaxed);
delta = (*config->now)() - ctx->case_begin_time;
+   steps += ctx->fixture_steps;
T_do_log(ctx, T_QUIET, "E:%s:N:%u:F:%u:D:%s\n",
tc->name, steps, fail

[PATCH 4/8] libtest: Add T_puts()

2020-08-13 Thread Sebastian Huber

Update #3199.
---
 cpukit/include/rtems/test.h |  2 ++
 cpukit/libtest/t-test.c | 24 
 2 files changed, 26 insertions(+)

diff --git a/cpukit/include/rtems/test.h b/cpukit/include/rtems/test.h
index a3900c1285..212d4a5ae2 100644
--- a/cpukit/include/rtems/test.h
+++ b/cpukit/include/rtems/test.h
@@ -673,6 +673,8 @@ int T_printf(char const *, ...);
 
 int T_vprintf(char const *, va_list);
 
+int T_puts(const char *, size_t);
+
 int T_snprintf(char *, size_t, const char *, ...);
 
 void T_log(T_verbosity, char const *, ...);
diff --git a/cpukit/libtest/t-test.c b/cpukit/libtest/t-test.c
index 92aed62b9b..ce9af0498b 100644
--- a/cpukit/libtest/t-test.c
+++ b/cpukit/libtest/t-test.c
@@ -276,6 +276,30 @@ T_vprintf(char const *fmt, va_list ap)
return len;
 }
 
+static int
+T_do_puts(T_context *ctx, const char *buf, size_t len)
+{
+   if (T_do_is_runner(ctx)) {
+   size_t i;
+
+   T_output_buffer_drain(ctx);
+
+   for (i = 0; i < len; ++i) {
+   (*ctx->putchar)(buf[i], ctx->putchar_arg);
+   }
+   } else {
+   len = T_output_buffer_fill(ctx, buf, len);
+   }
+
+   return len;
+}
+
+int
+T_puts(const char *buf, size_t len)
+{
+   return T_do_puts(&T_instance, buf, len);
+}
+
 static int
 T_cpu(void)
 {
-- 
2.26.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 3/8] libtest: Add T_do_is_runner()

2020-08-13 Thread Sebastian Huber

Update #3199.
---
 cpukit/libtest/t-test.c | 64 ++---
 1 file changed, 34 insertions(+), 30 deletions(-)

diff --git a/cpukit/libtest/t-test.c b/cpukit/libtest/t-test.c
index e8d0542c31..92aed62b9b 100644
--- a/cpukit/libtest/t-test.c
+++ b/cpukit/libtest/t-test.c
@@ -92,6 +92,40 @@ const T_check_context T_special = {
.flags = T_CHECK_FMT | T_CHECK_QUIET
 };
 
+static bool
+T_do_is_runner(T_context *ctx)
+{
+   bool is_runner;
+#ifdef __rtems__
+   ISR_Level level;
+   const Per_CPU_Control *cpu_self;
+#endif
+
+#ifdef __rtems__
+   _ISR_Local_disable(level);
+   cpu_self = _Per_CPU_Get();
+
+   if (ctx->runner_thread != NULL) {
+   is_runner = cpu_self->isr_nest_level == 0 &&
+   _Per_CPU_Get_executing(cpu_self) == ctx->runner_thread;
+   } else {
+   is_runner = cpu_self == ctx->runner_cpu;
+   }
+
+   _ISR_Local_enable(level);
+#else
+   is_runner = ctx->runner_valid &&
+   pthread_equal(pthread_self(), ctx->runner_thread) != 0;
+#endif
+
+   return is_runner;
+}
+
+bool T_is_runner(void)
+{
+   return T_do_is_runner(&T_instance);
+}
+
 typedef struct {
char *s;
size_t n;
@@ -952,36 +986,6 @@ T_main(const T_config *config)
return T_do_run_finalize(ctx) ? 0 : 1;
 }
 
-bool T_is_runner(void)
-{
-   T_context *ctx;
-   bool is_runner;
-#ifdef __rtems__
-   ISR_Level level;
-   const Per_CPU_Control *cpu_self;
-#endif
-
-   ctx = &T_instance;
-#ifdef __rtems__
-   _ISR_Local_disable(level);
-   cpu_self = _Per_CPU_Get();
-
-   if (ctx->runner_thread != NULL) {
-   is_runner = cpu_self->isr_nest_level == 0 &&
-   _Per_CPU_Get_executing(cpu_self) == ctx->runner_thread;
-   } else {
-   is_runner = cpu_self == ctx->runner_cpu;
-   }
-
-   _ISR_Local_enable(level);
-#else
-   is_runner = ctx->runner_valid &&
-   pthread_equal(pthread_self(), ctx->runner_thread) != 0;
-#endif
-
-   return is_runner;
-}
-
 #ifdef __rtems__
 RTEMS_LINKER_ROSET(_T, T_case_context *);
 #endif /* __rtems__ */
-- 
2.26.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/shared/ofw: Added and Documented RTEMS OFW interface

2020-08-13 Thread Niteesh G. S.

Hello,
On Thu, Aug 13, 2020 at 12:09 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> Hello Niteesh,
>
> On 13/08/2020 07:05, Niteesh G. S. wrote:
> > On Thu, Aug 13, 2020 at 12:36 AM Gedare Bloom  > > wrote:
> >
> > I make a few comments below for you to consider. At a high level, I
> > think the interface looks reasonable, although plainly mimics the
> > freebsd naming conventions. I wonder if we should prefer our naming
> > conventions, which is to aim to use _ to separate different words,
> and
> > to limit use of abbreviations except as they help shorten very long
> > names?
> >
> > I might suggest something along these lines:
> > rtems_ofw_get_prop_len() instead of rtems_ofw_getproplen() for
> example.
> >
> >
> > I'll change them to RTEMS naming conventions.
> >
> >
> > It will make mapping to FreeBSD a little more annoying, but will make
> > the RTEMS interface more RTEMS-friendly.
> >
> > Other small comments below.
> >
> > On Wed, Aug 12, 2020 at 10:11 AM G S Niteesh Babu
> > mailto:niteesh...@gmail.com>> wrote:
> > >
> > > ---
> > >  bsps/shared/dev/ofw/ofw.c |   0
> > >  bsps/shared/dev/ofw/ofw.h | 437
> > ++
> > >  2 files changed, 437 insertions(+)
> > >  create mode 100644 bsps/shared/dev/ofw/ofw.c
> > >  create mode 100644 bsps/shared/dev/ofw/ofw.h
> > >
> > > diff --git a/bsps/shared/dev/ofw/ofw.c b/bsps/shared/dev/ofw/ofw.c
> > > new file mode 100644
> > > index 00..e69de29bb2
> > > diff --git a/bsps/shared/dev/ofw/ofw.h b/bsps/shared/dev/ofw/ofw.h
> > > new file mode 100644
> > > index 00..5a8526c892
> > > --- /dev/null
> > > +++ b/bsps/shared/dev/ofw/ofw.h
> > > @@ -0,0 +1,437 @@
> > > +/* SPDX-License-Identifier: BSD-2-Clause */
> > > +
> > > +/**
> > > + * @file
> > > + *
> > > + * @ingroup ofw
> > > + *
> > > + * RTEMS FDT implementation of OpenFirmWare Interface.
>
> Maybe a short notice that the intention is to be compatible with the
> FreeBSD OpenFirmWare interface would be nice. So if someone changes
> something he knows that he has to take a look at FreeBSD too.
>
OK. I'll add one.

> > > + */
> > > +
> > > +/*
> > > + * Copyright (C) <2020> Niteesh Babu G S  > >
> >
> > no <> around year
> >
> > Fixed.
> >
> >
> > > + *
> > > + * Redistribution and use in source and binary forms, with or
> without
> > > + * modification, are permitted provided that the following
> conditions
> > > + * are met:
> > > + * 1. Redistributions of source code must retain the above
> copyright
> > > + *notice, this list of conditions and the following
> disclaimer.
> > > + * 2. Redistributions in binary form must reproduce the above
> > copyright
> > > + *notice, this list of conditions and the following
> > disclaimer in the
> > > + *documentation and/or other materials provided with the
> > distribution.
> > > + *
> > > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> > CONTRIBUTORS "AS IS"
> > > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> > LIMITED TO, THE
> > > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
> > PARTICULAR PURPOSE
> > > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> > CONTRIBUTORS BE
> > > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
> > EXEMPLARY, OR
> > > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
> > PROCUREMENT OF
> > > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
> > OR BUSINESS
> > > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
> > WHETHER IN
> > > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> > OTHERWISE)
> > > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
> > ADVISED OF THE
> > > + * POSSIBILITY OF SUCH DAMAGE.
> > > + */
> > > +
> > > +#ifndef _OFW_H
> > > +#define _OFW_H
> > > +
> > > +#ifdef __cplusplus
> > > +extern "C" {
> > > +#endif
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +typedef uint32_t  ihandle_t;
> > > +typedef uint32_t  pcell_t;
> > > +typedef uint32_t  phandle_t;
> > document the types?
> >
> > I'll document them. I should document their use right? Like what
> > ihandle_t, phandle_t represent.
> >
> > > +
> > > +/**
> > > + * @brief Gets the node that is next to @a node.
> >
> > Somewhere the data structure should be explained. Maybe it will take
> a
> > new section in our doco to document the new interface.
> >
> >
> > Once we finalize the interface. I'll add it to the doco.
> > But I don't understand what you mean by data structures.
> >
> >
> >

[PATCH v3] Psxtest : Fix String Turncation warning

2020-08-13 Thread Aschref Ben-Thabet

From: Aschref Ben Thabet 

replace strncpy with strdup to silence this warning since it tries to
allocate enough memory to hold the old string (plus a '\0' character
to mark the end of the string).

ddd
---
 testsuites/psxtests/psxndbm01/init.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/testsuites/psxtests/psxndbm01/init.c 
b/testsuites/psxtests/psxndbm01/init.c
index b524aff0df..cb4d1aca66 100644
--- a/testsuites/psxtests/psxndbm01/init.c
+++ b/testsuites/psxtests/psxndbm01/init.c
@@ -217,10 +217,7 @@ rtems_task Init(rtems_task_argument ignored)
   rtems_test_assert( strcmp( (const char*)get_phone_no.dptr, PHONE_NO2 ) == 0 
);
 
   puts( "Fetch non-existing record and confirm error." );
-  test_strings = (char*)malloc(6);
-  memcpy( test_strings, "Hello", 5 );
-
-  test_strings[5] = '\0';
+  test_strings = strdup( "Hello" );
 
 /* The data pointed by test_string is now pointed by key.dptr */
   key.dptr = test_strings;
-- 
2.26.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] Psxtest : Fix String Turncation warning

2020-08-13 Thread Sebastian Huber


On 13/08/2020 13:44, Aschref Ben-Thabet wrote:


diff --git a/testsuites/psxtests/psxndbm01/init.c 
b/testsuites/psxtests/psxndbm01/init.c
index b524aff0df..cb4d1aca66 100644
--- a/testsuites/psxtests/psxndbm01/init.c
+++ b/testsuites/psxtests/psxndbm01/init.c
@@ -217,10 +217,7 @@ rtems_task Init(rtems_task_argument ignored)
rtems_test_assert( strcmp( (const char*)get_phone_no.dptr, PHONE_NO2 ) == 0 
);
  
puts( "Fetch non-existing record and confirm error." );

-  test_strings = (char*)malloc(6);
-  memcpy( test_strings, "Hello", 5 );
-
-  test_strings[5] = '\0';
+  test_strings = strdup( "Hello" );
This patch is not against the master branch. Please squash all your 
local commits together and send a v4 which includes all changes against 
the master branch.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Need help in figuring out how to allocate sizes to the array

2020-08-13 Thread Richi Dubey

Hi,

I want to use arrays with size _CONFIGURE_MAXIMUM_PROCESSORS. Is it
okay if I define the arrays with this size while writing the scheduler
strong APA header file? I am asking this because the value of this
header gets defined at the time the test case runs while the scheduler
gets linked to the test case at the time of linking. So how would it
work?

This question is in continuation of
https://lists.rtems.org/pipermail/devel/2020-August/061305.html and
the code that I am working on right now is
:https://github.com/richidubey/rtems/pull/7/files.

I want to make the sizes of Scheduler_Node *caller, Per_CPU_Control *Cpu
and bool visited equal to _CONFIGURE_MAXIMUM_PROCESSORS which are
defined here 
https://github.com/richidubey/rtems/pull/7/files#diff-9a1c6e240a276a856e99c45d87f1a02f.

Thanks,
RIchi.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Need help in figuring out how to allocate sizes to the array

2020-08-13 Thread Sebastian Huber


On 13/08/2020 14:42, Richi Dubey wrote:


I want to use arrays with size _CONFIGURE_MAXIMUM_PROCESSORS. Is it
okay if I define the arrays with this size while writing the scheduler
strong APA header file? I am asking this because the value of this
header gets defined at the time the test case runs while the scheduler
gets linked to the test case at the time of linking. So how would it
work?


Do NOT use _CONFIGURE_MAXIMUM_PROCESSORS.

In  please use something similar to the EDF scheduler 
instantiation:


#ifdef CONFIGURE_SCHEDULER_EDF_SMP
  #include 

  #ifndef CONFIGURE_MAXIMUM_PROCESSORS
    #error "CONFIGURE_MAXIMUM_PROCESSORS must be defined to configure 
the EDF SMP scheduler"

  #endif

  #define SCHEDULER_EDF_SMP_CONTEXT_NAME( name ) \
    SCHEDULER_CONTEXT_NAME( EDF_SMP_ ## name )

  #define RTEMS_SCHEDULER_EDF_SMP( name ) \
    static struct { \
  Scheduler_EDF_SMP_Context Base; \
  Scheduler_EDF_SMP_Ready_queue Ready[ CONFIGURE_MAXIMUM_PROCESSORS 
+ 1 ]; \

    } SCHEDULER_EDF_SMP_CONTEXT_NAME( name )

  #define RTEMS_SCHEDULER_TABLE_EDF_SMP( name, obj_name ) \
    { \
  &SCHEDULER_EDF_SMP_CONTEXT_NAME( name ).Base.Base.Base, \
  SCHEDULER_EDF_SMP_ENTRY_POINTS, \
  SCHEDULER_EDF_MAXIMUM_PRIORITY, \
  ( obj_name ) \
  SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( false ) \
    }

  /* Provided for backward compatibility */

  #define RTEMS_SCHEDULER_CONTEXT_EDF_SMP( name, max_cpu_count ) \
    RTEMS_SCHEDULER_EDF_SMP( name )

  #define RTEMS_SCHEDULER_CONTROL_EDF_SMP( name, obj_name ) \
    RTEMS_SCHEDULER_TABLE_EDF_SMP( name, obj_name )
#endif

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: crypt and POSIX

2020-08-13 Thread Joel Sherrill

On Wed, Aug 12, 2020 at 11:56 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 13/08/2020 00:41, Joel Sherrill wrote:
>
> > Hi
> >
> > I was poking at updating the Compliance Spreadsheet to track what
> > Eshan has been doing this summer. POSIX requires crypt with crypt_r
> > being a GNU extension.
> >
> > https://pubs.opengroup.org/onlinepubs/009695399/functions/crypt.html
> >
> > I don't see the basic POSIX method in our libcrypt.
> >
> > Did I miss something?
>
> It is not available. We also don't offer the Openwall extensions.
>

Why was crypt() removed? It is in the FreeBSD version at the bottom of the
file.

https://github.com/freebsd/freebsd/blob/master/lib/libcrypt/crypt.c

The Openwall extensions are another matter completely.

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: crypt and POSIX

2020-08-13 Thread Sebastian Huber


On 13/08/2020 14:49, Joel Sherrill wrote:

Why was crypt() removed? It is in the FreeBSD version at the bottom of 
the file.


https://github.com/freebsd/freebsd/blob/master/lib/libcrypt/crypt.c

It is not thread-safe.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] Confstr Port for RTEMS

2020-08-13 Thread Joel Sherrill

I don't care where we provide it.

The list of names varies a bit based on the version of POSIX you are based
on.  We probably can just use the FreeBSD version minus the standard path
which makes no sense on RTEMS. They just detect you are running on a
supported environment or not. They only support one at a time like we do.

If it is libbsd, it stays up to date easier since we following FreeBSD
seems reasonable. Happy to see it deleted from libbsd and put in rtems
though since it doesn't have a bunch of dependencies.

On Thu, Aug 13, 2020 at 2:42 AM Chris Johns  wrote:

> On 13/8/20 3:54 pm, Sebastian Huber wrote:
> > On 12/08/2020 21:07, Gedare Bloom wrote:
> >
> >> Chris, Christian, Sebastian:
> >>
> >> I think it would be best if one of you may have insight on this
> touching libbsd.
> > Is libbsd really the right place for this function? Do we need the
> ability to
> > synchronize it with FreeBSD? Are FreeBSD and RTEMS similar enough to
> share an
> > implementation of confstr()?
>
> Good question, I am not sure. What is the list of `names` we have to
> support?
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: crypt and POSIX

2020-08-13 Thread Joel Sherrill

On Thu, Aug 13, 2020 at 7:52 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 13/08/2020 14:49, Joel Sherrill wrote:
>
> > Why was crypt() removed? It is in the FreeBSD version at the bottom of
> > the file.
> >
> > https://github.com/freebsd/freebsd/blob/master/lib/libcrypt/crypt.c
> It is not thread-safe.
>

Doh! But it is standards compliant.

And this would seem to violate the rules of source transparency in the
way the code was removed. If you wanted to disable it, it should have
been wrapped in ifndef __rtems__.

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/shared/ofw: Added and Documented RTEMS OFW interface

2020-08-13 Thread Gedare Bloom

On Thu, Aug 13, 2020 at 4:31 AM Niteesh G. S.  wrote:
>
> Hello,
> On Thu, Aug 13, 2020 at 12:09 PM Christian Mauderer 
>  wrote:
>>
>> Hello Niteesh,
>>
>> On 13/08/2020 07:05, Niteesh G. S. wrote:
>> > On Thu, Aug 13, 2020 at 12:36 AM Gedare Bloom > > > wrote:
>> >
>> > I make a few comments below for you to consider. At a high level, I
>> > think the interface looks reasonable, although plainly mimics the
>> > freebsd naming conventions. I wonder if we should prefer our naming
>> > conventions, which is to aim to use _ to separate different words, and
>> > to limit use of abbreviations except as they help shorten very long
>> > names?
>> >
>> > I might suggest something along these lines:
>> > rtems_ofw_get_prop_len() instead of rtems_ofw_getproplen() for example.
>> >
>> >
>> > I'll change them to RTEMS naming conventions.
>> >
>> >
>> > It will make mapping to FreeBSD a little more annoying, but will make
>> > the RTEMS interface more RTEMS-friendly.
>> >
>> > Other small comments below.
>> >
>> > On Wed, Aug 12, 2020 at 10:11 AM G S Niteesh Babu
>> > mailto:niteesh...@gmail.com>> wrote:
>> > >
>> > > ---
>> > >  bsps/shared/dev/ofw/ofw.c |   0
>> > >  bsps/shared/dev/ofw/ofw.h | 437
>> > ++
>> > >  2 files changed, 437 insertions(+)
>> > >  create mode 100644 bsps/shared/dev/ofw/ofw.c
>> > >  create mode 100644 bsps/shared/dev/ofw/ofw.h
>> > >
>> > > diff --git a/bsps/shared/dev/ofw/ofw.c b/bsps/shared/dev/ofw/ofw.c
>> > > new file mode 100644
>> > > index 00..e69de29bb2
>> > > diff --git a/bsps/shared/dev/ofw/ofw.h b/bsps/shared/dev/ofw/ofw.h
>> > > new file mode 100644
>> > > index 00..5a8526c892
>> > > --- /dev/null
>> > > +++ b/bsps/shared/dev/ofw/ofw.h
>> > > @@ -0,0 +1,437 @@
>> > > +/* SPDX-License-Identifier: BSD-2-Clause */
>> > > +
>> > > +/**
>> > > + * @file
>> > > + *
>> > > + * @ingroup ofw
>> > > + *
>> > > + * RTEMS FDT implementation of OpenFirmWare Interface.
>>
>> Maybe a short notice that the intention is to be compatible with the
>> FreeBSD OpenFirmWare interface would be nice. So if someone changes
>> something he knows that he has to take a look at FreeBSD too.
>
> OK. I'll add one.
>>
>> > > + */
>> > > +
>> > > +/*
>> > > + * Copyright (C) <2020> Niteesh Babu G S > > >
>> >
>> > no <> around year
>> >
>> > Fixed.
>> >
>> >
>> > > + *
>> > > + * Redistribution and use in source and binary forms, with or 
>> > without
>> > > + * modification, are permitted provided that the following 
>> > conditions
>> > > + * are met:
>> > > + * 1. Redistributions of source code must retain the above copyright
>> > > + *notice, this list of conditions and the following disclaimer.
>> > > + * 2. Redistributions in binary form must reproduce the above
>> > copyright
>> > > + *notice, this list of conditions and the following
>> > disclaimer in the
>> > > + *documentation and/or other materials provided with the
>> > distribution.
>> > > + *
>> > > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
>> > CONTRIBUTORS "AS IS"
>> > > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>> > LIMITED TO, THE
>> > > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
>> > PARTICULAR PURPOSE
>> > > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
>> > CONTRIBUTORS BE
>> > > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
>> > EXEMPLARY, OR
>> > > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
>> > PROCUREMENT OF
>> > > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
>> > OR BUSINESS
>> > > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
>> > WHETHER IN
>> > > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
>> > OTHERWISE)
>> > > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
>> > ADVISED OF THE
>> > > + * POSSIBILITY OF SUCH DAMAGE.
>> > > + */
>> > > +
>> > > +#ifndef _OFW_H
>> > > +#define _OFW_H
>> > > +
>> > > +#ifdef __cplusplus
>> > > +extern "C" {
>> > > +#endif
>> > > +
>> > > +#include 
>> > > +#include 
>> > > +
>> > > +typedef uint32_t  ihandle_t;
>> > > +typedef uint32_t  pcell_t;
>> > > +typedef uint32_t  phandle_t;
>> > document the types?
>> >
>> > I'll document them. I should document their use right? Like what
>> > ihandle_t, phandle_t represent.
>> >

I thought of one more little complaint. These types are non-standard,
and the _t is reserved for standards.

Should we introduce our own type names here, and then also map them
into the freeBSD type names?

>> > > +
>> >

Re: Need help in figuring out how to allocate sizes to the array

2020-08-13 Thread Richi Dubey

Thanks,
 I am assuming this is the code that allocates space:

 #define RTEMS_SCHEDULER_EDF_SMP( name ) \
>  static struct { \
>Scheduler_EDF_SMP_Context Base; \
>Scheduler_EDF_SMP_Ready_queue Ready[ CONFIGURE_MAXIMUM_PROCESSORS
> + 1 ]; \
>  } SCHEDULER_EDF_SMP_CONTEXT_NAME( name )


How do we use or refer to this 'Base'? How do we link this 'Ready' to the
'Ready' inside the EDF_SMP_Context?

On Thu, Aug 13, 2020 at 6:17 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
>
> On 13/08/2020 14:42, Richi Dubey wrote:
>
> > I want to use arrays with size _CONFIGURE_MAXIMUM_PROCESSORS. Is it
> > okay if I define the arrays with this size while writing the scheduler
> > strong APA header file? I am asking this because the value of this
> > header gets defined at the time the test case runs while the scheduler
> > gets linked to the test case at the time of linking. So how would it
> > work?
>
> Do NOT use _CONFIGURE_MAXIMUM_PROCESSORS.
>
> In  please use something similar to the EDF scheduler
> instantiation:
>
> #ifdef CONFIGURE_SCHEDULER_EDF_SMP
>#include 
>
>#ifndef CONFIGURE_MAXIMUM_PROCESSORS
>  #error "CONFIGURE_MAXIMUM_PROCESSORS must be defined to configure
> the EDF SMP scheduler"
>#endif
>
>#define SCHEDULER_EDF_SMP_CONTEXT_NAME( name ) \
>  SCHEDULER_CONTEXT_NAME( EDF_SMP_ ## name )
>
>#define RTEMS_SCHEDULER_EDF_SMP( name ) \
>  static struct { \
>Scheduler_EDF_SMP_Context Base; \
>Scheduler_EDF_SMP_Ready_queue Ready[ CONFIGURE_MAXIMUM_PROCESSORS
> + 1 ]; \
>  } SCHEDULER_EDF_SMP_CONTEXT_NAME( name )
>
>#define RTEMS_SCHEDULER_TABLE_EDF_SMP( name, obj_name ) \
>  { \
>&SCHEDULER_EDF_SMP_CONTEXT_NAME( name ).Base.Base.Base, \
>SCHEDULER_EDF_SMP_ENTRY_POINTS, \
>SCHEDULER_EDF_MAXIMUM_PRIORITY, \
>( obj_name ) \
>SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( false ) \
>  }
>
>/* Provided for backward compatibility */
>
>#define RTEMS_SCHEDULER_CONTEXT_EDF_SMP( name, max_cpu_count ) \
>  RTEMS_SCHEDULER_EDF_SMP( name )
>
>#define RTEMS_SCHEDULER_CONTROL_EDF_SMP( name, obj_name ) \
>  RTEMS_SCHEDULER_TABLE_EDF_SMP( name, obj_name )
> #endif
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Strict thread stack isolation and sharing

2020-08-13 Thread Utkarsh Rai

Following is the complete set of changes for thread stack isolation and
sharing.

Configuration for thread stack isolation.
> The configuration for thread stack isolation is based upon the new build
system.
> The RTEMS_THREAD_STACK_PROTECTION option needs to be specified and set to
'True'
   for enabling thread stack protection.
> I have used the realview_pbx_a9 BSP which already has support for small
pages. We need different page configuration options based upon whether the
architecture supports MMU or MPU.

Application requirements for stack sharing -
 > Naming for shared memory objects is done in the application and the name
follows a fixed naming pattern ( "/taskfs/" ), this is used to
differentiate between a normal mmap operation and a stack sharing operation.
> We need to explicitly allocate stack memory from the application for
stack sharing, and then set through pthread_attr_setstack*()
> Any application has to specify a series of repetitive steps (shm_open,
ftruncate, mmap) for sharing a particular thread-stack. Maybe this can be
wrapped under a function ((rtems_share_stack() ?) ) and we only make a call
to that function every time we have to share a thread stack.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Strict thread-stack isolation and thread-stack sharing.

2020-08-13 Thread Utkarsh Rai

-This patch provides thread-stack isolation and thread-stack sharing
 mechanism for a POSIX thread.

-The patches are based on sebastian's build-2 branch of sebastian's repo 
https://git.rtems.org/sebh

-Configurations options are provided by using the new-build system. Refer to 
https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf,
 chapter 7,for basic setup and 
https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf(chapter 9) for the 
internals of the build system.
---
 .../realview-pbx-a9/mmu/bsp-set-mmu-attr.c|  75 ++
 bsps/shared/start/stackalloc.c|  12 +-
 .../libbsp/arm/realview-pbx-a9/Makefile.am|   3 +
 cpukit/Makefile.am|   1 +
 cpukit/headers.am |   2 +
 cpukit/include/rtems/score/memoryprotection.h |  91 
 cpukit/include/rtems/score/stack.h|  49 +++
 cpukit/include/rtems/score/stackprotection.h  |  80 +++
 cpukit/include/rtems/score/thread.h   |   1 +
 cpukit/posix/src/mmap.c   |  41 +-
 cpukit/posix/src/shmwkspace.c |  46 +-
 cpukit/score/cpu/arm/cpu_asm.S|  94 
 cpukit/score/src/stackprotection.c| 103 +
 cpukit/score/src/threadhandler.c  |   6 +
 cpukit/score/src/threadinitialize.c   |   9 ++
 .../arm/realview-pbx-a9/bsprealviewpbxa9.yml  |   1 +
 spec/build/cpukit/cpuopts.yml |   2 +
 spec/build/cpukit/librtemscpu.yml |   3 +
 .../build/cpukit/optthreadstackprotection.yml |  16 +++
 spec/build/testsuites/samples/grp.yml |   4 +
 .../samples/threadstackprotection.yml |  19 +++
 .../testsuites/samples/threadstacksharing.yml |  19 +++
 testsuites/samples/Makefile.am|  16 +++
 testsuites/samples/configure.ac   |   2 +
 .../samples/thread_stack_protection/init.c| 112 +++
 .../thread_stack_protection.doc   |   2 +
 .../thread_stack_protection.scn   |  20 +++
 .../samples/thread_stack_sharing/init.c   | 136 ++
 28 files changed, 959 insertions(+), 6 deletions(-)
 create mode 100644 bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
 create mode 100644 cpukit/include/rtems/score/memoryprotection.h
 create mode 100644 cpukit/include/rtems/score/stackprotection.h
 create mode 100644 cpukit/score/src/stackprotection.c
 create mode 100644 spec/build/cpukit/optthreadstackprotection.yml
 create mode 100644 spec/build/testsuites/samples/threadstackprotection.yml
 create mode 100644 spec/build/testsuites/samples/threadstacksharing.yml
 create mode 100644 testsuites/samples/thread_stack_protection/init.c
 create mode 100644 
testsuites/samples/thread_stack_protection/thread_stack_protection.doc
 create mode 100644 
testsuites/samples/thread_stack_protection/thread_stack_protection.scn
 create mode 100644 testsuites/samples/thread_stack_sharing/init.c

diff --git a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c 
b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
new file mode 100644
index 00..c3b469dd2a
--- /dev/null
+++ b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
@@ -0,0 +1,75 @@
+#include 
+#include 
+#include 
+#include 
+
+static uint32_t translate_flags(uint32_t attr_flags)
+{
+  uint32_t flags;
+  uint32_t memory_attribute;
+
+  switch (attr_flags)
+  {
+case RTEMS_READ_WRITE: 
+ flags = ARMV7_MMU_READ_WRITE;
+ break;
+
+case RTEMS_READ_ONLY:
+ flags = ARMV7_MMU_READ_ONLY;
+ break;
+
+case RTEMS_NO_ACCESS:
+default:
+ flags = 0;
+ break;
+  }
+
+ /*
+  * Check for memory-cache operation 
+  */
+  if( attr_flags & RTEMS_MEMORY_CACHED ) {
+flags |= ARM_MMU_SECT_TEX_0 | ARM_MMU_SECT_C | ARM_MMU_SECT_B;
+  }
+
+  return flags;
+}
+
+void _Memory_protection_Set_entries(uintptr_t begin, size_t size, uint32_t 
flags)
+{
+  uintptr_t end;
+  rtems_interrupt_level irq_level;
+  uint32_t access_flags;
+  
+  if(begin != NULL ) {
+end = begin + size;
+access_flags = translate_flags(flags);
+
+/*
+ * The ARM reference manual instructs to disable all the interrupts before
+ * setting up page table entries.
+ */
+rtems_interrupt_disable(irq_level);
+arm_cp15_set_translation_table_entries(begin, end, access_flags); 
+rtems_interrupt_enable(irq_level);
+  }
+}
+
+void _Memory_protection_Unset_entries(uintptr_t begin, size_t size)
+{
+  uint32_t access_flags;
+  uintptr_t end;
+  rtems_interrupt_level irq_level;
+  
+  if( begin != NULL ) {
+end = begin + size;
+access_flags = translate_flags( RTEMS_NO_ACCESS );
+
+/*
+ *  The ARM reference manual instructs to disable all the interrupts before
+ * setting up page table entries.
+ */
+rtems_interrupt_disable(irq_level);
+arm_cp15_set_translation_table_entries(begin, end, access_flags); 
+rtems_interrupt_enable(irq_level);
+  }
+}
\ No newline at end of file
diff --git

Re: Need help in figuring out how to allocate sizes to the array

2020-08-13 Thread Gedare Bloom

On Thu, Aug 13, 2020 at 8:34 AM Richi Dubey  wrote:
>
> Thanks,
>  I am assuming this is the code that allocates space:
>
>>  #define RTEMS_SCHEDULER_EDF_SMP( name ) \
>>  static struct { \
>>Scheduler_EDF_SMP_Context Base; \
>>Scheduler_EDF_SMP_Ready_queue Ready[ CONFIGURE_MAXIMUM_PROCESSORS
>> + 1 ]; \
>>  } SCHEDULER_EDF_SMP_CONTEXT_NAME( name )
>
This is declaring a structure type that will have a particular format
of the struct name.

>
> How do we use or refer to this 'Base'? How do we link this 'Ready' to the 
> 'Ready' inside the EDF_SMP_Context?
>

This stuff gets set up during confdefs step. Eventually the scheduler
contexts are instantiated in the scheduler table.

confdefs/scheduler.h:
#define CONFIGURE_SCHEDULER RTEMS_SCHEDULER_EDF_SMP( dflt )

#define CONFIGURE_SCHEDULER_TABLE_ENTRIES \
  RTEMS_SCHEDULER_TABLE_EDF_SMP( dflt, CONFIGURE_SCHEDULER_NAME )

const Scheduler_Control _Scheduler_Table[] = {
  CONFIGURE_SCHEDULER_TABLE_ENTRIES
};

This is where the space actually gets allocated, based on how
CONFIGURE_SCHEDULER_TABLE_ENTRIES gets defined up to here from the CPP
macros.



> On Thu, Aug 13, 2020 at 6:17 PM Sebastian Huber 
>  wrote:
> >
> > On 13/08/2020 14:42, Richi Dubey wrote:
> >
> > > I want to use arrays with size _CONFIGURE_MAXIMUM_PROCESSORS. Is it
> > > okay if I define the arrays with this size while writing the scheduler
> > > strong APA header file? I am asking this because the value of this
> > > header gets defined at the time the test case runs while the scheduler
> > > gets linked to the test case at the time of linking. So how would it
> > > work?
> >
> > Do NOT use _CONFIGURE_MAXIMUM_PROCESSORS.
> >
> > In  please use something similar to the EDF scheduler
> > instantiation:
> >
> > #ifdef CONFIGURE_SCHEDULER_EDF_SMP
> >#include 
> >
> >#ifndef CONFIGURE_MAXIMUM_PROCESSORS
> >  #error "CONFIGURE_MAXIMUM_PROCESSORS must be defined to configure
> > the EDF SMP scheduler"
> >#endif
> >
> >#define SCHEDULER_EDF_SMP_CONTEXT_NAME( name ) \
> >  SCHEDULER_CONTEXT_NAME( EDF_SMP_ ## name )
> >
> >#define RTEMS_SCHEDULER_EDF_SMP( name ) \
> >  static struct { \
> >Scheduler_EDF_SMP_Context Base; \
> >Scheduler_EDF_SMP_Ready_queue Ready[ CONFIGURE_MAXIMUM_PROCESSORS
> > + 1 ]; \
> >  } SCHEDULER_EDF_SMP_CONTEXT_NAME( name )
> >
> >#define RTEMS_SCHEDULER_TABLE_EDF_SMP( name, obj_name ) \
> >  { \
> >&SCHEDULER_EDF_SMP_CONTEXT_NAME( name ).Base.Base.Base, \
> >SCHEDULER_EDF_SMP_ENTRY_POINTS, \
> >SCHEDULER_EDF_MAXIMUM_PRIORITY, \
> >( obj_name ) \
> >SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( false ) \
> >  }
> >
> >/* Provided for backward compatibility */
> >
> >#define RTEMS_SCHEDULER_CONTEXT_EDF_SMP( name, max_cpu_count ) \
> >  RTEMS_SCHEDULER_EDF_SMP( name )
> >
> >#define RTEMS_SCHEDULER_CONTROL_EDF_SMP( name, obj_name ) \
> >  RTEMS_SCHEDULER_TABLE_EDF_SMP( name, obj_name )
> > #endif
> >
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2] cpukit: Edit String Warninng

2020-08-13 Thread Aschref Ben-Thabet

From: Aschref Ben Thabet 

Using FILENAME_MAX as a parameter in strncpy function can gererate
warnings of type: -Wstringop-truncation. Replacing it with sizeof
(distination_buffer) can avoid this warning.
---
 cpukit/libmisc/shell/main_edit.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/cpukit/libmisc/shell/main_edit.c b/cpukit/libmisc/shell/main_edit.c
index 6e88916ad0..feefd6bff1 100644
--- a/cpukit/libmisc/shell/main_edit.c
+++ b/cpukit/libmisc/shell/main_edit.c
@@ -286,7 +286,7 @@ static struct editor *find_editor(struct env *env, char 
*filename) {
   struct editor *ed = env->current;
   struct editor *start = ed;
 
-  if (!realpath(filename, fn)) memcpy(fn, filename, FILENAME_MAX);
+  if (!realpath(filename, fn)) strncpy(fn, filename, sizeof(fn)-1);
 
   do {
 if (strcmp(fn, ed->filename) == 0) return ed;
@@ -297,8 +297,9 @@ static struct editor *find_editor(struct env *env, char 
*filename) {
 
 static int new_file(struct editor *ed, char *filename) {
   if (*filename) {
-memcpy(ed->filename, filename, FILENAME_MAX);
-  } else {
+  strncpy(ed->filename, filename, sizeof(ed->filename)-1);
+  }
+  else {
 sprintf(ed->filename, "Untitled-%d", ++ed->env->untitled);
 ed->newfile = 1;
   }
@@ -1775,8 +1776,8 @@ static void save_editor(struct editor *ed) {
 return;
   }
 }
-memcpy(
-  ed->filename, (const char*) ed->env->linebuf, FILENAME_MAX);
+strncpy(
+ed->filename, (const char*)ed->env->linebuf, sizeof(ed->filename)-1);
 ed->newfile = 0;
   }
 
-- 
2.26.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Need help in figuring out how to allocate sizes to the array

2020-08-13 Thread Richi Dubey

Thanks,

But I still can't find the code that links the 'Ready' in this

>>  #define RTEMS_SCHEDULER_EDF_SMP( name ) \
>>  static struct { \
>>Scheduler_EDF_SMP_Context Base; \
>>Scheduler_EDF_SMP_Ready_queue Ready[ CONFIGURE_MAXIMUM_PROCESSORS
>> + 1 ]; \

to the 'Ready' in scheduleredfsmp.h:

typedef struct {
  Scheduler_SMP_Context Base;

  /**
   * @brief Current generation for LIFO (index 0) and FIFO (index 1)
ordering.
   */
  int64_t generations[ 2 ];

  /**
   * @brief Chain of ready queues with affine threads to determine the
highest
   * priority ready thread.
   */
  Chain_Control Affine_queues;

  /**
   * @brief A table with ready queues.
   *
   * The index zero queue is used for threads with a one-to-all processor
   * affinity.  Index one corresponds to processor index zero, and so on.
   */
  Scheduler_EDF_SMP_Ready_queue Ready[ RTEMS_ZERO_LENGTH_ARRAY ];
} Scheduler_EDF_SMP_Context;

If I figure this out, everything else would make sense too. Please help me
out.

On Thu, Aug 13, 2020 at 8:47 PM Gedare Bloom  wrote:

> On Thu, Aug 13, 2020 at 8:34 AM Richi Dubey  wrote:
> >
> > Thanks,
> >  I am assuming this is the code that allocates space:
> >
> >>  #define RTEMS_SCHEDULER_EDF_SMP( name ) \
> >>  static struct { \
> >>Scheduler_EDF_SMP_Context Base; \
> >>Scheduler_EDF_SMP_Ready_queue Ready[ CONFIGURE_MAXIMUM_PROCESSORS
> >> + 1 ]; \
> >>  } SCHEDULER_EDF_SMP_CONTEXT_NAME( name )
> >
> This is declaring a structure type that will have a particular format
> of the struct name.
>
> >
> > How do we use or refer to this 'Base'? How do we link this 'Ready' to
> the 'Ready' inside the EDF_SMP_Context?
> >
>
> This stuff gets set up during confdefs step. Eventually the scheduler
> contexts are instantiated in the scheduler table.
>
> confdefs/scheduler.h:
> #define CONFIGURE_SCHEDULER RTEMS_SCHEDULER_EDF_SMP( dflt )
>
> #define CONFIGURE_SCHEDULER_TABLE_ENTRIES \
>   RTEMS_SCHEDULER_TABLE_EDF_SMP( dflt, CONFIGURE_SCHEDULER_NAME )
> 
> const Scheduler_Control _Scheduler_Table[] = {
>   CONFIGURE_SCHEDULER_TABLE_ENTRIES
> };
>
> This is where the space actually gets allocated, based on how
> CONFIGURE_SCHEDULER_TABLE_ENTRIES gets defined up to here from the CPP
> macros.
>
>
>
> > On Thu, Aug 13, 2020 at 6:17 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> > >
> > > On 13/08/2020 14:42, Richi Dubey wrote:
> > >
> > > > I want to use arrays with size _CONFIGURE_MAXIMUM_PROCESSORS. Is it
> > > > okay if I define the arrays with this size while writing the
> scheduler
> > > > strong APA header file? I am asking this because the value of this
> > > > header gets defined at the time the test case runs while the
> scheduler
> > > > gets linked to the test case at the time of linking. So how would it
> > > > work?
> > >
> > > Do NOT use _CONFIGURE_MAXIMUM_PROCESSORS.
> > >
> > > In  please use something similar to the EDF
> scheduler
> > > instantiation:
> > >
> > > #ifdef CONFIGURE_SCHEDULER_EDF_SMP
> > >#include 
> > >
> > >#ifndef CONFIGURE_MAXIMUM_PROCESSORS
> > >  #error "CONFIGURE_MAXIMUM_PROCESSORS must be defined to configure
> > > the EDF SMP scheduler"
> > >#endif
> > >
> > >#define SCHEDULER_EDF_SMP_CONTEXT_NAME( name ) \
> > >  SCHEDULER_CONTEXT_NAME( EDF_SMP_ ## name )
> > >
> > >#define RTEMS_SCHEDULER_EDF_SMP( name ) \
> > >  static struct { \
> > >Scheduler_EDF_SMP_Context Base; \
> > >Scheduler_EDF_SMP_Ready_queue Ready[
> CONFIGURE_MAXIMUM_PROCESSORS
> > > + 1 ]; \
> > >  } SCHEDULER_EDF_SMP_CONTEXT_NAME( name )
> > >
> > >#define RTEMS_SCHEDULER_TABLE_EDF_SMP( name, obj_name ) \
> > >  { \
> > >&SCHEDULER_EDF_SMP_CONTEXT_NAME( name ).Base.Base.Base, \
> > >SCHEDULER_EDF_SMP_ENTRY_POINTS, \
> > >SCHEDULER_EDF_MAXIMUM_PRIORITY, \
> > >( obj_name ) \
> > >SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( false ) \
> > >  }
> > >
> > >/* Provided for backward compatibility */
> > >
> > >#define RTEMS_SCHEDULER_CONTEXT_EDF_SMP( name, max_cpu_count ) \
> > >  RTEMS_SCHEDULER_EDF_SMP( name )
> > >
> > >#define RTEMS_SCHEDULER_CONTROL_EDF_SMP( name, obj_name ) \
> > >  RTEMS_SCHEDULER_TABLE_EDF_SMP( name, obj_name )
> > > #endif
> > >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v3] cpukit: Edit String Warninng

2020-08-13 Thread Aschref Ben-Thabet

From: Aschref Ben Thabet 

Using FILENAME_MAX as a parameter in strncpy function can gererate
warnings of type: -Wstringop-truncation. Replacing it with sizeof
(distination_buffer) can avoid this warning.
---
 cpukit/libmisc/shell/main_edit.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/cpukit/libmisc/shell/main_edit.c b/cpukit/libmisc/shell/main_edit.c
index e43ff68d2b..feefd6bff1 100644
--- a/cpukit/libmisc/shell/main_edit.c
+++ b/cpukit/libmisc/shell/main_edit.c
@@ -286,7 +286,7 @@ static struct editor *find_editor(struct env *env, char 
*filename) {
   struct editor *ed = env->current;
   struct editor *start = ed;
 
-  if (!realpath(filename, fn)) strncpy(fn, filename, FILENAME_MAX);
+  if (!realpath(filename, fn)) strncpy(fn, filename, sizeof(fn)-1);
 
   do {
 if (strcmp(fn, ed->filename) == 0) return ed;
@@ -297,8 +297,9 @@ static struct editor *find_editor(struct env *env, char 
*filename) {
 
 static int new_file(struct editor *ed, char *filename) {
   if (*filename) {
-strncpy(ed->filename, filename, FILENAME_MAX);
-  } else {
+  strncpy(ed->filename, filename, sizeof(ed->filename)-1);
+  }
+  else {
 sprintf(ed->filename, "Untitled-%d", ++ed->env->untitled);
 ed->newfile = 1;
   }
@@ -1776,7 +1777,7 @@ static void save_editor(struct editor *ed) {
   }
 }
 strncpy(
-  ed->filename, (const char*) ed->env->linebuf, FILENAME_MAX);
+ed->filename, (const char*)ed->env->linebuf, sizeof(ed->filename)-1);
 ed->newfile = 0;
   }
 
-- 
2.26.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] cpukit: Edit String Warninng

2020-08-13 Thread Aschref Ben-Thabet


Sorry it was not against master !
i send then V3 for this patch.

On 8/13/20 5:19 PM, Aschref Ben-Thabet wrote:

From: Aschref Ben Thabet 

Using FILENAME_MAX as a parameter in strncpy function can gererate
warnings of type: -Wstringop-truncation. Replacing it with sizeof
(distination_buffer) can avoid this warning.
---
  cpukit/libmisc/shell/main_edit.c | 11 ++-
  1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/cpukit/libmisc/shell/main_edit.c b/cpukit/libmisc/shell/main_edit.c
index 6e88916ad0..feefd6bff1 100644
--- a/cpukit/libmisc/shell/main_edit.c
+++ b/cpukit/libmisc/shell/main_edit.c
@@ -286,7 +286,7 @@ static struct editor *find_editor(struct env *env, char 
*filename) {
struct editor *ed = env->current;
struct editor *start = ed;
  
-  if (!realpath(filename, fn)) memcpy(fn, filename, FILENAME_MAX);

+  if (!realpath(filename, fn)) strncpy(fn, filename, sizeof(fn)-1);
  
do {

  if (strcmp(fn, ed->filename) == 0) return ed;
@@ -297,8 +297,9 @@ static struct editor *find_editor(struct env *env, char 
*filename) {
  
  static int new_file(struct editor *ed, char *filename) {

if (*filename) {
-memcpy(ed->filename, filename, FILENAME_MAX);
-  } else {
+  strncpy(ed->filename, filename, sizeof(ed->filename)-1);
+  }
+  else {
  sprintf(ed->filename, "Untitled-%d", ++ed->env->untitled);
  ed->newfile = 1;
}
@@ -1775,8 +1776,8 @@ static void save_editor(struct editor *ed) {
  return;
}
  }
-memcpy(
-  ed->filename, (const char*) ed->env->linebuf, FILENAME_MAX);
+strncpy(
+ed->filename, (const char*)ed->env->linebuf, sizeof(ed->filename)-1);
  ed->newfile = 0;
}
  


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v4] Psxtest : Fix String Turncation warning

2020-08-13 Thread Aschref Ben-Thabet

From: Aschref Ben Thabet 

replace strncpy with strdup to silence this warning since it tries to
allocate enough memory to hold the old string (plus a '\0' character
to mark the end of the string).
---
 testsuites/psxtests/psxndbm01/init.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/testsuites/psxtests/psxndbm01/init.c 
b/testsuites/psxtests/psxndbm01/init.c
index a13afa7315..cb4d1aca66 100644
--- a/testsuites/psxtests/psxndbm01/init.c
+++ b/testsuites/psxtests/psxndbm01/init.c
@@ -217,10 +217,7 @@ rtems_task Init(rtems_task_argument ignored)
   rtems_test_assert( strcmp( (const char*)get_phone_no.dptr, PHONE_NO2 ) == 0 
);
 
   puts( "Fetch non-existing record and confirm error." );
-  test_strings = (char*)malloc(6);
-  strncpy( test_strings, "Hello", 5 );
-
-  test_strings[5] = '\0';
+  test_strings = strdup( "Hello" );
 
 /* The data pointed by test_string is now pointed by key.dptr */
   key.dptr = test_strings;
-- 
2.26.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Strict thread-stack isolation and thread-stack sharing.

2020-08-13 Thread Gedare Bloom

On Thu, Aug 13, 2020 at 9:06 AM Utkarsh Rai  wrote:
>
> -This patch provides thread-stack isolation and thread-stack sharing
>  mechanism for a POSIX thread.
>
Monster patch! think to yourself whether or not it makes sense to
split these up. The main constraint is that every patch in the series
should compile/run as they are applied.

> -The patches are based on sebastian's build-2 branch of sebastian's repo 
> https://git.rtems.org/sebh
>
> -Configurations options are provided by using the new-build system. Refer to 
> https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf,
>  chapter 7,for basic setup and 
> https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf(chapter 9) for the 
> internals of the build system.
> ---
>  .../realview-pbx-a9/mmu/bsp-set-mmu-attr.c|  75 ++
>  bsps/shared/start/stackalloc.c|  12 +-
>  .../libbsp/arm/realview-pbx-a9/Makefile.am|   3 +
>  cpukit/Makefile.am|   1 +
>  cpukit/headers.am |   2 +
>  cpukit/include/rtems/score/memoryprotection.h |  91 
>  cpukit/include/rtems/score/stack.h|  49 +++
>  cpukit/include/rtems/score/stackprotection.h  |  80 +++
>  cpukit/include/rtems/score/thread.h   |   1 +
>  cpukit/posix/src/mmap.c   |  41 +-
>  cpukit/posix/src/shmwkspace.c |  46 +-
>  cpukit/score/cpu/arm/cpu_asm.S|  94 
>  cpukit/score/src/stackprotection.c| 103 +
>  cpukit/score/src/threadhandler.c  |   6 +
>  cpukit/score/src/threadinitialize.c   |   9 ++
>  .../arm/realview-pbx-a9/bsprealviewpbxa9.yml  |   1 +
>  spec/build/cpukit/cpuopts.yml |   2 +
>  spec/build/cpukit/librtemscpu.yml |   3 +
>  .../build/cpukit/optthreadstackprotection.yml |  16 +++
>  spec/build/testsuites/samples/grp.yml |   4 +
>  .../samples/threadstackprotection.yml |  19 +++
>  .../testsuites/samples/threadstacksharing.yml |  19 +++
>  testsuites/samples/Makefile.am|  16 +++
>  testsuites/samples/configure.ac   |   2 +
>  .../samples/thread_stack_protection/init.c| 112 +++
>  .../thread_stack_protection.doc   |   2 +
>  .../thread_stack_protection.scn   |  20 +++
>  .../samples/thread_stack_sharing/init.c   | 136 ++
>  28 files changed, 959 insertions(+), 6 deletions(-)
>  create mode 100644 bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>  create mode 100644 cpukit/include/rtems/score/memoryprotection.h
>  create mode 100644 cpukit/include/rtems/score/stackprotection.h
>  create mode 100644 cpukit/score/src/stackprotection.c
>  create mode 100644 spec/build/cpukit/optthreadstackprotection.yml
>  create mode 100644 spec/build/testsuites/samples/threadstackprotection.yml
>  create mode 100644 spec/build/testsuites/samples/threadstacksharing.yml
>  create mode 100644 testsuites/samples/thread_stack_protection/init.c
>  create mode 100644 
> testsuites/samples/thread_stack_protection/thread_stack_protection.doc
>  create mode 100644 
> testsuites/samples/thread_stack_protection/thread_stack_protection.scn
>  create mode 100644 testsuites/samples/thread_stack_sharing/init.c
>
> diff --git a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c 
> b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
> new file mode 100644
> index 00..c3b469dd2a
> --- /dev/null
> +++ b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
> @@ -0,0 +1,75 @@
file header block?

> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static uint32_t translate_flags(uint32_t attr_flags)
> +{
> +  uint32_t flags;
> +  uint32_t memory_attribute;
> +
> +  switch (attr_flags)
> +  {
> +case RTEMS_READ_WRITE:
> + flags = ARMV7_MMU_READ_WRITE;
> + break;
> +
> +case RTEMS_READ_ONLY:
> + flags = ARMV7_MMU_READ_ONLY;
> + break;
> +
> +case RTEMS_NO_ACCESS:
> +default:
> + flags = 0;
> + break;
> +  }

Does this switch statement work when the attr_flags have other fields
defined such as RTEMS_MEMORY_CACHED?

When bit flags are not mutually exclusive it makes more sense to write as...

if ( (attr_flags & RTEMS_READ_WRITE) == RTEMS_READ_WRITE) ) {
   ...
}
if ( ... ) {
  ...
}
Maybe it makes more sense to write your helper function this way?

> +
> + /*
> +  * Check for memory-cache operation
> +  */
> +  if( attr_flags & RTEMS_MEMORY_CACHED ) {
> +flags |= ARM_MMU_SECT_TEX_0 | ARM_MMU_SECT_C | ARM_MMU_SECT_B;
> +  }
> +
> +  return flags;
> +}
> +
> +void _Memory_protection_Set_entries(uintptr_t begin, size_t size, uint32_t 
> flags)
> +{
> +  uintptr_t end;
> +  rtems_interrupt_level irq_level;
> +  uint32_t access_flags;
> +
> +  if(begin != NULL ) {
whitespace: "if ( begin ..."

If begin is invalid, the set_entries fails. Maybe you want to return
an error code?

You might want to refactor a helper to validate the memory ra

Re: Need help in figuring out how to allocate sizes to the array

2020-08-13 Thread Gedare Bloom

On Thu, Aug 13, 2020 at 9:28 AM Richi Dubey  wrote:
>
> Thanks,
>
> But I still can't find the code that links the 'Ready' in this
>
> >>  #define RTEMS_SCHEDULER_EDF_SMP( name ) \
> >>  static struct { \
> >>Scheduler_EDF_SMP_Context Base; \
This 'Base' will be an instance of the struct
Scheduler_EDF_SMP_Context. In memory, it will look like this:
Scheduler_EDF_SMP_Context Base =
the 0-valued array won't actually take any storage.

> >>Scheduler_EDF_SMP_Ready_queue Ready[ CONFIGURE_MAXIMUM_PROCESSORS
This

> >> + 1 ]; \
>
In memory this structure will look like this:
{ Scheduler_SMP_Context, int64_t, Chain_Control,
Scheduler_EDF_SMP_Ready_queue[CONFIGURE_MAXIMUM_PROCESSORS + 1] }
Because the Scheduler_EDF_SMP_Context type comes first and provides
{ Scheduler_SMP_Context, int64_t, Chain_Control,
Scheduler_EDF_SMP_Ready_queue[0] } where the last element is a 0-value
array so it doesn't actually take up any memory storage, then the
Scheduler_EDF_SMP_Ready_queue Ready[ CONFIGURE_MAXIMUM_PROCESSORS + 1]
overlaps with the Scheduler_EDF_SMP_Ready_queue[0] because the end of
Base aligns with the start of Ready.

This is what I meant by you need to review how C struct layout works.



> to the 'Ready' in scheduleredfsmp.h:
>
> typedef struct {
>   Scheduler_SMP_Context Base;
>
>   /**
>* @brief Current generation for LIFO (index 0) and FIFO (index 1) ordering.
>*/
>   int64_t generations[ 2 ];
>
>   /**
>* @brief Chain of ready queues with affine threads to determine the highest
>* priority ready thread.
>*/
>   Chain_Control Affine_queues;
>
>   /**
>* @brief A table with ready queues.
>*
>* The index zero queue is used for threads with a one-to-all processor
>* affinity.  Index one corresponds to processor index zero, and so on.
>*/
>   Scheduler_EDF_SMP_Ready_queue Ready[ RTEMS_ZERO_LENGTH_ARRAY ];
> } Scheduler_EDF_SMP_Context;
>
> If I figure this out, everything else would make sense too. Please help me 
> out.
>
> On Thu, Aug 13, 2020 at 8:47 PM Gedare Bloom  wrote:
>>
>> On Thu, Aug 13, 2020 at 8:34 AM Richi Dubey  wrote:
>> >
>> > Thanks,
>> >  I am assuming this is the code that allocates space:
>> >
>> >>  #define RTEMS_SCHEDULER_EDF_SMP( name ) \
>> >>  static struct { \
>> >>Scheduler_EDF_SMP_Context Base; \
>> >>Scheduler_EDF_SMP_Ready_queue Ready[ CONFIGURE_MAXIMUM_PROCESSORS
>> >> + 1 ]; \
>> >>  } SCHEDULER_EDF_SMP_CONTEXT_NAME( name )
>> >
>> This is declaring a structure type that will have a particular format
>> of the struct name.
>>
>> >
>> > How do we use or refer to this 'Base'? How do we link this 'Ready' to the 
>> > 'Ready' inside the EDF_SMP_Context?
>> >
>>
>> This stuff gets set up during confdefs step. Eventually the scheduler
>> contexts are instantiated in the scheduler table.
>>
>> confdefs/scheduler.h:
>> #define CONFIGURE_SCHEDULER RTEMS_SCHEDULER_EDF_SMP( dflt )
>>
>> #define CONFIGURE_SCHEDULER_TABLE_ENTRIES \
>>   RTEMS_SCHEDULER_TABLE_EDF_SMP( dflt, CONFIGURE_SCHEDULER_NAME )
>> 
>> const Scheduler_Control _Scheduler_Table[] = {
>>   CONFIGURE_SCHEDULER_TABLE_ENTRIES
>> };
>>
>> This is where the space actually gets allocated, based on how
>> CONFIGURE_SCHEDULER_TABLE_ENTRIES gets defined up to here from the CPP
>> macros.
>>
>>
>>
>> > On Thu, Aug 13, 2020 at 6:17 PM Sebastian Huber 
>> >  wrote:
>> > >
>> > > On 13/08/2020 14:42, Richi Dubey wrote:
>> > >
>> > > > I want to use arrays with size _CONFIGURE_MAXIMUM_PROCESSORS. Is it
>> > > > okay if I define the arrays with this size while writing the scheduler
>> > > > strong APA header file? I am asking this because the value of this
>> > > > header gets defined at the time the test case runs while the scheduler
>> > > > gets linked to the test case at the time of linking. So how would it
>> > > > work?
>> > >
>> > > Do NOT use _CONFIGURE_MAXIMUM_PROCESSORS.
>> > >
>> > > In  please use something similar to the EDF scheduler
>> > > instantiation:
>> > >
>> > > #ifdef CONFIGURE_SCHEDULER_EDF_SMP
>> > >#include 
>> > >
>> > >#ifndef CONFIGURE_MAXIMUM_PROCESSORS
>> > >  #error "CONFIGURE_MAXIMUM_PROCESSORS must be defined to configure
>> > > the EDF SMP scheduler"
>> > >#endif
>> > >
>> > >#define SCHEDULER_EDF_SMP_CONTEXT_NAME( name ) \
>> > >  SCHEDULER_CONTEXT_NAME( EDF_SMP_ ## name )
>> > >
>> > >#define RTEMS_SCHEDULER_EDF_SMP( name ) \
>> > >  static struct { \
>> > >Scheduler_EDF_SMP_Context Base; \
>> > >Scheduler_EDF_SMP_Ready_queue Ready[ CONFIGURE_MAXIMUM_PROCESSORS
>> > > + 1 ]; \
>> > >  } SCHEDULER_EDF_SMP_CONTEXT_NAME( name )
>> > >
>> > >#define RTEMS_SCHEDULER_TABLE_EDF_SMP( name, obj_name ) \
>> > >  { \
>> > >&SCHEDULER_EDF_SMP_CONTEXT_NAME( name ).Base.Base.Base, \
>> > >SCHEDULER_EDF_SMP_ENTRY_POINTS, \
>> > >SCHEDULER_EDF_MAXIMUM_PRIORITY, \
>> > >( obj_name ) \
>> > >SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SU

Re: Need help in figuring out how to allocate sizes to the array

2020-08-13 Thread Gedare Bloom

Resending without some stray words

On Thu, Aug 13, 2020 at 10:10 AM Gedare Bloom  wrote:
>
> On Thu, Aug 13, 2020 at 9:28 AM Richi Dubey  wrote:
> >
> > Thanks,
> >
> > But I still can't find the code that links the 'Ready' in this
> >
> > >>  #define RTEMS_SCHEDULER_EDF_SMP( name ) \
> > >>  static struct { \
> > >>Scheduler_EDF_SMP_Context Base; \
> > >>Scheduler_EDF_SMP_Ready_queue Ready[ CONFIGURE_MAXIMUM_PROCESSORS
> > >> + 1 ]; \
> >
> In memory this structure will look like this:
> { Scheduler_SMP_Context, int64_t, Chain_Control,
> Scheduler_EDF_SMP_Ready_queue[CONFIGURE_MAXIMUM_PROCESSORS + 1] }
> Because the Scheduler_EDF_SMP_Context type comes first and provides
> { Scheduler_SMP_Context, int64_t, Chain_Control,
> Scheduler_EDF_SMP_Ready_queue[0] } where the last element is a 0-value
> array so it doesn't actually take up any memory storage, then the
> Scheduler_EDF_SMP_Ready_queue Ready[ CONFIGURE_MAXIMUM_PROCESSORS + 1]
> overlaps with the Scheduler_EDF_SMP_Ready_queue[0] because the end of
> Base aligns with the start of Ready.
>
> This is what I meant by you need to review how C struct layout works.
>
>
>
> > to the 'Ready' in scheduleredfsmp.h:
> >
> > typedef struct {
> >   Scheduler_SMP_Context Base;
> >
> >   /**
> >* @brief Current generation for LIFO (index 0) and FIFO (index 1) 
> > ordering.
> >*/
> >   int64_t generations[ 2 ];
> >
> >   /**
> >* @brief Chain of ready queues with affine threads to determine the 
> > highest
> >* priority ready thread.
> >*/
> >   Chain_Control Affine_queues;
> >
> >   /**
> >* @brief A table with ready queues.
> >*
> >* The index zero queue is used for threads with a one-to-all processor
> >* affinity.  Index one corresponds to processor index zero, and so on.
> >*/
> >   Scheduler_EDF_SMP_Ready_queue Ready[ RTEMS_ZERO_LENGTH_ARRAY ];
> > } Scheduler_EDF_SMP_Context;
> >
> > If I figure this out, everything else would make sense too. Please help me 
> > out.
> >
> > On Thu, Aug 13, 2020 at 8:47 PM Gedare Bloom  wrote:
> >>
> >> On Thu, Aug 13, 2020 at 8:34 AM Richi Dubey  wrote:
> >> >
> >> > Thanks,
> >> >  I am assuming this is the code that allocates space:
> >> >
> >> >>  #define RTEMS_SCHEDULER_EDF_SMP( name ) \
> >> >>  static struct { \
> >> >>Scheduler_EDF_SMP_Context Base; \
> >> >>Scheduler_EDF_SMP_Ready_queue Ready[ CONFIGURE_MAXIMUM_PROCESSORS
> >> >> + 1 ]; \
> >> >>  } SCHEDULER_EDF_SMP_CONTEXT_NAME( name )
> >> >
> >> This is declaring a structure type that will have a particular format
> >> of the struct name.
> >>
> >> >
> >> > How do we use or refer to this 'Base'? How do we link this 'Ready' to 
> >> > the 'Ready' inside the EDF_SMP_Context?
> >> >
> >>
> >> This stuff gets set up during confdefs step. Eventually the scheduler
> >> contexts are instantiated in the scheduler table.
> >>
> >> confdefs/scheduler.h:
> >> #define CONFIGURE_SCHEDULER RTEMS_SCHEDULER_EDF_SMP( dflt )
> >>
> >> #define CONFIGURE_SCHEDULER_TABLE_ENTRIES \
> >>   RTEMS_SCHEDULER_TABLE_EDF_SMP( dflt, CONFIGURE_SCHEDULER_NAME )
> >> 
> >> const Scheduler_Control _Scheduler_Table[] = {
> >>   CONFIGURE_SCHEDULER_TABLE_ENTRIES
> >> };
> >>
> >> This is where the space actually gets allocated, based on how
> >> CONFIGURE_SCHEDULER_TABLE_ENTRIES gets defined up to here from the CPP
> >> macros.
> >>
> >>
> >>
> >> > On Thu, Aug 13, 2020 at 6:17 PM Sebastian Huber 
> >> >  wrote:
> >> > >
> >> > > On 13/08/2020 14:42, Richi Dubey wrote:
> >> > >
> >> > > > I want to use arrays with size _CONFIGURE_MAXIMUM_PROCESSORS. Is it
> >> > > > okay if I define the arrays with this size while writing the 
> >> > > > scheduler
> >> > > > strong APA header file? I am asking this because the value of this
> >> > > > header gets defined at the time the test case runs while the 
> >> > > > scheduler
> >> > > > gets linked to the test case at the time of linking. So how would it
> >> > > > work?
> >> > >
> >> > > Do NOT use _CONFIGURE_MAXIMUM_PROCESSORS.
> >> > >
> >> > > In  please use something similar to the EDF 
> >> > > scheduler
> >> > > instantiation:
> >> > >
> >> > > #ifdef CONFIGURE_SCHEDULER_EDF_SMP
> >> > >#include 
> >> > >
> >> > >#ifndef CONFIGURE_MAXIMUM_PROCESSORS
> >> > >  #error "CONFIGURE_MAXIMUM_PROCESSORS must be defined to configure
> >> > > the EDF SMP scheduler"
> >> > >#endif
> >> > >
> >> > >#define SCHEDULER_EDF_SMP_CONTEXT_NAME( name ) \
> >> > >  SCHEDULER_CONTEXT_NAME( EDF_SMP_ ## name )
> >> > >
> >> > >#define RTEMS_SCHEDULER_EDF_SMP( name ) \
> >> > >  static struct { \
> >> > >Scheduler_EDF_SMP_Context Base; \
> >> > >Scheduler_EDF_SMP_Ready_queue Ready[ 
> >> > > CONFIGURE_MAXIMUM_PROCESSORS
> >> > > + 1 ]; \
> >> > >  } SCHEDULER_EDF_SMP_CONTEXT_NAME( name )
> >> > >
> >> > >#define RTEMS_SCHEDULER_TABLE_EDF_SMP( name, obj_name ) \
> >> > >  { \
> >> > >&SCHEDULER_EDF_SMP_CONTEXT_

Re: Need help in figuring out how to allocate sizes to the array

2020-08-13 Thread Richi Dubey

Great explanation. I feel stupid to miss this :p. Thanks!

On Thu, Aug 13, 2020 at 9:40 PM Gedare Bloom  wrote:

> On Thu, Aug 13, 2020 at 9:28 AM Richi Dubey  wrote:
> >
> > Thanks,
> >
> > But I still can't find the code that links the 'Ready' in this
> >
> > >>  #define RTEMS_SCHEDULER_EDF_SMP( name ) \
> > >>  static struct { \
> > >>Scheduler_EDF_SMP_Context Base; \
> This 'Base' will be an instance of the struct
> Scheduler_EDF_SMP_Context. In memory, it will look like this:
> Scheduler_EDF_SMP_Context Base =
> the 0-valued array won't actually take any storage.
>
> > >>Scheduler_EDF_SMP_Ready_queue Ready[
> CONFIGURE_MAXIMUM_PROCESSORS
> This
>
> > >> + 1 ]; \
> >
> In memory this structure will look like this:
> { Scheduler_SMP_Context, int64_t, Chain_Control,
> Scheduler_EDF_SMP_Ready_queue[CONFIGURE_MAXIMUM_PROCESSORS + 1] }
> Because the Scheduler_EDF_SMP_Context type comes first and provides
> { Scheduler_SMP_Context, int64_t, Chain_Control,
> Scheduler_EDF_SMP_Ready_queue[0] } where the last element is a 0-value
> array so it doesn't actually take up any memory storage, then the
> Scheduler_EDF_SMP_Ready_queue Ready[ CONFIGURE_MAXIMUM_PROCESSORS + 1]
> overlaps with the Scheduler_EDF_SMP_Ready_queue[0] because the end of
> Base aligns with the start of Ready.
>
> This is what I meant by you need to review how C struct layout works.
>
>
>
> > to the 'Ready' in scheduleredfsmp.h:
> >
> > typedef struct {
> >   Scheduler_SMP_Context Base;
> >
> >   /**
> >* @brief Current generation for LIFO (index 0) and FIFO (index 1)
> ordering.
> >*/
> >   int64_t generations[ 2 ];
> >
> >   /**
> >* @brief Chain of ready queues with affine threads to determine the
> highest
> >* priority ready thread.
> >*/
> >   Chain_Control Affine_queues;
> >
> >   /**
> >* @brief A table with ready queues.
> >*
> >* The index zero queue is used for threads with a one-to-all processor
> >* affinity.  Index one corresponds to processor index zero, and so on.
> >*/
> >   Scheduler_EDF_SMP_Ready_queue Ready[ RTEMS_ZERO_LENGTH_ARRAY ];
> > } Scheduler_EDF_SMP_Context;
> >
> > If I figure this out, everything else would make sense too. Please help
> me out.
> >
> > On Thu, Aug 13, 2020 at 8:47 PM Gedare Bloom  wrote:
> >>
> >> On Thu, Aug 13, 2020 at 8:34 AM Richi Dubey 
> wrote:
> >> >
> >> > Thanks,
> >> >  I am assuming this is the code that allocates space:
> >> >
> >> >>  #define RTEMS_SCHEDULER_EDF_SMP( name ) \
> >> >>  static struct { \
> >> >>Scheduler_EDF_SMP_Context Base; \
> >> >>Scheduler_EDF_SMP_Ready_queue Ready[
> CONFIGURE_MAXIMUM_PROCESSORS
> >> >> + 1 ]; \
> >> >>  } SCHEDULER_EDF_SMP_CONTEXT_NAME( name )
> >> >
> >> This is declaring a structure type that will have a particular format
> >> of the struct name.
> >>
> >> >
> >> > How do we use or refer to this 'Base'? How do we link this 'Ready' to
> the 'Ready' inside the EDF_SMP_Context?
> >> >
> >>
> >> This stuff gets set up during confdefs step. Eventually the scheduler
> >> contexts are instantiated in the scheduler table.
> >>
> >> confdefs/scheduler.h:
> >> #define CONFIGURE_SCHEDULER RTEMS_SCHEDULER_EDF_SMP( dflt )
> >>
> >> #define CONFIGURE_SCHEDULER_TABLE_ENTRIES \
> >>   RTEMS_SCHEDULER_TABLE_EDF_SMP( dflt, CONFIGURE_SCHEDULER_NAME )
> >> 
> >> const Scheduler_Control _Scheduler_Table[] = {
> >>   CONFIGURE_SCHEDULER_TABLE_ENTRIES
> >> };
> >>
> >> This is where the space actually gets allocated, based on how
> >> CONFIGURE_SCHEDULER_TABLE_ENTRIES gets defined up to here from the CPP
> >> macros.
> >>
> >>
> >>
> >> > On Thu, Aug 13, 2020 at 6:17 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >> > >
> >> > > On 13/08/2020 14:42, Richi Dubey wrote:
> >> > >
> >> > > > I want to use arrays with size _CONFIGURE_MAXIMUM_PROCESSORS. Is
> it
> >> > > > okay if I define the arrays with this size while writing the
> scheduler
> >> > > > strong APA header file? I am asking this because the value of this
> >> > > > header gets defined at the time the test case runs while the
> scheduler
> >> > > > gets linked to the test case at the time of linking. So how would
> it
> >> > > > work?
> >> > >
> >> > > Do NOT use _CONFIGURE_MAXIMUM_PROCESSORS.
> >> > >
> >> > > In  please use something similar to the EDF
> scheduler
> >> > > instantiation:
> >> > >
> >> > > #ifdef CONFIGURE_SCHEDULER_EDF_SMP
> >> > >#include 
> >> > >
> >> > >#ifndef CONFIGURE_MAXIMUM_PROCESSORS
> >> > >  #error "CONFIGURE_MAXIMUM_PROCESSORS must be defined to
> configure
> >> > > the EDF SMP scheduler"
> >> > >#endif
> >> > >
> >> > >#define SCHEDULER_EDF_SMP_CONTEXT_NAME( name ) \
> >> > >  SCHEDULER_CONTEXT_NAME( EDF_SMP_ ## name )
> >> > >
> >> > >#define RTEMS_SCHEDULER_EDF_SMP( name ) \
> >> > >  static struct { \
> >> > >Scheduler_EDF_SMP_Context Base; \
> >> > >Scheduler_EDF_SMP_Ready_queue Ready[
> CONFIGURE_MAXIMUM

Quick question: How do I get the name of the scheduler from _Scheduler_Control

2020-08-13 Thread Richi Dubey

Hi,

It's hard to find this with the help of cscope and I would appreciate your
help in this.

Is there a way to print the 'name' in :
--
struct _Scheduler_Control {
  /**
   * @brief Reference to a statically allocated scheduler context.
   */
  Scheduler_Context *context;

  /**
   * @brief The scheduler operations.
   */
  Scheduler_Operations Operations;

  /**
   * @brief The maximum priority value of this scheduler.
   *
   * It defines the lowest (least important) thread priority for this
   * scheduler.  For example the idle threads have this priority.
   */
  Priority_Control maximum_priority;

  /**
   * @brief The scheduler name.
   */
  uint32_t name;
--

as a string? Is there a function that maps this int to string?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Need help finding the cause of an ARM4 Exception

2020-08-13 Thread Richi Dubey

Thanks for your detailed reply. All this helped.

You should be able to print the exception context and see what are the
> values of some different registers. This might be helpful.

How do I do this? Right now I am printing individual variables that I find
important by using 'p'.

typedef struct
> {
>   bool visited[ RTEMS_ZERO_LENGTH_ARRAY ];
> } Scheduler_strong_APA_Visited;
> I don't see where this gets initialized.
> You have Scheduler_strong_APA_Visited *visited;
> inside of the context. Then you get
> visited = self->visited->visited;
> Probably this is now a pointer to a 0-length array, and you make a
> bunch of bad writes past the end of it.
>

Thanks for this observation. It has been resolved now.

This code is initializing the default scheduler context for strong
> apa. You need to make sure this initializer is in sync with the
> definition of the strong apa context structure layout. Right now, this
> is not matching up correctly with how you have defined
> Scheduler_strong_APA_Context;

Done.

>
> If there is code that casts a Scheduler_SMP_Node* to an
> Scheduler_strong_APA_Node* it will not work correctly the way you have
> structured the Scheduler_strong_APA_Node, because you have something
> (Chain_Node) in the structure prior to the Scheduler_SMP_Node.
> I think you need to review how C structs are laid out in memory.


Okay, that completely slipped from my view. That is corrected now. Thank
you

On Thu, Aug 13, 2020 at 2:20 AM Gedare Bloom  wrote:

> On Wed, Aug 12, 2020 at 2:28 PM Richi Dubey  wrote:
> >
> > Hi,
> >
> > Can someone please help me figure out why I am getting the
> _ARMV4_Exception_data_abort_default?
> >
> > I have attached the gdb script (Provided by Mr. Huber) that I used with
> this email. I have also printed the commands I have used to run gdb and
> qemu.
> >
> > I have provided my view on this exception and the link to PR with my
> changes at the end.
> >
> > qemu executed with the command:
> >
> --
> >  ./qemu-system-arm -net none -nographic -M realview-pbx-a9 -m 256M
> -kernel
> ~/quick-start/build/b3-realview/arm-rtems5/c/realview_pbx_a9_qemu/testsuites/smptests/smpstrongapa01.exe
> -smp 3 -S -s
> >
> >
> --
> >
> > GDB commands used:
> >
> --
> >
> >  ~/quick-start/rtems/5/bin$ ./arm-rtems5-gdb --command=arm.gdb
> ~/quick-start/build/b3-realview/arm-rtems5/c/realview_pbx_a9_qemu/testsuites/smptests/smpstrongapa01.exe
> > .
> > .
> > .
> > Loading section .fini_array, size 0x4 lma 0x121184
> > Loading section .rtemsroset, size 0x74 lma 0x121188
> > Loading section .data, size 0x530 lma 0x20
> > Start address 0x00100040, load size 136967
> > Transfer rate: 26751 KB/sec, 1778 bytes/write.
> > (gdb) continue
> > Continuing.
> >
> > Thread 1 hit Breakpoint 2, _ARMV4_Exception_data_abort_default () at
> /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/cpu/arm/armv4-exception-default.S:70
> > 70 sub sp, #MORE_CONTEXT_SIZE
> > (gdb) bt
> > #0  _ARMV4_Exception_data_abort_default () at
> /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/cpu/arm/armv4-exception-default.S:70
> > #1  0x00118c64 in _Scheduler_strong_APA_Get_lowest_scheduled
> (context=0x200620 <_Configuration_Scheduler_strong_APA_dflt>,
> filter_base=0x201910 <_RTEMS_tasks_Objects+600>) at
> /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/schedulerstrongapa.c:318
> > Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> > (gdb) reset
> > Loading section .start, size 0x8e0 lma 0x10
> > Loading section .text, size 0x1f00c lma 0x100900
> > Loading section .init, size 0xc lma 0x11f90c
> > Loading section .fini, size 0xc lma 0x11f918
> > Loading section .rodata, size 0x184b lma 0x11f928
> > Loading section .ARM.exidx, size 0x8 lma 0x121174
> > Loading section .eh_frame, size 0x4 lma 0x12117c
> > Loading section .init_array, size 0x4 lma 0x121180
> > Loading section .fini_array, size 0x4 lma 0x121184
> > Loading section .rtemsroset, size 0x74 lma 0x121188
> > Loading section .data, size 0x530 lma 0x20
> > Start address 0x00100040, load size 136967
> > Transfer rate: 8359 KB/sec, 1778 bytes/write.
> > (gdb) b _Scheduler_strong_APA_Get_lowest_scheduled
> > Breakpoint 7 at 0x118bee: file
> /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/schedulerstrongapa.c,
> line 287.
> > (gdb) continue
> > Continuing.
> >
> > Thread 1 hit Breakpoint 7, _Scheduler_strong_APA_Get_lowest_scheduled
> (context=0x200620 <_Configuration_Scheduler_strong_APA_dflt>,
> filter_base=0x201910 <_RTEMS_tasks_Objects+600>) at
> /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/schedulerstrongapa.c:28

Re: Quick question: How do I get the name of the scheduler from _Scheduler_Control

2020-08-13 Thread Gedare Bloom

cpukit/include/rtems/rtems/support.h:RTEMS_INLINE_ROUTINE void
rtems_name_to_characters(

On Thu, Aug 13, 2020 at 1:15 PM Richi Dubey  wrote:
>
> Hi,
>
> It's hard to find this with the help of cscope and I would appreciate your 
> help in this.
>
> Is there a way to print the 'name' in :
> --
> struct _Scheduler_Control {
>   /**
>* @brief Reference to a statically allocated scheduler context.
>*/
>   Scheduler_Context *context;
>
>   /**
>* @brief The scheduler operations.
>*/
>   Scheduler_Operations Operations;
>
>   /**
>* @brief The maximum priority value of this scheduler.
>*
>* It defines the lowest (least important) thread priority for this
>* scheduler.  For example the idle threads have this priority.
>*/
>   Priority_Control maximum_priority;
>
>   /**
>* @brief The scheduler name.
>*/
>   uint32_t name;
> --
>
> as a string? Is there a function that maps this int to string?
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: crypt and POSIX

2020-08-13 Thread Chris Johns

On 13/8/20 11:47 pm, Joel Sherrill wrote:
> On Thu, Aug 13, 2020 at 7:52 AM Sebastian Huber
>  >
> wrote:
> 
> On 13/08/2020 14:49, Joel Sherrill wrote:
> 
> > Why was crypt() removed? It is in the FreeBSD version at the bottom of
> > the file.
> >
> > https://github.com/freebsd/freebsd/blob/master/lib/libcrypt/crypt.c
> It is not thread-safe.
> 

> But it is standards compliant.

Could it be added and just return NULL or even generate an internal error? The
lack of crypt stopped me from using and it made me consider the issues. It is
easy to forget these things when adding passwords to the console or telnet
server and really hard to see an issue.

> And this would seem to violate the rules of source transparency in the 
> way the code was removed. If you wanted to disable it, it should have
> been wrapped in ifndef __rtems__.

I am confused, the code in cpukit/libcrypt is not from FreeBSD?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[GSoC 2020]: Need help in writing sed alternative in Python for RSB recipes

2020-08-13 Thread Mritunjay Sharma

Hello everyone,

Based on the input received by Gedare, I have started working
on finding a 'sed' alternative to be used in the RSB recipes to
do streamline text replacements.

I have gone through the Python Development Guidelines (
https://docs.rtems.org/branches/master/eng/python-devel.html)
and have installed the things suggested in this for the development
environment.

To start with the research work, I found this interesting
the discussion here
https://unix.stackexchange.com/questions/13711/differences-between-sed-on-mac-osx-and-other-standard-sed
that
gave me an idea
on how sed differs in BSD and UNIX platforms.

I learnt about differences like:
`OS X's sed uses -E for ERE and GNU sed uses -r. -E is an alias for -r in
GNU sed (added in 4.2, not documented until 4.3). Newer versions of FreeBSD
and NetBSD sed support both -E and -r. OpenBSD sed only supports -E.
`

I also found a similar project https://github.com/chmln/sd which can help
us in
developing the Python code needed in our case.

I would request the mentors to guide me on how and where to begin from
in writing this alternative?
Where do I have to write it? Is it the rtems-tools project (
https://github.com/RTEMS/rtems-tools) where I have to contribute to for
building this alternative?

Thanks
Mritunjay Sharma
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

about FAST_IDLE in Clock_isr

2020-08-13 Thread 朱忠杰

Hi, everyone

Is there any consideration why the FAST_IDLE is separated from normal
path，can I change the FAST_IDLE like the following?

#if defined(BSP_FEATURE_IRQ_EXTENSION) || \
(CPU_SIMPLE_VECTORED_INTERRUPTS != TRUE)
void Clock_isr(void *arg);
void Clock_isr(void *arg)
{
#else
rtems_isr Clock_isr(rtems_vector_number vector);
rtems_isr Clock_isr(
  rtems_vector_number vector
)
{
#endif
  /*
   *  Accurate count of ISRs
   */
  Clock_driver_ticks += 1;

  #if CLOCK_DRIVER_ISRS_PER_TICK
/*
 *  The driver is multiple ISRs per clock tick.
 */
if ( !Clock_driver_isrs ) {
  Clock_driver_timecounter_tick();

  Clock_driver_isrs = CLOCK_DRIVER_ISRS_PER_TICK_VALUE;
}
Clock_driver_isrs--;
  #else
/*
 *  The driver is one ISR per clock tick.
 */
Clock_driver_timecounter_tick();

#if CLOCK_DRIVER_USE_FAST_IDLE
  if (_SMP_Get_processor_maximum() == 1) {
struct timecounter *tc;
uint64_tus_per_tick;
uint32_tinterval;
Per_CPU_Control*cpu_self;

cpu_self = _Per_CPU_Get();
tc = _Timecounter;
us_per_tick = rtems_configuration_get_microseconds_per_tick();
interval = (uint32_t) ((tc->tc_frequency * us_per_tick) / 100);

while (
  cpu_self->thread_dispatch_disable_level == cpu_self->isr_nest_level
&& cpu_self->heir == cpu_self->executing
&& cpu_self->executing->is_idle
) {
  ISR_lock_Context lock_context;

  _Timecounter_Acquire(&lock_context);
  _Timecounter_Tick_simple(
interval,
(*tc->tc_get_timecount)(tc),
&lock_context
  );
}
  }
#endif
  #endif
/*
 *  Do the hardware specific per-tick action.
 *
 *  The counter/timer may or may not be set to automatically reload.
 */
Clock_driver_support_at_tick();
}
diff --git a/bsps/shared/dev/clock/clockimpl.h b/bsps/shared/dev/clock/clockimpl.h
index dad71307f4..635c52b54e 100644
--- a/bsps/shared/dev/clock/clockimpl.h
+++ b/bsps/shared/dev/clock/clockimpl.h
@@ -141,10 +141,23 @@ rtems_isr Clock_isr(
*/
   Clock_driver_ticks += 1;
 
-  #if CLOCK_DRIVER_USE_FAST_IDLE
-{
+  #if CLOCK_DRIVER_ISRS_PER_TICK
+/*
+ *  The driver is multiple ISRs per clock tick.
+ */
+if ( !Clock_driver_isrs ) {
   Clock_driver_timecounter_tick();
 
+  Clock_driver_isrs = CLOCK_DRIVER_ISRS_PER_TICK_VALUE;
+}
+Clock_driver_isrs--;
+  #else
+/*
+ *  The driver is one ISR per clock tick.
+ */
+Clock_driver_timecounter_tick();
+
+#if CLOCK_DRIVER_USE_FAST_IDLE
   if (_SMP_Get_processor_maximum() == 1) {
 struct timecounter *tc;
 uint64_tus_per_tick;
@@ -171,34 +184,14 @@ rtems_isr Clock_isr(
   );
 }
   }
-
-  Clock_driver_support_at_tick();
-}
-  #else
+#endif
+  #endif
 /*
  *  Do the hardware specific per-tick action.
  *
  *  The counter/timer may or may not be set to automatically reload.
  */
 Clock_driver_support_at_tick();
-
-#if CLOCK_DRIVER_ISRS_PER_TICK
-  /*
-   *  The driver is multiple ISRs per clock tick.
-   */
-  if ( !Clock_driver_isrs ) {
-Clock_driver_timecounter_tick();
-
-Clock_driver_isrs = CLOCK_DRIVER_ISRS_PER_TICK_VALUE;
-  }
-  Clock_driver_isrs--;
-#else
-  /*
-   *  The driver is one ISR per clock tick.
-   */
-  Clock_driver_timecounter_tick();
-#endif
-  #endif
 }
 
 void _Clock_Initialize( void )
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: crypt and POSIX

2020-08-13 Thread Sebastian Huber

On 13/08/2020 21:52, Chris Johns wrote:

On 13/8/20 11:47 pm, Joel Sherrill wrote:

On Thu, Aug 13, 2020 at 7:52 AM Sebastian Huber
mailto:sebastian.hu...@embedded-brains.de>>
wrote:

 On 13/08/2020 14:49, Joel Sherrill wrote:

 > Why was crypt() removed? It is in the FreeBSD version at the bottom of
 > the file.
 >
 > https://github.com/freebsd/freebsd/blob/master/lib/libcrypt/crypt.c
 It is not thread-safe.

But it is standards compliant.

Could it be added and just return NULL or even generate an internal error? The
lack of crypt stopped me from using and it made me consider the issues. It is
easy to forget these things when adding passwords to the console or telnet
server and really hard to see an issue.

If you prefer a run time error to a link time error you can add 
something like this:

char *
crypt(const char *passwd, const char *salt)
{
    errno = ENOSYS;
    return NULL;
}

The ready to use shell function to do a login check is:

extern bool rtems_shell_login_check(
  const char *user,
  const char *passphrase
);

And this would seem to violate the rules of source transparency in the
way the code was removed. If you wanted to disable it, it should have
been wrapped in ifndef __rtems__.

I am confused, the code in cpukit/libcrypt is not from FreeBSD?
The file "cpukit/libcrypt/crypt.c" is not from FreeBSD, so there is no 
point of having #ifndef __rtems__ stuff in it. Other files in the 
libcrypt are from FreeBSD.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

40 matches

Mail list logo