[PATCH] rsb: Fix the documentation URL

[Hesham Almatary]

---
 README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README b/README
index 34350c8..0a9ae72 100644
--- a/README
+++ b/README
@@ -20,7 +20,7 @@ The project is part of the RTEMS Project. The project's 
websites are:
https://git.rtems.org/rtems-source-builder.git/
 
  Documentation:
-   https://docs.rtems.org/branches/master/rsb/index.html
+   https://docs.rtems.org/branches/master/user/rsb/index.html
 
  Bugs:
https://devel.rtems.org/query?component=RSB
-- 
2.25.1

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

Re: [PATCH] rsb: Fix the documentation URL

[Chris Johns]

OK to push.

Thanks
Chris

On 9/9/20 6:56 pm, Hesham Almatary wrote:
> ---
>  README | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/README b/README
> index 34350c8..0a9ae72 100644
> --- a/README
> +++ b/README
> @@ -20,7 +20,7 @@ The project is part of the RTEMS Project. The project's 
> websites are:
> https://git.rtems.org/rtems-source-builder.git/
>  
>   Documentation:
> -   https://docs.rtems.org/branches/master/rsb/index.html
> +   https://docs.rtems.org/branches/master/user/rsb/index.html
>  
>   Bugs:
> https://devel.rtems.org/query?component=RSB
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] rtems: Add rtems_task_create_from_config()

[Chris Johns]

On 9/9/20 4:49 pm, Sebastian Huber wrote:
> On 09/09/2020 07:56, Chris Johns wrote:
>> What about a test for this API that has a 100K char TLS array and all the 
>> other
>> task values as defaults? If the space allocated and reported in the link map 
>> is
>> not just over 100K there is a problem.
> 
> As I said before, this API is for users which want to do the memory allocation
> on their own. These users must know when they have an 100K char TLS array in
> their application. They just have to use in this case:
> 
> #define MY_TLS (100K + whatever)
> 
> RTEMS_TASK_STORAGE_SIZE( MY_TLS + MY_STACK_SIZE, MY_ATTRIBUTES )

Ouch. This is not very nice. I see your design problem with this API.

I will try and discuss this topic with Joel tomorrow if we can get together.

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

Re: [PATCH v2] rtems: Add rtems_task_create_from_config()

[Sebastian Huber]

On 09/09/2020 00:43, Joel Sherrill wrote:



On Wed, Sep 2, 2020 at 11:09 AM Sebastian Huber 
> wrote:


In contrast to rtems_task_create() this function creates a task with a
user-provided task storage area.  The new create function uses a
configuration structure instead of individual parameters.

Add RTEMS_TASK_STORAGE_ALIGNMENT to define the recommended alignment of
a task storage area.

Add RTEMS_TASK_STORAGE_SIZE() to calculate the recommended size of a
task storage area based on the task attributes and the size dedicated to
the task stack and thread-local storage.  This macro may allow future
extensions without breaking the API.

Update #3959.
---

v2:

Rename function from rtems_task_build() to
rtems_task_create_from_config().  Add RTEMS_TASK_STORAGE_ALIGNMENT and
RTEMS_TASK_STORAGE_SIZE().  Improve documentation.

  cpukit/Makefile.am                      |   1 +
  cpukit/include/rtems/rtems/tasks.h      | 124 +++
  cpukit/include/rtems/rtems/tasksimpl.h  |  11 +
  cpukit/rtems/src/taskcreate.c           | 278 +---
  cpukit/rtems/src/taskcreatefromconfig.c | 274 +++
  testsuites/sptests/sp01/init.c          |  24 +-
  testsuites/sptests/sp01/sp01.doc        |   1 +
  testsuites/sptests/sp01/system.h        |   2 +-
  8 files changed, 479 insertions(+), 236 deletions(-)
  create mode 100644 cpukit/rtems/src/taskcreatefromconfig.c

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index e5009e53c9..caa6a9efe6 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -787,6 +787,7 @@ librtemscpu_a_SOURCES += rtems/src/statustoerrno.c
  librtemscpu_a_SOURCES += rtems/src/systemeventreceive.c
  librtemscpu_a_SOURCES += rtems/src/systemeventsend.c
  librtemscpu_a_SOURCES += rtems/src/taskcreate.c
+librtemscpu_a_SOURCES += rtems/src/taskcreatefromconfig.c
  librtemscpu_a_SOURCES += rtems/src/taskdelete.c
  librtemscpu_a_SOURCES += rtems/src/taskexit.c
  librtemscpu_a_SOURCES += rtems/src/taskgetaffinity.c
diff --git a/cpukit/include/rtems/rtems/tasks.h
b/cpukit/include/rtems/rtems/tasks.h
index 12c323e60e..a183dcafed 100644
--- a/cpukit/include/rtems/rtems/tasks.h
+++ b/cpukit/include/rtems/rtems/tasks.h
@@ -21,6 +21,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 

  #ifdef __cplusplus
@@ -164,6 +165,129 @@ rtems_status_code rtems_task_create(
    rtems_id            *id
  );

+/**
+ * @brief Returns the recommended task storage area size for the
specified size
+ *   and task attributes.
+ *
+ * @param _size is the size dedicated to the task stack and
thread-local
+ *   storage.


How does the user get the TLS size?

Need advice on that. Seems hard to get at compile time since it is a link
time aggregation.


I think we need an update of the Key Concepts or the Task Manager 
Background chapters so that general task storage considerations are 
explained.


https://docs.rtems.org/branches/master/c-user/key_concepts.html

https://docs.rtems.org/branches/master/c-user/task/background.html

See also reply to Chris.



+ *
+ * @param _attributes is the attribute set of the task using the
storage area.
+ *
+ * @return The recommended task storage area size is returned
calculated from
+ *   the input parameters.
+ *
+ * @see rtems_task_config
+ */
+#define RTEMS_TASK_STORAGE_SIZE( _size, _attributes ) \
+  ( ( _size ) + \
+    ( ( ( _attributes ) & RTEMS_FLOATING_POINT ) != 0 ?
CONTEXT_FP_SIZE : 0 ) )


If the architecture requires all threads to be FP, I don't think this 
will work.


Oh, yes. I will fix this in v3.



+
+/**
+ * @brief This variable attribute defines the recommended alignment
of a task
+ *   storage area.
+ *
+ * @see rtems_task_config
+ */
+#define RTEMS_TASK_STORAGE_ALIGNMENT RTEMS_ALIGNED(
CPU_STACK_ALIGNMENT )

Good. I assume the stack comes off the lower address range. Will
the TLS and FP areas have sufficient alignment? Is that accounted for?

I can't speak to generic TLS alignment but seems like cache alignment
is what the linker script would aim for.


The TLS alignment is defined by the content. The linker script doesn't 
define a particular alignment.


In the storage area size sanity check we have to take the alignment into 
account.




FP context may have to be double aligned on many architectures.


I guess CPU_STACK_ALIGNMENT accounts for alignment requirements of 
double values.




+/**
+ * @brief This structure defines the configuration of a task created by
+ *   rtems_task_create_from_config().
+ */
+typedef struct {
+  /**
+   * @brief This member defines the name of the task.
+   */
+  rtems_name n

[PATCH v3] rtems: Add rtems_task_create_from_config()

[Sebastian Huber]

In contrast to rtems_task_create() this function creates a task with a
user-provided task storage area.  The new create function uses a
configuration structure instead of individual parameters.

Add RTEMS_TASK_STORAGE_ALIGNMENT to define the recommended alignment of
a task storage area.

Add RTEMS_TASK_STORAGE_SIZE() to calculate the recommended size of a
task storage area based on the task attributes and the size dedicated to
the task stack and thread-local storage.  This macro may allow future
extensions without breaking the API.

Add application configuration option CONFIGURE_TASKS_CREATED_FROM_CONFIG to
adjust RTEMS Workspace size estimate.

Update #3959.
---
v2:

Rename function from rtems_task_build() to
rtems_task_create_from_config().  Add RTEMS_TASK_STORAGE_ALIGNMENT and
RTEMS_TASK_STORAGE_SIZE().  Improve documentation.

v3:

Add CONFIGURE_TASKS_CREATED_FROM_CONFIG.  Fix RTEMS_TASK_STORAGE_SIZE() if
CPU_ALL_TASKS_ARE_FP == TRUE.

 cpukit/Makefile.am  |   1 +
 cpukit/doxygen/appl-config.h|  23 ++
 cpukit/include/rtems/confdefs/threads.h |   8 +
 cpukit/include/rtems/confdefs/wkspace.h |   4 +-
 cpukit/include/rtems/rtems/tasks.h  | 131 +++
 cpukit/include/rtems/rtems/tasksimpl.h  |  11 +
 cpukit/rtems/src/taskcreate.c   | 278 +---
 cpukit/rtems/src/taskcreatefromconfig.c | 274 +++
 testsuites/sptests/sp01/init.c  |  24 +-
 testsuites/sptests/sp01/sp01.doc|   1 +
 testsuites/sptests/sp01/system.h|   3 +-
 11 files changed, 521 insertions(+), 237 deletions(-)
 create mode 100644 cpukit/rtems/src/taskcreatefromconfig.c

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index e5009e53c9..caa6a9efe6 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -787,6 +787,7 @@ librtemscpu_a_SOURCES += rtems/src/statustoerrno.c
 librtemscpu_a_SOURCES += rtems/src/systemeventreceive.c
 librtemscpu_a_SOURCES += rtems/src/systemeventsend.c
 librtemscpu_a_SOURCES += rtems/src/taskcreate.c
+librtemscpu_a_SOURCES += rtems/src/taskcreatefromconfig.c
 librtemscpu_a_SOURCES += rtems/src/taskdelete.c
 librtemscpu_a_SOURCES += rtems/src/taskexit.c
 librtemscpu_a_SOURCES += rtems/src/taskgetaffinity.c
diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index cd4664f7c8..5813192fd5 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -864,6 +864,29 @@
  */
 #define CONFIGURE_MAXIMUM_USER_EXTENSIONS
 
+/**
+ * @brief This configuration option is an integer define.
+ *
+ * The value of this configuration option defines the count of Classic API
+ * Tasks which are created by rtems_task_create_from_config().
+ *
+ * @par Default Value
+ * The default value is 0.
+ *
+ * @par Value Constraints
+ * The value of this configuration option shall be greater than or equal to 0
+ * and less than or equal to #CONFIGURE_MAXIMUM_TASKS.
+ *
+ * @par Notes
+ * By default, the calculation for the required memory in the RTEMS Workspace
+ * for tasks assumes that all Classic API Tasks are created by
+ * rtems_task_create().  This configuration option can be used to reduce the
+ * required memory for the system-provided task storage areas since tasks
+ * created by rtems_task_create_from_config() use a user-provided task storage
+ * area.
+ */
+#define CONFIGURE_TASKS_CREATED_FROM_CONFIG
+
 /** @} */
 
 /**
diff --git a/cpukit/include/rtems/confdefs/threads.h 
b/cpukit/include/rtems/confdefs/threads.h
index 33b8c5cee2..32d0c63d98 100644
--- a/cpukit/include/rtems/confdefs/threads.h
+++ b/cpukit/include/rtems/confdefs/threads.h
@@ -60,6 +60,14 @@
 
 #define _CONFIGURE_TASKS ( CONFIGURE_MAXIMUM_TASKS + _CONFIGURE_LIBBLOCK_TASKS 
)
 
+#ifndef CONFIGURE_TASKS_CREATED_FROM_CONFIG
+  #define CONFIGURE_TASKS_CREATED_FROM_CONFIG 0
+#endif
+
+#if CONFIGURE_TASKS_CREATED_FROM_CONFIG > CONFIGURE_MAXIMUM_TASKS
+  #error "CONFIGURE_TASKS_CREATED_FROM_CONFIG shall be less than or equal to 
CONFIGURE_MAXIMUM_TASKS"
+#endif
+
 #ifndef CONFIGURE_MAXIMUM_POSIX_THREADS
   #define CONFIGURE_MAXIMUM_POSIX_THREADS 0
 #endif
diff --git a/cpukit/include/rtems/confdefs/wkspace.h 
b/cpukit/include/rtems/confdefs/wkspace.h
index de476dbf82..215cdcb141 100644
--- a/cpukit/include/rtems/confdefs/wkspace.h
+++ b/cpukit/include/rtems/confdefs/wkspace.h
@@ -100,7 +100,9 @@
 + _CONFIGURE_POSIX_INIT_THREAD_STACK_EXTRA \
 + _CONFIGURE_LIBBLOCK_TASKS_STACK_EXTRA \
 + CONFIGURE_EXTRA_TASK_STACKS \
-+ rtems_resource_maximum_per_allocation( _CONFIGURE_TASKS ) \
++ rtems_resource_maximum_per_allocation( \
+_CONFIGURE_TASKS - CONFIGURE_TASKS_CREATED_FROM_CONFIG \
+  ) \
   * _Configure_From_stackspace( CONFIGURE_MINIMUM_TASK_STACK_SIZE ) \
 + rtems_resource_maximum_per_allocation( CONFIGURE_MAXIMUM_POSIX_THREADS ) 
\
   * _Configure_From_stackspace( CONFIGURE_MINIMUM_POSIX_THREAD_STACK_SIZE 
) \
diff --git a/cpukit/include/rtems/rtems/tasks.h 
b/cpukit/include/rtems/rtems

Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

[Chris Johns]

On 9/9/20 4:55 pm, jan.som...@dlr.de wrote:
> Hi Chris,
> 
>> -Original Message-
>> From: Chris Johns 
>> Sent: Friday, August 14, 2020 11:43 PM
>> To: Sommer, Jan ; devel@rtems.org
>> Subject: Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 
>> 5
>>
>> On 15/8/20 5:57 am, Jan Sommer wrote:
>>> Hello,
>>>
>>> I finally got around to port the e1000 driver fixes which are already
>>> present in the 5-freebsd-12 branch of rtems-libbsd also for the master
>>> (and 5) branch.
>>
>> Thanks. I will push these soon.
>>
> 
> As mentioned over at the users list, could you please push these changes?

Yes I will tomorrow if no one else does it.

> They should enable compilation for i386 again and we could establish Ethernet 
> connections with Intel network devices.
> The patches should apply to libbsd master and 5 branch, as they are both 
> based on FreeBSD master.
> 
>> I am not sure if the 5 branch in the rtems-libbsd.git repo is right and if it
>> should be made from the 5-freebsd-12 branch? I feel it is currently confusing
>> but either way it has issues.
>>
> 
> Maybe, we can continue to discuss that outside of this patch set? Renaming a 
> branch later should be no trouble.
> An option could be to rename 5 -> 5-freebsd-master, then the mapping between 
> rtems and FreeBSD would always be explicit.

Yes this is one Joel mentioned the other day and I missed the context in
relation to these patches. I think moving 5 to 5-freebsd-master makes sense.
What we have is confusing.

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

Re: [PATCH v2] rtems: Add rtems_task_create_from_config()

[Sebastian Huber]

On 09/09/2020 10:07, Chris Johns wrote:

On 9/9/20 4:49 pm, Sebastian Huber wrote:

On 09/09/2020 07:56, Chris Johns wrote:

What about a test for this API that has a 100K char TLS array and all the other
task values as defaults? If the space allocated and reported in the link map is
not just over 100K there is a problem.


As I said before, this API is for users which want to do the memory allocation
on their own. These users must know when they have an 100K char TLS array in
their application. They just have to use in this case:

#define MY_TLS (100K + whatever)

RTEMS_TASK_STORAGE_SIZE( MY_TLS + MY_STACK_SIZE, MY_ATTRIBUTES )


Ouch. This is not very nice. I see your design problem with this API.


I need an API which allows the user to provide the task storage area. 
The user should be able to use statically allocated memory for this.


The task storage area contains the task stack, the thread-local storage, 
and the floating-point context on architectures with a separate 
floating-point context.


The TLS size is known at link-time. If a user wants to use a statically 
allocated memory area for the task storage area, then the size of the 
user-provided task storage area must be known at compile-time.


From my point of view all what we can do is a sanity check at run-time. 
Do you have a better approach?




I will try and discuss this topic with Joel tomorrow if we can get together.


Ok, thanks for having a look at it.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

We are loosing patches

[Christian Mauderer]

Hello,

triggered by a comment from Chris here

https://lists.rtems.org/pipermail/users/2020-September/067873.html

I started to take a look at patches from non maintainers and write after
approval maintainers for some months: I think in May and June we lost at
least one or two of the following ones:

https://lists.rtems.org/pipermail/devel/2020-May/059751.html
https://lists.rtems.org/pipermail/devel/2020-May/059771.html
https://lists.rtems.org/pipermail/devel/2020-May/059772.html
https://lists.rtems.org/pipermail/devel/2020-May/059773.html
https://lists.rtems.org/pipermail/devel/2020-June/060125.html
https://lists.rtems.org/pipermail/devel/2020-June/060231.html
https://lists.rtems.org/pipermail/devel/2020-June/060235.html

It's a bit hard to see exactly whether a later version has been added
with a different subject, merged with another patch or just has been
rejected for some reason. That's another problem with our current system.

I think we start to loose valuable contributions due to that. I also
found some patches where just no one responded because no one noted it
and the person sending the patch had to ping it some time later. That's
not really encouraging to continue participating for new contributors.

I even lost track of some of my own patches in the past and found out
about a month later that I should have pushed them long ago.

Maybe it would be a good idea to start at least discussing whether we
should change something to avoid these problems. I think our current
system has two main problems:

1. All patches go to one single devel mailing list. It's sometimes hard
to see which patches are for what repository. And small patches tend to
just vanish between lot of other mails.

2. We have a big problem seeing which patch sets are done, which are in
the middle of a discussion and which are rejected.

A lot of other projects use software to solve these problems. Linux uses
"patchwork" for it since a long time (which needs one mailing list per
project). Most other projects use systems with pull requests like github
or a self hosted gitlab for that kind of stuff.

Maybe we should think about following these examples and go one step to
more modern software development too? What do you think?

Best regards

Christian
-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] rtems: Add rtems_task_create_from_config()

[Sebastian Huber]

On 09/09/2020 00:25, Joel Sherrill wrote:
   This has gotten to be a long-ish side discussion. I havecomments on 
the patch and will reply to the original email for that.


On Thu, Sep 3, 2020 at 10:17 PM Chris Johns > wrote:


On 3/9/20 10:08 pm, Sebastian Huber wrote:
 >
 > On 03/09/2020 04:08, Chris Johns wrote:
 >> On 3/9/20 2:09 am, Sebastian Huber wrote:
 >>> In contrast to rtems_task_create() this function creates a task
with a
 >>> user-provided task storage area.  The new create function uses a
 >>> configuration structure instead of individual parameters.
 >>>
 >>> Add RTEMS_TASK_STORAGE_ALIGNMENT to define the recommended
alignment of
 >>> a task storage area.
 >>>
 >>> Add RTEMS_TASK_STORAGE_SIZE() to calculate the recommended size
of a
 >>> task storage area based on the task attributes and the size
dedicated to
 >>> the task stack and thread-local storage.  This macro may allow
future
 >>> extensions without breaking the API.
 >> Have all the issues in the other thread been resolved? It would
be good to have
 >> Joel ack this patch before it is merged.
 > I tried to address the issues raised by Joel.

He will need to answer.


I will also comment on the patch. But the first thing I noticed was how 
does the user

know the amount of memory required for keys? That was in a Doxygen comment
about the macro which is a big improvement but still makes the user guess
something we should compute.

This reminds me of not giving an option to account for message buffers. Then
we added a confdefs macro to specify the total amount of memory. It took 
another
release before we realized that we didn't give the user a way to 
calculate the

memory required per queue based on number of messages and size of the
buffer. This made them guess to account for the overhead for each of those.
Let's try to avoid making users guess the size of memory that we would 
normally

compute.


The problem is that the TLS size is known at link-time (or even run-time 
if you take dynamic linking into account). You can't calculate this at 
compile-time.





 >> In considering the support for static allocation in general I am
wondering if
 >> the RTEMS Classic API Guide is poorly named? This is a new API
with new features
 >> and it is not "classic". The Key Concepts section of the that
manual says...
 >>
 >>   "RTEMS provides directives which can be used to dynamically
 >>    create, delete, and manipulate a set of predefined object types."
 >>
 >> This change makes this statement questionable.
 >
 > The task is still dynamically created, however, with a
user-provided task
 > storage area. It is similar to the POSIX threads which also have
to option to
 > use a user-provided task storage area. When you don't use
unlimited objects,
 > then the memory for task control blocks is only statically
allocated. The tasks
 > are dynamically maintained.

Thanks. This makes sense and almost what could be used in the
documentation :)


We just need to make sure we name the various situations clearly without 
names

like new/old, improved, etc.

I see a handful of RTOS memory organizations a systems designer has to pick
and we have to name and explain them.

(1) Workspace vs C Program Heap
     - usually associated with hard limits on objects. Unlimited is of 
marginal

       use with the split memory model.

(2) Unified Workspace/Heap
    - usually associated with unlimited objects

On top of that, you have

     (a) stack and FP allocated from Workspace
     (b)  BSP/application provided stack allocator
     (c) Application provided memory per task

That makes six combinations. I would tend to say that if you choose to
use Unified Workspace, then 2a makes sense. 2b also makes sense if
you had some stack protection scheme. But why would someone mix in
2c. Should work but not likely to be a common setup unless we do it
in support code.

For (1), I can see situations where you would use 1a, 1b, and 1c.

Overall, I see a-c as useful with 1+2 and a-c should work with 1 or 2
but we have to explain the choices.

I think this means we need to name a-c so we use consistent
terms across the community.


Yes, this makes sense. Finding good names for a-c will not be easy (at 
least for me).





 > The self-contained synchronization objects of this chapter
 >
 >
https://docs.rtems.org/branches/master/c-user/self_contained_objects.html
 >
 > are a different kind of thing.

Yes and this makes the word Classic look wrong.


Classic is probably technically only the core APIs that derived from 
RTEID/ORKID
or soon thereafter. Perhaps only the managers that existed before any 
POSIX was

added which would be strictly less than v4.x of RTEMS.

But now, Classic is just RTEMS specific APIs that start with rtems_ even 
t

Re: BSP Test Results

[Sebastian Huber]

Hello Chris,

On 07/09/2020 04:55, Chris Johns wrote:

Hello,

I would like to discuss BSP Test results early in the release cycle in the hope
we avoid the last minute issues we encountered with RTEMS 5 and the "expected"
failure state ticket.

I would like to update this section ...

https://docs.rtems.org/branches/master/user/testing/tests.html#expected-test-states

to state there is to be a ticket for each `expected-fail` test state. I believe
this was the outcome of the discussion that took place. Please correct me if
this is not correct.

The purpose of the `expected-fail` is to aid the accounting of the test results
to let us know if there are any regressions. We need to account for tests that
fail so we can track if a recent commit results in a new failure, i.e. a
regression. To do this we need to capture the state in a way `rtems-test` can
indicate a regression.


at first I was a bit sceptical about the expected-fail state, but you 
fully convinced me that it is a good approach. We need some automatic 
way to report regressions and the expected-fail helps here.




I think the `indeterminate` state may need further explanation as it will help
in the cases a simulator passes a test but the test fails on some hardware. I am
currently seeing this with spcache01 on the PC BSP.


The spintrcritical* tests had some sporadic failures on simulators. So 
sometimes they pass, sometimes they fail, sometimes they time out. I 
tried to fix this with the new T_interrupt_test(), but I am not sure if 
these tests can be made to work always.




With the level of continuous building and testing we are currently doing being
able to easily determine a regression will become important. Check out the
example below.

I would like to avoid us sitting with failures that do not have tickets and are
not accounted for. I know there is a lump of work to account for the failures
and after that is done I think the effort needed to maintain the failure states
will drop.

As a result I have been pondering how I can encourage this work be done. I am
considering updating the tier-1 status to requiring there be 0 unaccounted for
failures. That is the `rtems-test`'s Failure count is 0 for a hardware test run.


We would like to set up some continuous testing of the upstream 
GCC/GDB/Newlib. As it turned out, building the tools is not enough. We 
also have to build the tests for selected BSPs to catch compile/link 
errors. We also have to run the tests. For this we need a simple error 
status from rtems-test, e.g. everything as usual (0) or there was a 
regression (1).




Chris

An example using Joel's recent test run (thanks Joel :)). The sparc/leon2
results show no regressions:

Summary
===

Passed:580
Failed:  0
User Input:  6
Expected Fail:   1
Indeterminate:   0
Benchmark:   3
Timeout: 0
Invalid: 0
Wrong Version:   0
Wrong Build: 0
Wrong Tools: 0
--
Total: 590

[ https://lists.rtems.org/pipermail/build/2020-September/018089.html ]

while the sparc/erc32 has a single failure:

Summary
===

Passed:579
Failed:  1
User Input:  6
Expected Fail:   1
Indeterminate:   0
Benchmark:   3
Timeout: 0
Invalid: 0
Wrong Version:   0
Wrong Build: 0
Wrong Tools: 0
--
Total: 590

Failures:
  spintrcritical08.exe

[ https://lists.rtems.org/pipermail/build/2020-September/018088.html ]


I work on this one. It seems that the 1000us per tick are the issue, the 
test passes with 1us per tick.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: We are loosing patches

[Jan.Sommer]

I would like this idea.
We got Gitlab this year and collaboration with it is pretty convenient.
They also seem to hand out free licenses for OSS projects.
I guess installing and maintaining an instance is probably quite some work.

Best regards,

   Jan

> -Original Message-
> From: devel  On Behalf Of Christian Mauderer
> Sent: Wednesday, September 9, 2020 10:24 AM
> To: RTEMS Devel RTEMS 
> Subject: We are loosing patches
> 
> Hello,
> 
> triggered by a comment from Chris here
> 
> https://lists.rtems.org/pipermail/users/2020-September/067873.html
> 
> I started to take a look at patches from non maintainers and write after
> approval maintainers for some months: I think in May and June we lost at
> least one or two of the following ones:
> 
> https://lists.rtems.org/pipermail/devel/2020-May/059751.html
> https://lists.rtems.org/pipermail/devel/2020-May/059771.html
> https://lists.rtems.org/pipermail/devel/2020-May/059772.html
> https://lists.rtems.org/pipermail/devel/2020-May/059773.html
> https://lists.rtems.org/pipermail/devel/2020-June/060125.html
> https://lists.rtems.org/pipermail/devel/2020-June/060231.html
> https://lists.rtems.org/pipermail/devel/2020-June/060235.html
> 
> It's a bit hard to see exactly whether a later version has been added with a
> different subject, merged with another patch or just has been rejected for
> some reason. That's another problem with our current system.
> 
> I think we start to loose valuable contributions due to that. I also found 
> some
> patches where just no one responded because no one noted it and the
> person sending the patch had to ping it some time later. That's not really
> encouraging to continue participating for new contributors.
> 
> I even lost track of some of my own patches in the past and found out about
> a month later that I should have pushed them long ago.
> 
> Maybe it would be a good idea to start at least discussing whether we should
> change something to avoid these problems. I think our current system has
> two main problems:
> 
> 1. All patches go to one single devel mailing list. It's sometimes hard to see
> which patches are for what repository. And small patches tend to just vanish
> between lot of other mails.
> 
> 2. We have a big problem seeing which patch sets are done, which are in the
> middle of a discussion and which are rejected.
> 
> A lot of other projects use software to solve these problems. Linux uses
> "patchwork" for it since a long time (which needs one mailing list per
> project). Most other projects use systems with pull requests like github or a
> self hosted gitlab for that kind of stuff.
> 
> Maybe we should think about following these examples and go one step to
> more modern software development too? What do you think?
> 
> Best regards
> 
> Christian
> --
> 
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> PGP: Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BSP Test Results

[Sebastian Huber]

On 09/09/2020 02:36, Chris Johns wrote:

On 9/9/20 3:13 am, Gedare Bloom wrote:

On Sun, Sep 6, 2020 at 8:55 PM Chris Johns  wrote:

An example using Joel's recent test run (thanks Joel :)). The sparc/leon2
results show no regressions:

Summary
===

Passed:580
Failed:  0
User Input:  6
Expected Fail:   1

Is there a ticket for this one? out of curiosity.

I do not think so. This and any others will need to be cleaned up once I
implement the change to support ticket numbers. I will do that as part of the
change seems I added the expected-fail states.


I think it is this one:

http://devel.rtems.org/ticket/3997

Maybe the expected-fail state should report a ticket number (or link).

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BSP Test Results

[Sebastian Huber]

On 09/09/2020 02:29, Chris Johns wrote:

This would be enough to address my "HW or which simulator" question.

I had created #4072, please update adding the items you would like. We can add
anything you like and they can be mandated. There already exist a number of
fields for various transports so adding this is not hard, creating the list is
harder. These can defined in the .cfg files or they can be part of the user .ini
configuration files and so specific to a user's set up. They would be
informational only.


Before we dig into this, it would be nice to integrate the new build 
system first. We have a lot more options to work with in Python.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-libbsd 2/2] imx: Remove ccm functions alredy defined in RTEMS

[Christian Mauderer]

The imx_ccm_*_hz are all defined in RTEMS. So don't duplicate them in
libbsd. Otherwise some applications get linker errors.

Update #3869
---
 freebsd/sys/arm/freescale/imx/imx6_ccm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/freebsd/sys/arm/freescale/imx/imx6_ccm.c 
b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
index 78bbd5c1..7fdb69b8 100644
--- a/freebsd/sys/arm/freescale/imx/imx6_ccm.c
+++ b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
@@ -368,6 +368,7 @@ imx6_ccm_sata_enable(void)
return 0;
 }
 
+#ifndef __rtems__
 uint32_t
 imx_ccm_ecspi_hz(void)
 {
@@ -408,6 +409,7 @@ imx_ccm_ahb_hz(void)
 {
return (13200);
 }
+#endif /* __rtems__ */
 
 void
 imx_ccm_ipu_enable(int ipu)
-- 
2.26.2

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

[PATCH rtems-libbsd 1/2] sdhci: Add some workarrounds for i.MX

[Christian Mauderer]

Some bits are in the wrong order. Beneath that, the interrupts can occur
in an unexpected order. The DATA_AVAIL interrupt can occur at the same
time as the DMA interrupt (or slightly before it). With that, the DMA
and PIO interrupt handling doesn't work well together. Beneath that the
DMA interrupt isn't only executed at block ends but also if all data is
transfered. That can lead to problems with the DATA_END interrupt.
Therefore check whether there is really data left to unload.

Update #3869
---
 freebsd/sys/dev/sdhci/fsl_sdhci.c | 41 +++
 freebsd/sys/dev/sdhci/sdhci.c | 40 ++
 2 files changed, 81 insertions(+)

diff --git a/freebsd/sys/dev/sdhci/fsl_sdhci.c 
b/freebsd/sys/dev/sdhci/fsl_sdhci.c
index be3d1de3..acef1c4a 100644
--- a/freebsd/sys/dev/sdhci/fsl_sdhci.c
+++ b/freebsd/sys/dev/sdhci/fsl_sdhci.c
@@ -74,6 +74,9 @@ uint32_t mpc85xx_get_system_clock(void);
 #endif /* __rtems__ */
 #endif
 
+#ifndef __rtems__
+#include 
+#endif /* __rtems__ */
 #include 
 
 #include 
@@ -168,6 +171,16 @@ struct fsl_sdhci_softc {
 #define SDHC_PROT_CDSS (1 << 7)
 
 #defineSDHC_SYS_CTRL   0x2c
+#ifdef __rtems__
+
+/*
+ * Freescale messed up the INT DMA ERR bit and placed it at bit 28 instead of
+ * bit 25 which would be standard.
+ */
+#define SDHC_INT_DMAES (1 << 28)
+
+#define SDHC_CAN_DO_ADMA2  0x0010
+#endif /* __rtems__ */
 
 /*
  * The clock enable bits exist in different registers for ESDHC vs USDHC, but
@@ -349,6 +362,16 @@ fsl_sdhci_read_4(device_t dev, struct sdhci_slot *slot, 
bus_size_t off)
val32 &= ~SDHCI_CAN_VDD_180;
val32 &= ~SDHCI_CAN_DO_SUSPEND;
val32 |= SDHCI_CAN_DO_8BITBUS;
+#ifdef __rtems__
+   /*
+* Freescale signals ADMA2 capability via bit 20 (which would be
+* ADMA1) instead of 19.
+*/
+   if (val32 & SDHC_CAN_DO_ADMA2) {
+   val32 &= ~SDHC_CAN_DO_ADMA2;
+   val32 |= SDHCI_CAN_DO_ADMA2;
+   }
+#endif /* __rtems__ */
return (val32);
}

@@ -373,6 +396,13 @@ fsl_sdhci_read_4(device_t dev, struct sdhci_slot *slot, 
bus_size_t off)
 * command with an R1B response, mix it into the hardware status.
 */
if (off == SDHCI_INT_STATUS) {
+#ifdef __rtems__
+   /* Fix messed up DMA error. */
+   if (val32 & SDHC_INT_DMAES) {
+   val32 &= ~SDHC_INT_DMAES;
+   val32 |= SDHCI_INT_ADMAERR;
+   }
+#endif /* __rtems__ */
return (val32 | sc->r1bfix_intmask);
}
 
@@ -519,6 +549,15 @@ fsl_sdhci_write_4(device_t dev, struct sdhci_slot *slot, 
bus_size_t off, uint32_
if (off == SDHCI_INT_STATUS) {
sc->r1bfix_intmask &= ~val;
}
+#ifdef __rtems__
+   /* Fix messed up DMA error. */
+   if (off == SDHCI_INT_STATUS || off == SDHCI_INT_ENABLE || off == 
SDHCI_SIGNAL_ENABLE) {
+   if (val & SDHCI_INT_ADMAERR) {
+   val &= ~SDHCI_INT_ADMAERR;
+   val |= SDHC_INT_DMAES;
+   }
+   }
+#endif /* __rtems__ */
 
WR4(sc, off, val);
 }
@@ -884,10 +923,12 @@ fsl_sdhci_attach(device_t dev)
 
sc->slot.quirks |= SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK;
 
+#if !defined(__rtems__) || !defined(LIBBSP_ARM_IMX_BSP_H)
/*
 * DMA is not really broken, I just haven't implemented it yet.
 */
sc->slot.quirks |= SDHCI_QUIRK_BROKEN_DMA;
+#endif /* __rtems__ */
 
/*
 * Set the buffer watermark level to 128 words (512 bytes) for both read
diff --git a/freebsd/sys/dev/sdhci/sdhci.c b/freebsd/sys/dev/sdhci/sdhci.c
index ed6010e8..53d86fe8 100644
--- a/freebsd/sys/dev/sdhci/sdhci.c
+++ b/freebsd/sys/dev/sdhci/sdhci.c
@@ -68,6 +68,9 @@ __FBSDID("$FreeBSD$");
 #include 
 
 #include 
+#ifdef __rtems__
+#include 
+#endif /* __rtems__ */
 
 SYSCTL_NODE(_hw, OID_AUTO, sdhci, CTLFLAG_RD, 0, "sdhci driver");
 
@@ -766,6 +769,17 @@ sdhci_dma_alloc(struct sdhci_slot *slot)
else
slot->sdma_boundary = SDHCI_BLKSZ_SDMA_BNDRY_512K;
}
+#ifdef __rtems__
+#if defined(LIBBSP_ARM_IMX_BSP_H)
+   /*
+* i.MX6ULL doesn't have the SDMA Buffer Boundary bits. Instead the
+* BLKSIZE is one bit larger and would overlap the Buffer Boundary.
+* Setting the Buffer Boundary to 4K makes sure that the highest BLKSIZE
+* bit is always 0.
+*/
+   slot->sdma_boundary = SDHCI_BLKSZ_SDMA_BNDRY_4K;
+#endif
+#endif /* __rtems__ */
slot->sdma_bbufsz = SDHCI_SDMA_BNDRY_TO_BBUFSZ(slot->sdma_boundary);
 
/*
@@ -1896,6 +1910,10 @@ sdhci_start_data(struct sdhci_slot *slot, const struct 
mmc_data *data)
BUS_DMASYNC_PREWRITE);
}
WR4(

Re: BSP Test Results

[Christian Mauderer]

On 09/09/2020 02:29, Chris Johns wrote:
[...]
> 
>> > Also I am not sure but hopefully the test reports do accurately reflect
>> host OS.
>>
>> There is a "Host" section at the top of the results log? It is just 
>> `uname -a`.
>>
>> I think that's sufficient as long as it can distinguish Linux distributions. 
> 
> Does Linux or Python on Linux provide a common means to find what distribution
> you are on? Do distributions based on another distro make a suitable the
> separation? A Linux distro expert will need to guide this. I have no idea.
> 

In theory there is the platform.linux_distribution() in python:

https://docs.python.org/3.7/library/platform.html#module-platform

But on my OpenSUSE 15.1 that failed to provide anything. Beneath that it
seems to be deprecated since Python 3.5.

A newer package that want to provide this functionality is "distro":

https://distro.readthedocs.io/en/latest/

Beneath that module, there is "/etc/os-release". It's a standard file
for systemd. So most likely most distros have it now:

https://www.freedesktop.org/software/systemd/man/os-release.html

Best regards

Christian
-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: We are loosing patches

[Joel Sherrill]

On Wed, Sep 9, 2020 at 3:43 AM  wrote:

> I would like this idea.
> We got Gitlab this year and collaboration with it is pretty convenient.
> They also seem to hand out free licenses for OSS projects.
> I guess installing and maintaining an instance is probably quite some work.
>

We use Gitlab community edition internally. On a recent non-RTEMS project,
we pushed the Continuous Integration and Testing pretty hard. We built,
tested, and did coverage for 4 configurations of the software for 3
different
Linux distributions using Docker on every push. We built Doxygen every time
and ran the FACE Conformance Test Suite on multiple components. Plus
had a  commercial tool that did MISRA/CERT compliance checking and MCDC
coverage analysis. Everything ran well but the commercial tool took a
fair amount of babying.

We didn't use it for patch management though. We just required issues
and you had to pass the CIT to merge. We did use milestones for light
project management but only the basics of the ticketing system.

One challenge RTEMS has with automated testing is the turnaround time.
On the project I mentioned, everything took only a few minutes except the
commercial tool which ended up taking 30 minutes. For RTEMS, building
and testing everything is quite time consuming. The script I run takes
about
1 day on an 8 core Xeon and ~2.5 days on the older quad-cores. I don't test
anything on hardware in that cycle. Because of this, the testing part of CIT
for RTEMS will likely always only be spot checking. But we could put more
emphasis on say Doxygen builds always being warning free and the critical
BSPs that are spot checked being warning free.

The "critical set of BSPs" to be spot checked is up for discussion but
ideally they would run on simulators and represent a realistic but broad
subset. That makes the long version of the list something like sparc/leon3,
arm/zynq_qemu, x86/pc, powerpc/psim and mips/jmr3904.

This was a long reply to just cover what I think we could do for CIT on
the RTEMS repo. Considering rtems-docs, examples, etc. adds other
options.

Back to the patch management system.

We have discussed having Patchwork and Phabricator in the past. I don't
know if there is a true resistance to using such a tool but a lack of time.
All system administration on rtems.org is volunteer.  That by itself is the
biggest barrier.

--joel

Ph
> Best regards,
>
>Jan
>
> > -Original Message-
> > From: devel  On Behalf Of Christian Mauderer
> > Sent: Wednesday, September 9, 2020 10:24 AM
> > To: RTEMS Devel RTEMS 
> > Subject: We are loosing patches
> >
> > Hello,
> >
> > triggered by a comment from Chris here
> >
> > https://lists.rtems.org/pipermail/users/2020-September/067873.html
> >
> > I started to take a look at patches from non maintainers and write after
> > approval maintainers for some months: I think in May and June we lost at
> > least one or two of the following ones:
> >
> > https://lists.rtems.org/pipermail/devel/2020-May/059751.html
> > https://lists.rtems.org/pipermail/devel/2020-May/059771.html
> > https://lists.rtems.org/pipermail/devel/2020-May/059772.html
> > https://lists.rtems.org/pipermail/devel/2020-May/059773.html
> > https://lists.rtems.org/pipermail/devel/2020-June/060125.html
> > https://lists.rtems.org/pipermail/devel/2020-June/060231.html
> > https://lists.rtems.org/pipermail/devel/2020-June/060235.html
> >
> > It's a bit hard to see exactly whether a later version has been added
> with a
> > different subject, merged with another patch or just has been rejected
> for
> > some reason. That's another problem with our current system.
> >
> > I think we start to loose valuable contributions due to that. I also
> found some
> > patches where just no one responded because no one noted it and the
> > person sending the patch had to ping it some time later. That's not
> really
> > encouraging to continue participating for new contributors.
> >
> > I even lost track of some of my own patches in the past and found out
> about
> > a month later that I should have pushed them long ago.
> >
> > Maybe it would be a good idea to start at least discussing whether we
> should
> > change something to avoid these problems. I think our current system has
> > two main problems:
> >
> > 1. All patches go to one single devel mailing list. It's sometimes hard
> to see
> > which patches are for what repository. And small patches tend to just
> vanish
> > between lot of other mails.
> >
> > 2. We have a big problem seeing which patch sets are done, which are in
> the
> > middle of a discussion and which are rejected.
> >
> > A lot of other projects use software to solve these problems. Linux uses
> > "patchwork" for it since a long time (which needs one mailing list per
> > project). Most other projects use systems with pull requests like github
> or a
> > self hosted gitlab for that kind of stuff.
> >
> > Maybe we should think about following these examples and go one step to
> > more mo

Re: We are loosing patches

[Christian Mauderer]

Hello Jan and Joel,

On 09/09/2020 15:19, Joel Sherrill wrote:
> 
> 
> On Wed, Sep 9, 2020 at 3:43 AM  > wrote:
> 
> I would like this idea.
> We got Gitlab this year and collaboration with it is pretty convenient.
> They also seem to hand out free licenses for OSS projects.
> I guess installing and maintaining an instance is probably quite
> some work.
> 
> 
> We use Gitlab community edition internally. On a recent non-RTEMS project, 
> we pushed the Continuous Integration and Testing pretty hard. We built, 
> tested, and did coverage for 4 configurations of the software for 3
> different 
> Linux distributions using Docker on every push. We built Doxygen every time
> and ran the FACE Conformance Test Suite on multiple components. Plus 
> had a  commercial tool that did MISRA/CERT compliance checking and MCDC
> coverage analysis. Everything ran well but the commercial tool took a 
> fair amount of babying. 
> 
> We didn't use it for patch management though. We just required issues
> and you had to pass the CIT to merge. We did use milestones for light
> project management but only the basics of the ticketing system.
> 
> One challenge RTEMS has with automated testing is the turnaround time. 
> On the project I mentioned, everything took only a few minutes except the 
> commercial tool which ended up taking 30 minutes. For RTEMS, building 
> and testing everything is quite time consuming. The script I run takes
> about 
> 1 day on an 8 core Xeon and ~2.5 days on the older quad-cores. I don't test 
> anything on hardware in that cycle. Because of this, the testing part of CIT
> for RTEMS will likely always only be spot checking. But we could put more 
> emphasis on say Doxygen builds always being warning free and the critical 
> BSPs that are spot checked being warning free.  
> 
> The "critical set of BSPs" to be spot checked is up for discussion but 
> ideally they would run on simulators and represent a realistic but broad 
> subset. That makes the long version of the list something like sparc/leon3, 
> arm/zynq_qemu, x86/pc, powerpc/psim and mips/jmr3904. 
> 
> This was a long reply to just cover what I think we could do for CIT on
> the RTEMS repo. Considering rtems-docs, examples, etc. adds other 
> options.

Also I agree that automated builds or checks could be an extension, that
is not really the core point. Part of these automated builds are already
done by buildbot.rtems.org.

> 
> Back to the patch management system.

That's the part that (at the moment) was the starting point of my mail.

> 
> We have discussed having Patchwork and Phabricator in the past. I don't
> know if there is a true resistance to using such a tool but a lack of time.
> All system administration on rtems.org  is volunteer. 
> That by itself is the
> biggest barrier. 

Regarding the administrative effort: I'm well aware that there is a lot
of work. And if my request adds additional workload, we should discuss
who can do that or how it can be funded. But I don't think that it is a
good situation that patches get lost or that _new_ contributors have to
ping a mail because no one has seen it between lot's of other mails.
Patches are valuable and they are the entry point for every new member
of our community.

Beneath that: Our time is valuable too. If systems can collect all
relevant information for one patch set (including earlier versions,
comments, ...): Why do we waste so much time with searching that kind of
stuff on the mailing list. If you just have to use a single command to
apply the latest version of a patch set: Why do we have to find and
download the patches from the mailing list, apply them locally to the
correct repo, make sure that we did the right thing and then push them.

So please let's not jump right into the administrative part of the
system or how many work it maybe would be to implement it. Let's first
find out whether a big part of our community could agree to a more
modern approach of handling patches that can save time for contributors
and maintainers. As soon as we have one: Let's talk about what is
necessary to reach that solution. If it is a step forward, I'm sure we
will find a solution to handle the initial effort.

Best regards

Christian

> 
> --joel
> 
> Ph
> Best regards,
> 
>    Jan
> 
> > -Original Message-
> > From: devel  > On Behalf Of Christian Mauderer
> > Sent: Wednesday, September 9, 2020 10:24 AM
> > To: RTEMS Devel RTEMS mailto:devel@rtems.org>>
> > Subject: We are loosing patches
> >
> > Hello,
> >
> > triggered by a comment from Chris here
> >
> >     https://lists.rtems.org/pipermail/users/2020-September/067873.html
> >
> > I started to take a look at patches from non maintainers and write
> after
> > approval maintainers for some months: I think in May and June we
> lost at
> > least one o

Re: Error while running rtems-test

[Richi Dubey]

Sorry for the late reply. My university tests are going to come up really
soon and I have to make up for stuff I missed early on :p


Did you build with --enable-tests?

I do not remember. I am going to make the bsp from the beginning again.

Are there *.exe files in ~/quick-start/build/b-smp-leon3?

Nope.

I do not think rtems-test expands a ~ to $HOME so changing to the directory
> should work.

It did not work. Thank you for the suggestion, maybe I haven't enabled
tests while building.

On Tue, Sep 8, 2020 at 8:14 AM Chris Johns  wrote:

> On 8/9/20 1:48 am, Sebastian Huber wrote:
> > On 07/09/2020 17:37, Richi Dubey wrote:
> >
> >> My current directory is: ~/quick-start/build/b-smp-leon3$
> >>
> >> and I'm running the command:
> >> ~/quick-start/rtems/test/rtems-tools/tester/rtems-test \
> --log=log_leon3_sis \
> >> --rtems-bsp=leon3-sis \
> >> ~/quick-start/build/b-smp-leon3/sparc-rtems5/c/leon3/testsuites
> >>
> >> which gives the following error:
> >>
> >> RTEMS Testing - Tester, 6 (b1c6a98da4a2)
> >> error: no executables supplied
> >
> > Did you build with --enable-tests?
> >
> > Are there *.exe files in ~/quick-start/build/b-smp-leon3?
> >
> > If yes, then try to run it with:
> >
> > cd ~/quick-start/build/b-smp-leon3
>
> I do not think rtems-test expands a ~ to $HOME so changing to the directory
> should work.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: We are loosing patches

[Thomas Doerfler]

Hi Joe,

just a brief note from holidays:

Am 09.09.20 um 15:19 schrieb Joel Sherrill:

> All system administration on rtems.org  is volunteer. 
> That by itself is the
> biggest barrier. 

We've talked collecting funds through a foundation. How can we push that
to at least partly professionalize the administration?

IMHO we are stuck with "I want to do X when I find proper time for it".
Collecting (constant?) funds may solve this a bit. Other open source
projects made this move quite successfully.

wkr,

Thomas.

> 
> --joel
> 
> Ph
> Best regards,
> 
>    Jan
> 
> > -Original Message-
> > From: devel  > On Behalf Of Christian Mauderer
> > Sent: Wednesday, September 9, 2020 10:24 AM
> > To: RTEMS Devel RTEMS mailto:devel@rtems.org>>
> > Subject: We are loosing patches
> >
> > Hello,
> >
> > triggered by a comment from Chris here
> >
> >     https://lists.rtems.org/pipermail/users/2020-September/067873.html
> >
> > I started to take a look at patches from non maintainers and write
> after
> > approval maintainers for some months: I think in May and June we
> lost at
> > least one or two of the following ones:
> >
> > https://lists.rtems.org/pipermail/devel/2020-May/059751.html
> > https://lists.rtems.org/pipermail/devel/2020-May/059771.html
> > https://lists.rtems.org/pipermail/devel/2020-May/059772.html
> > https://lists.rtems.org/pipermail/devel/2020-May/059773.html
> > https://lists.rtems.org/pipermail/devel/2020-June/060125.html
> > https://lists.rtems.org/pipermail/devel/2020-June/060231.html
> > https://lists.rtems.org/pipermail/devel/2020-June/060235.html
> >
> > It's a bit hard to see exactly whether a later version has been
> added with a
> > different subject, merged with another patch or just has been
> rejected for
> > some reason. That's another problem with our current system.
> >
> > I think we start to loose valuable contributions due to that. I
> also found some
> > patches where just no one responded because no one noted it and the
> > person sending the patch had to ping it some time later. That's
> not really
> > encouraging to continue participating for new contributors.
> >
> > I even lost track of some of my own patches in the past and found
> out about
> > a month later that I should have pushed them long ago.
> >
> > Maybe it would be a good idea to start at least discussing whether
> we should
> > change something to avoid these problems. I think our current
> system has
> > two main problems:
> >
> > 1. All patches go to one single devel mailing list. It's sometimes
> hard to see
> > which patches are for what repository. And small patches tend to
> just vanish
> > between lot of other mails.
> >
> > 2. We have a big problem seeing which patch sets are done, which
> are in the
> > middle of a discussion and which are rejected.
> >
> > A lot of other projects use software to solve these problems.
> Linux uses
> > "patchwork" for it since a long time (which needs one mailing list per
> > project). Most other projects use systems with pull requests like
> github or a
> > self hosted gitlab for that kind of stuff.
> >
> > Maybe we should think about following these examples and go one
> step to
> > more modern software development too? What do you think?
> >
> > Best regards
> >
> > Christian
> > --
> > 
> > embedded brains GmbH
> > Herr Christian Mauderer
> > Dornierstr. 4
> > D-82178 Puchheim
> > Germany
> > email: christian.maude...@embedded-brains.de
> 
> > Phone: +49-89-18 94 741 - 18
> > Fax:   +49-89-18 94 741 - 08
> > PGP: Public key available on request.
> >
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> > ___
> > devel mailing list
> > devel@rtems.org 
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> 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
> 

-- 

embedded brains GmbH
Thomas Doerfler
Dornierstr. 4
D-82178 Puchheim
Germany
email: thomas.doerf...@embedded-brains.de
Phone: +49-89-18 94 741-12
Fax:   +49-89-18 94 741-09
PGP: Public key available on request.
For our privacy statement, see
https://embedded-brains.de/en/data-privacy-statement/
___

Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

[Gedare Bloom]

On Wed, Sep 9, 2020 at 2:16 AM Chris Johns  wrote:
>
> On 9/9/20 4:55 pm, jan.som...@dlr.de wrote:
> > Hi Chris,
> >
> >> -Original Message-
> >> From: Chris Johns 
> >> Sent: Friday, August 14, 2020 11:43 PM
> >> To: Sommer, Jan ; devel@rtems.org
> >> Subject: Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master 
> >> and 5
> >>
> >> On 15/8/20 5:57 am, Jan Sommer wrote:
> >>> Hello,
> >>>
> >>> I finally got around to port the e1000 driver fixes which are already
> >>> present in the 5-freebsd-12 branch of rtems-libbsd also for the master
> >>> (and 5) branch.
> >>
> >> Thanks. I will push these soon.
> >>
> >
> > As mentioned over at the users list, could you please push these changes?
>
> Yes I will tomorrow if no one else does it.
>
> > They should enable compilation for i386 again and we could establish 
> > Ethernet connections with Intel network devices.
> > The patches should apply to libbsd master and 5 branch, as they are both 
> > based on FreeBSD master.
> >
> >> I am not sure if the 5 branch in the rtems-libbsd.git repo is right and if 
> >> it
> >> should be made from the 5-freebsd-12 branch? I feel it is currently 
> >> confusing
> >> but either way it has issues.
> >>
> >
> > Maybe, we can continue to discuss that outside of this patch set? Renaming 
> > a branch later should be no trouble.
> > An option could be to rename 5 -> 5-freebsd-master, then the mapping 
> > between rtems and FreeBSD would always be explicit.
>
> Yes this is one Joel mentioned the other day and I missed the context in
> relation to these patches. I think moving 5 to 5-freebsd-master makes sense.
> What we have is confusing.
>
+1

Would be good to get Christian or Sebastian to comment/agree :)

> Chris
> ___
> 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: We are loosing patches

[Gedare Bloom]

On Wed, Sep 9, 2020 at 8:16 AM Christian Mauderer
 wrote:
>
> Hello Jan and Joel,
>
> On 09/09/2020 15:19, Joel Sherrill wrote:
> >
> >
> > On Wed, Sep 9, 2020 at 3:43 AM  > > wrote:
> >
> > I would like this idea.
> > We got Gitlab this year and collaboration with it is pretty convenient.
> > They also seem to hand out free licenses for OSS projects.
> > I guess installing and maintaining an instance is probably quite
> > some work.
> >
> >
> > We use Gitlab community edition internally. On a recent non-RTEMS project,
> > we pushed the Continuous Integration and Testing pretty hard. We built,
> > tested, and did coverage for 4 configurations of the software for 3
> > different
> > Linux distributions using Docker on every push. We built Doxygen every time
> > and ran the FACE Conformance Test Suite on multiple components. Plus
> > had a  commercial tool that did MISRA/CERT compliance checking and MCDC
> > coverage analysis. Everything ran well but the commercial tool took a
> > fair amount of babying.
> >
> > We didn't use it for patch management though. We just required issues
> > and you had to pass the CIT to merge. We did use milestones for light
> > project management but only the basics of the ticketing system.
> >
> > One challenge RTEMS has with automated testing is the turnaround time.
> > On the project I mentioned, everything took only a few minutes except the
> > commercial tool which ended up taking 30 minutes. For RTEMS, building
> > and testing everything is quite time consuming. The script I run takes
> > about
> > 1 day on an 8 core Xeon and ~2.5 days on the older quad-cores. I don't test
> > anything on hardware in that cycle. Because of this, the testing part of CIT
> > for RTEMS will likely always only be spot checking. But we could put more
> > emphasis on say Doxygen builds always being warning free and the critical
> > BSPs that are spot checked being warning free.
> >
> > The "critical set of BSPs" to be spot checked is up for discussion but
> > ideally they would run on simulators and represent a realistic but broad
> > subset. That makes the long version of the list something like sparc/leon3,
> > arm/zynq_qemu, x86/pc, powerpc/psim and mips/jmr3904.
> >
> > This was a long reply to just cover what I think we could do for CIT on
> > the RTEMS repo. Considering rtems-docs, examples, etc. adds other
> > options.
>
> Also I agree that automated builds or checks could be an extension, that
> is not really the core point. Part of these automated builds are already
> done by buildbot.rtems.org.
>
> >
> > Back to the patch management system.
>
> That's the part that (at the moment) was the starting point of my mail.
>
> >
> > We have discussed having Patchwork and Phabricator in the past. I don't
> > know if there is a true resistance to using such a tool but a lack of time.
> > All system administration on rtems.org  is volunteer.
> > That by itself is the
> > biggest barrier.
>
> Regarding the administrative effort: I'm well aware that there is a lot
> of work. And if my request adds additional workload, we should discuss
> who can do that or how it can be funded. But I don't think that it is a
> good situation that patches get lost or that _new_ contributors have to
> ping a mail because no one has seen it between lot's of other mails.
> Patches are valuable and they are the entry point for every new member
> of our community.
>
> Beneath that: Our time is valuable too. If systems can collect all
> relevant information for one patch set (including earlier versions,
> comments, ...): Why do we waste so much time with searching that kind of
> stuff on the mailing list. If you just have to use a single command to
> apply the latest version of a patch set: Why do we have to find and
> download the patches from the mailing list, apply them locally to the
> correct repo, make sure that we did the right thing and then push them.
>
> So please let's not jump right into the administrative part of the
> system or how many work it maybe would be to implement it. Let's first
> find out whether a big part of our community could agree to a more
> modern approach of handling patches that can save time for contributors
> and maintainers. As soon as we have one: Let's talk about what is
> necessary to reach that solution. If it is a step forward, I'm sure we
> will find a solution to handle the initial effort.
>

This is a good idea to address a clear problem. We should identify the
requirements and options.

Some initial requirements:
1. Self-hosted: I guess we want self-hosting or at least control of
the data so we can easily retain it for the future and migrate it if
necessary.

2. Testing: At least a compile-only test, if not a simulator test
result. This shouldn't be a full CIT, just enough to say it compiles
(maybe runs) for some BSP(s).

3. Push from tool: to reduce the burden of downloading, testing, and
then pushing.

4. Sub

Re: [PATCH rtems-libbsd 1/2] sdhci: Add some workarrounds for i.MX

[Gedare Bloom]

Can this be pushed upstream in a non-RTEMS specific way?

On Wed, Sep 9, 2020 at 5:16 AM Christian Mauderer
 wrote:
>
> Some bits are in the wrong order. Beneath that, the interrupts can occur
> in an unexpected order. The DATA_AVAIL interrupt can occur at the same
> time as the DMA interrupt (or slightly before it). With that, the DMA
> and PIO interrupt handling doesn't work well together. Beneath that the
> DMA interrupt isn't only executed at block ends but also if all data is
> transfered. That can lead to problems with the DATA_END interrupt.
> Therefore check whether there is really data left to unload.
>
> Update #3869
> ---
>  freebsd/sys/dev/sdhci/fsl_sdhci.c | 41 +++
>  freebsd/sys/dev/sdhci/sdhci.c | 40 ++
>  2 files changed, 81 insertions(+)
>
> diff --git a/freebsd/sys/dev/sdhci/fsl_sdhci.c 
> b/freebsd/sys/dev/sdhci/fsl_sdhci.c
> index be3d1de3..acef1c4a 100644
> --- a/freebsd/sys/dev/sdhci/fsl_sdhci.c
> +++ b/freebsd/sys/dev/sdhci/fsl_sdhci.c
> @@ -74,6 +74,9 @@ uint32_t mpc85xx_get_system_clock(void);
>  #endif /* __rtems__ */
>  #endif
>
> +#ifndef __rtems__
> +#include 
> +#endif /* __rtems__ */
>  #include 
>
>  #include 
> @@ -168,6 +171,16 @@ struct fsl_sdhci_softc {
>  #define SDHC_PROT_CDSS (1 << 7)
>
>  #defineSDHC_SYS_CTRL   0x2c
> +#ifdef __rtems__
> +
> +/*
> + * Freescale messed up the INT DMA ERR bit and placed it at bit 28 instead of
> + * bit 25 which would be standard.
> + */
> +#define SDHC_INT_DMAES (1 << 28)
> +
> +#define SDHC_CAN_DO_ADMA2  0x0010
> +#endif /* __rtems__ */
>
>  /*
>   * The clock enable bits exist in different registers for ESDHC vs USDHC, but
> @@ -349,6 +362,16 @@ fsl_sdhci_read_4(device_t dev, struct sdhci_slot *slot, 
> bus_size_t off)
> val32 &= ~SDHCI_CAN_VDD_180;
> val32 &= ~SDHCI_CAN_DO_SUSPEND;
> val32 |= SDHCI_CAN_DO_8BITBUS;
> +#ifdef __rtems__
> +   /*
> +* Freescale signals ADMA2 capability via bit 20 (which would 
> be
> +* ADMA1) instead of 19.
> +*/
> +   if (val32 & SDHC_CAN_DO_ADMA2) {
> +   val32 &= ~SDHC_CAN_DO_ADMA2;
> +   val32 |= SDHCI_CAN_DO_ADMA2;
> +   }
> +#endif /* __rtems__ */
> return (val32);
> }
>
> @@ -373,6 +396,13 @@ fsl_sdhci_read_4(device_t dev, struct sdhci_slot *slot, 
> bus_size_t off)
>  * command with an R1B response, mix it into the hardware status.
>  */
> if (off == SDHCI_INT_STATUS) {
> +#ifdef __rtems__
> +   /* Fix messed up DMA error. */
> +   if (val32 & SDHC_INT_DMAES) {
> +   val32 &= ~SDHC_INT_DMAES;
> +   val32 |= SDHCI_INT_ADMAERR;
> +   }
> +#endif /* __rtems__ */
> return (val32 | sc->r1bfix_intmask);
> }
>
> @@ -519,6 +549,15 @@ fsl_sdhci_write_4(device_t dev, struct sdhci_slot *slot, 
> bus_size_t off, uint32_
> if (off == SDHCI_INT_STATUS) {
> sc->r1bfix_intmask &= ~val;
> }
> +#ifdef __rtems__
> +   /* Fix messed up DMA error. */
> +   if (off == SDHCI_INT_STATUS || off == SDHCI_INT_ENABLE || off == 
> SDHCI_SIGNAL_ENABLE) {
> +   if (val & SDHCI_INT_ADMAERR) {
> +   val &= ~SDHCI_INT_ADMAERR;
> +   val |= SDHC_INT_DMAES;
> +   }
> +   }
> +#endif /* __rtems__ */
>
> WR4(sc, off, val);
>  }
> @@ -884,10 +923,12 @@ fsl_sdhci_attach(device_t dev)
>
> sc->slot.quirks |= SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK;
>
> +#if !defined(__rtems__) || !defined(LIBBSP_ARM_IMX_BSP_H)
> /*
>  * DMA is not really broken, I just haven't implemented it yet.
>  */
> sc->slot.quirks |= SDHCI_QUIRK_BROKEN_DMA;
> +#endif /* __rtems__ */
>
> /*
>  * Set the buffer watermark level to 128 words (512 bytes) for both 
> read
> diff --git a/freebsd/sys/dev/sdhci/sdhci.c b/freebsd/sys/dev/sdhci/sdhci.c
> index ed6010e8..53d86fe8 100644
> --- a/freebsd/sys/dev/sdhci/sdhci.c
> +++ b/freebsd/sys/dev/sdhci/sdhci.c
> @@ -68,6 +68,9 @@ __FBSDID("$FreeBSD$");
>  #include 
>
>  #include 
> +#ifdef __rtems__
> +#include 
> +#endif /* __rtems__ */
>
>  SYSCTL_NODE(_hw, OID_AUTO, sdhci, CTLFLAG_RD, 0, "sdhci driver");
>
> @@ -766,6 +769,17 @@ sdhci_dma_alloc(struct sdhci_slot *slot)
> else
> slot->sdma_boundary = SDHCI_BLKSZ_SDMA_BNDRY_512K;
> }
> +#ifdef __rtems__
> +#if defined(LIBBSP_ARM_IMX_BSP_H)
> +   /*
> +* i.MX6ULL doesn't have the SDMA Buffer Boundary bits. Instead the
> +* BLKSIZE is one bit larger and would overlap the Buffer Boundary.
> +* Setting the Buffer Boundary to 4K makes sure that the highest 
> BLKSIZE
> +* bit is always 0.
> +*/

Determining Linux Distribution

[Joel Sherrill]

Hi

Chris mentioned this and then the thread moved on. Based on reading a few
pages, each distribution has its own place to state the distribution name.
Which makes the problem a bit recursive.  But some nice soul put together a
shell script which is supposed to identify the distribution.

https://www.unix.com/shell-programming-and-scripting/27932-how-know-linux-distribution-i-am-using.html

I would suggest we all try this script on various distributions we have
access to and see how good it does. If it works, converting it into a
Python helper would be the next step.

It reports CentOS 7 as "centos"

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

Re: Determining Linux Distribution

[Karel Gardas]

On 9/9/20 10:30 PM, Joel Sherrill wrote:
> It reports CentOS 7 as "centos"

Ubuntu 18.04 -> Ubuntu

and now in linux containers (if you are curious, but I would bet you get
the same result on local installed system too):

Ubuntu 20.04 -> Ubuntu
CentOS 8 -> centos
Debian 10 -> os
OpenSUSE 15.2 -> os
Alpine 3.12 -> alpine
Kali 2020.03 -> os

so Debian, Kali and OpenSuSE at least are not well handled by this
script and it's quite fun since simple:

cat /etc/os-release |grep "^ID="|cut -d '=' -f 2-

works on all of them above providing kind of meaningful answer:

Ubuntu 18.04 -> ubuntu
Ubuntu 20.04 -> ubuntu
CentOS 7 -> "centos"
CentOS 8 -> "centos"
Debian 10 -> debian
OpenSUSE 15.2 -> "opensuse-leap"
Alpine 3.12 -> alpine
Kali 2020.03 -> kali

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

Re: Determining Linux Distribution

[Karel Gardas]

On 9/9/20 11:03 PM, Karel Gardas wrote:
> so Debian, Kali and OpenSuSE at least are not well handled by this
> script and it's quite fun since simple:

Can't judge author of the script. The post is from 2008! So I guess
/etc/os-release was not so wide spread among the Linuxes at that time...
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Determining Linux Distribution

[Joel Sherrill]

On Wed, Sep 9, 2020 at 4:06 PM Karel Gardas  wrote:

> On 9/9/20 11:03 PM, Karel Gardas wrote:
> > so Debian, Kali and OpenSuSE at least are not well handled by this
> > script and it's quite fun since simple:
>
> Can't judge author of the script. The post is from 2008! So I guess
> /etc/os-release was not so wide spread among the Linuxes at that time...
>

That looks promising and linux.py in rtems-toolkit should be easy to make
do that.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Determining Linux Distribution

[Chris Johns]

On 10/9/20 8:15 am, Joel Sherrill wrote:
> On Wed, Sep 9, 2020 at 4:06 PM Karel Gardas  > wrote:
> 
> On 9/9/20 11:03 PM, Karel Gardas wrote:
> > so Debian, Kali and OpenSuSE at least are not well handled by this
> > script and it's quite fun since simple:
> 
> Can't judge author of the script. The post is from 2008! So I guess
> /etc/os-release was not so wide spread among the Linuxes at that time...
> 
> That looks promising and linux.py in rtems-toolkit should be easy to make do 
> that.

The code in linux.py that calls platform.dist() should be removed because the
call has been removed from Python 3 after 3.5.

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

Re: [PATCH v1 2/6] waf: Add path-mappings feature

[Chris Johns]

On 15/8/20 5:57 am, Jan Sommer wrote:
> - path-mappings allow to fix autogenerated include paths for some corner
> cases of target platforms without the need to change the build system
> - Currently used for i386 based bsps

I will need to take in this patch into my development libbsd branchs and merge.
I will try and get this done ASAP.

I am refactoring parts of the libbsd builder.py and related files to separate
the user and kernel space headers. There are conflicts in these files that
become apparent with some of the FreeBSD source. It looks like I based my work
on this patch and these changes so I hope it will be easy to sort out. I would
prefer to bring this into my branch, sort out what is happening and push them.
Sorry this will not happen today but it will get done as it is top of my list.

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

Re: We are loosing patches

[Chris Johns]

On 10/9/20 1:04 am, Thomas Doerfler wrote:
> 
> just a brief note from holidays:

Great to hear. Enjoy yourselves.

> Am 09.09.20 um 15:19 schrieb Joel Sherrill:
> 
>> All system administration on rtems.org  is volunteer. 
>> That by itself is the
>> biggest barrier. 
> 
> We've talked collecting funds through a foundation. How can we push that
> to at least partly professionalize the administration?

The foundation is a key part of this and it is great you ask. I happened to give
that effort a little shake today. I hope we have some movement soon.

The other part is defining the projects, obtaining the resources, managing the
projects and signing off the completed works. The foundation has no resources
capable of doing this, it has no processes or procedures.

> IMHO we are stuck with "I want to do X when I find proper time for it".
> Collecting (constant?) funds may solve this a bit. Other open source
> projects made this move quite successfully.

Yes, we need to have this happen.

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