[PATCH] config: CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS

2019-12-17 Thread Sebastian Huber 
Rename CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS into
CONFIGURE_MAXIMUM_FILE_DESCRIPTORS.

Update #3753.
---
 cpukit/include/rtems/confdefs.h| 11 ---
 cpukit/libmisc/dummy/default-configuration.c   |  2 +-
 testsuites/fstests/fsbdpart01/init.c   |  2 +-
 testsuites/fstests/fsclose01/init.c|  2 +-
 testsuites/fstests/fsdosfsformat01/init.c  |  2 +-
 testsuites/fstests/fsdosfsname01/init.c|  2 +-
 testsuites/fstests/fsdosfsname02/init.c|  2 +-
 testsuites/fstests/fsdosfssync01/init.c|  2 +-
 testsuites/fstests/fsdosfswrite01/init.c   |  2 +-
 testsuites/fstests/fsfseeko01/init.c   |  2 +-
 testsuites/fstests/fsimfsconfig01/init.c   |  2 +-
 testsuites/fstests/fsimfsconfig03/init.c   |  2 +-
 testsuites/fstests/fsimfsgeneric01/init.c  |  2 +-
 testsuites/fstests/fsrofs01/init.c |  2 +-
 testsuites/fstests/imfs_support/fs_support.c   |  2 +-
 testsuites/fstests/jffs2_support/fs_support.c  |  2 +-
 testsuites/fstests/mdosfs_support/fs_support.c |  2 +-
 testsuites/fstests/mimfs_support/fs_support.c  |  2 +-
 testsuites/fstests/mrfs_support/fs_support.c   |  2 +-
 testsuites/libtests/block01/init.c |  2 +-
 testsuites/libtests/block02/init.c |  2 +-
 testsuites/libtests/block03/init.c |  2 +-
 testsuites/libtests/block04/init.c |  2 +-
 testsuites/libtests/block05/init.c |  2 +-
 testsuites/libtests/block06/init.c |  2 +-
 testsuites/libtests/block07/init.c |  2 +-
 testsuites/libtests/block08/system.h   |  2 +-
 testsuites/libtests/block09/init.c |  2 +-
 testsuites/libtests/block10/init.c |  2 +-
 testsuites/libtests/block11/init.c |  2 +-
 testsuites/libtests/block12/init.c |  2 +-
 testsuites/libtests/block13/init.c |  2 +-
 testsuites/libtests/block14/init.c |  2 +-
 testsuites/libtests/block15/init.c |  2 +-
 testsuites/libtests/block16/init.c |  2 +-
 testsuites/libtests/devfs02/init.c |  2 +-
 testsuites/libtests/devfs03/init.c |  2 +-
 testsuites/libtests/devfs04/init.c |  2 +-
 testsuites/libtests/deviceio01/init.c  |  2 +-
 testsuites/libtests/dl01/init.c|  2 +-
 testsuites/libtests/dl02/init.c|  2 +-
 testsuites/libtests/dl03/init.c|  2 +-
 testsuites/libtests/dl04/init.c|  2 +-
 testsuites/libtests/dl05/init.c|  2 +-
 testsuites/libtests/dl06/initimpl.h|  2 +-
 testsuites/libtests/dl07/init.c|  2 +-
 testsuites/libtests/dl08/init.c|  2 +-
 testsuites/libtests/dl09/init.c|  2 +-
 testsuites/libtests/dl10/init.c|  2 +-
 testsuites/libtests/flashdisk01/init.c |  2 +-
 testsuites/libtests/ftp01/init.c   |  2 +-
 testsuites/libtests/i2c01/init.c   |  2 +-
 testsuites/libtests/mghttpd01/init.c   |  2 +-
 testsuites/libtests/mouse01/init.c |  2 +-
 testsuites/libtests/newlib01/init.c|  2 +-
 testsuites/libtests/pwdgrp01/init.c|  2 +-
 testsuites/libtests/pwdgrp02/init.c|  2 +-
 testsuites/libtests/record01/init.c|  2 +-
 testsuites/libtests/shell01/init.c |  2 +-
 testsuites/libtests/sparsedisk01/init.c|  2 +-
 testsuites/libtests/spi01/init.c   |  2 +-
 testsuites/libtests/syscall01/init.c   |  2 +-
 testsuites/libtests/tar01/init.c   |  2 +-
 testsuites/libtests/tar02/init.c   |  2 +-
 testsuites/libtests/telnetd01/init.c   |  2 +-
 testsuites/libtests/termios01/init.c   |  2 +-
 testsuites/libtests/termios03/init.c   |  2 +-
 testsuites/libtests/termios04/init.c   |  2 +-
 testsuites/libtests/termios05/init.c   |  2 +-
 testsuites/libtests/termios06/init.c   |  2 +-
 testsuites/libtests/termios07/init.c   |  2 +-
 testsuites/libtests/termios08/init.c   |  2 +-
 testsuites/libtests/termios09/init.c   |  2 +-
 testsuites/libtests/termios10/termios10impl.h  |  2 +-
 testsuites/libtests/ttest01/init.c |  2 +-
 testsuites/libtests/uid01/init.c   |  2 +-
 testsuites/psxtests/psx13/main.c   |  2 +-
 testsuites/psxtests/psxaio01/system.h  |  2 +-
 testsuites/psxtests/psxaio02/system.h  |  2 +-
 testsuites/psxtests/psxaio03/system.h  |  2 +-
 testsuites/psxtests/psxchroot01/main.c |  2 +-
 testsuites/psxtests/psxconfig01/init.c |  8 
 testsuites/psxtests/psxfchx01/init.c   |  2 +-
 testsuites/psxtests/psxfenv01/init.c   |  2 +-
 testsuites/psxtests/psxfile01/main.c   |  2 +-
 testsuites/psxtests/psxfile02/init.c   |  2 +-
 testsuites/psxtests/psxfilelock01/init.c   |  2 +-
 tes

What should confdefs.h do if CONFIGURE_INIT is not defined?

2019-12-17 Thread Sebastian Huber 

Hello,

I plan to move content from confdefs.h to separate header files for 
configuration groups. What should confdefs.h do if CONFIGURE_INIT is not 
defined?


Should we do the consistency checks for example if CONFIGURE_INIT is not 
defined, e.g.


#if defined(CONFIGURE_UNLIMITED_OBJECTS)
  #if !defined(CONFIGURE_UNIFIED_WORK_AREAS) && \
 !defined(CONFIGURE_EXECUTIVE_RAM_SIZE) && \
 !defined(CONFIGURE_MEMORY_OVERHEAD)
 #error "CONFIGURE_UNLIMITED_OBJECTS requires a unified work area, 
an executive RAM size, or a defined workspace memory overhead"

  #endif

vs.

#ifdef CONFIGURE_INIT
#if defined(CONFIGURE_UNLIMITED_OBJECTS)
  #if !defined(CONFIGURE_UNIFIED_WORK_AREAS) && \
 !defined(CONFIGURE_EXECUTIVE_RAM_SIZE) && \
 !defined(CONFIGURE_MEMORY_OVERHEAD)
 #error "CONFIGURE_UNLIMITED_OBJECTS requires a unified work area, 
an executive RAM size, or a defined workspace memory overhead"

  #endif

What about includes, e.g.

#ifdef CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
  #include 

  #ifdef CONFIGURE_INIT
RTEMS_SYSINIT_ITEM(
  _Clock_Initialize,
  RTEMS_SYSINIT_DEVICE_DRIVERS,
  RTEMS_SYSINIT_ORDER_THIRD
);
  #endif
#endif

vs.

#ifdef CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
  #ifdef CONFIGURE_INIT
#include 

RTEMS_SYSINIT_ITEM(
  _Clock_Initialize,
  RTEMS_SYSINIT_DEVICE_DRIVERS,
  RTEMS_SYSINIT_ORDER_THIRD
);
  #endif
#endif

?

My approach would be to place all the define evaluations into a #ifdef 
CONFIGURE_INIT guard, so that #include  provides 
nothing to the C compiler if CONFIGURE_INIT is not defined.


--
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] config: CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE

2019-12-17 Thread Sebastian Huber 
Remove CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE.

Update #3844.
---
 cpukit/include/rtems/confdefs.h | 58 -
 1 file changed, 28 insertions(+), 30 deletions(-)

diff --git a/cpukit/include/rtems/confdefs.h b/cpukit/include/rtems/confdefs.h
index 05dfc3c91a..7c7b6fc601 100644
--- a/cpukit/include/rtems/confdefs.h
+++ b/cpukit/include/rtems/confdefs.h
@@ -1557,8 +1557,6 @@ extern rtems_initialization_tasks_table 
Initialization_tasks[];
   #include 
 #endif
 
-#ifndef CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE
-
 /**
  * This specifies the maximum number of device drivers that
  * can be installed in the system at one time.  It must account
@@ -1622,8 +1620,6 @@ extern rtems_initialization_tasks_table 
Initialization_tasks[];
 RTEMS_ARRAY_SIZE( _IO_Driver_address_table );
 #endif
 
-#endif  /* CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE */
-
 #ifdef CONFIGURE_APPLICATION_NEEDS_ATA_DRIVER
   /*
* configure the priority of the ATA driver task
@@ -2986,33 +2982,31 @@ struct _reent *__getreent(void)
 #endif
 
 #if !defined(RTEMS_SCHEDSIM)
-  #if !defined(CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE)
-/*
- *  You must either explicity include or exclude the clock driver.
- *  It is such a common newbie error to leave it out.  Maybe this
- *  will put an end to it.
- *
- *  NOTE: If you are using the timer driver, it is considered
- *mutually exclusive with the clock driver because the
- *drivers are assumed to use the same "timer" hardware
- *on many boards.
- */
-#if !defined(CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER) && \
-!defined(CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER) && \
-!defined(CONFIGURE_APPLICATION_NEEDS_TIMER_DRIVER)
-  #error "CONFIGURATION ERROR: Do you want the clock driver or not?!?"
- #endif
+/*
+ *  You must either explicitly include or exclude the clock driver.
+ *  It is such a common newbie error to leave it out.  Maybe this
+ *  will put an end to it.
+ *
+ *  NOTE: If you are using the timer driver, it is considered
+ *mutually exclusive with the clock driver because the
+ *drivers are assumed to use the same "timer" hardware
+ *on many boards.
+ */
+#if !defined(CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER) && \
+!defined(CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER) && \
+!defined(CONFIGURE_APPLICATION_NEEDS_TIMER_DRIVER)
+  #error "CONFIGURATION ERROR: Do you want the clock driver or not?!?"
+ #endif
 
-/*
- * Only one of the following three configuration parameters should be
- * defined at a time.
- */
-#if ((defined(CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER) + \
-  defined(CONFIGURE_APPLICATION_NEEDS_TIMER_DRIVER) + \
-  defined(CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER)) > 1)
-   #error "CONFIGURATION ERROR: More than one clock/timer driver 
configuration parameter specified?!?"
-#endif
-  #endif /* !defined(CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE) */
+/*
+ * Only one of the following three configuration parameters should be
+ * defined at a time.
+ */
+#if ((defined(CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER) + \
+  defined(CONFIGURE_APPLICATION_NEEDS_TIMER_DRIVER) + \
+  defined(CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER)) > 1)
+   #error "CONFIGURATION ERROR: More than one clock/timer driver configuration 
parameter specified?!?"
+#endif
 #endif   /* !defined(RTEMS_SCHEDSIM) */
 
 /*
@@ -3047,6 +3041,10 @@ struct _reent *__getreent(void)
   #warning "The CONFIGURE_HAS_OWN_CONFIGURATION_TABLE configuration option is 
obsolete since RTEMS 5.1"
 #endif
 
+#ifdef CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE
+  #warning "The CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE configuration option is 
obsolete since RTEMS 5.1"
+#endif
+
 #ifdef CONFIGURE_HAS_OWN_FILESYSTEM_TABLE
   #warning "The CONFIGURE_HAS_OWN_FILESYSTEM_TABLE configuration option is 
obsolete since RTEMS 5.1"
 #endif
-- 
2.16.4

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

[PATCH] c-user: CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE

2019-12-17 Thread Sebastian Huber 
Remove CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE.

Close #3844.
---
 c-user/configuring_a_system.rst | 40 
 1 file changed, 8 insertions(+), 32 deletions(-)

diff --git a/c-user/configuring_a_system.rst b/c-user/configuring_a_system.rst
index 17278c0..7eb472b 100644
--- a/c-user/configuring_a_system.rst
+++ b/c-user/configuring_a_system.rst
@@ -4406,38 +4406,6 @@ DESCRIPTION:
 NOTES:
 This device driver is supported by all BSPs.
 
-.. index:: CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE
-
-.. _CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE:
-
-CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE
--
-
-CONSTANT:
-``CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE``
-
-DATA TYPE:
-Boolean feature macro.
-
-RANGE:
-Defined or undefined.
-
-DEFAULT VALUE:
-This is not defined by default, indicating the  is
-providing the device driver table.
-
-DESCRIPTION:
-``CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE`` is defined if the application
-wishes to provide their own Device Driver Table.
-
-The table must be an array of ``rtems_driver_address_table`` entries
-named`` _IO_Driver_address_table``.  The application must also provide a
-const variable ``_IO_Number_of_drivers`` of type ``size_t`` indicating the
-number of entries in the ``_IO_Driver_address_table``.
-
-NOTES:
-It is expected that there the application would only rarely need to do 
this.
-
 Multiprocessing Configuration
 =
 
@@ -4876,6 +4844,14 @@ CONFIGURE_HAS_OWN_BDBUF_TABLE
 This configuration option was introduced in RTEMS 4.7.0 and is obsolete since
 RTEMS 4.10.0.
 
+.. index:: CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE
+
+CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE
+-
+
+This configuration option was present in all RTEMS versions since at least 1995
+and is obsolete since RTEMS 5.1.
+
 .. index:: CONFIGURE_HAS_OWN_MOUNT_TABLE
 
 CONFIGURE_HAS_OWN_MOUNT_TABLE
-- 
2.16.4

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

[PATCH] c-user: CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS

2019-12-17 Thread Sebastian Huber 
Rename CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS in
CONFIGURE_MAXIMUM_FILE_DESCRIPTORS.

Close #3753.
---
 c-user/configuring_a_system.rst | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/c-user/configuring_a_system.rst b/c-user/configuring_a_system.rst
index 7eb472b..6e680c2 100644
--- a/c-user/configuring_a_system.rst
+++ b/c-user/configuring_a_system.rst
@@ -529,16 +529,16 @@ NOTES:
 :ref:`CONFIGURE_MINIMUM_TASK_STACK_SIZE
 ` instead of ``CPU_STACK_MINIMUM_SIZE``.
 
-.. index:: CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS
+.. index:: CONFIGURE_MAXIMUM_FILE_DESCRIPTORS
 .. index:: maximum file descriptors
 
-.. _CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS:
+.. _CONFIGURE_MAXIMUM_FILE_DESCRIPTORS:
 
-CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS
-
+CONFIGURE_MAXIMUM_FILE_DESCRIPTORS
+--
 
 CONSTANT:
-``CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS``
+``CONFIGURE_MAXIMUM_FILE_DESCRIPTORS``
 
 DATA TYPE:
 Unsigned integer (``uint32_t``).
@@ -4866,12 +4866,13 @@ CONFIGURE_HAS_OWN_MULTIPROCESSING_TABLE
 
 This configuration option is obsolete since RTEMS 5.1.
 
-.. index:: CONFIGURE_NUMBER_OF_TERMIOS_PORTS
+.. index:: CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS
 
-CONFIGURE_NUMBER_OF_TERMIOS_PORTS
--
+CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS
+
 
-This configuration option is obsolete since RTEMS 5.1.
+This configuration option was present in all RTEMS versions since at 1998 and 
is
+obsolete since RTEMS 5.1.  See also :ref:`CONFIGURE_MAXIMUM_FILE_DESCRIPTORS`.
 
 .. index:: CONFIGURE_MAXIMUM_GO_CHANNELS
 
@@ -4894,6 +4895,13 @@ CONFIGURE_MAXIMUM_MRSP_SEMAPHORES
 
 This configuration option is obsolete since RTEMS 5.1.
 
+.. index:: CONFIGURE_NUMBER_OF_TERMIOS_PORTS
+
+CONFIGURE_NUMBER_OF_TERMIOS_PORTS
+-
+
+This configuration option is obsolete since RTEMS 5.1.
+
 .. index:: CONFIGURE_MAXIMUM_POSIX_BARRIERS
 
 CONFIGURE_MAXIMUM_POSIX_BARRIERS
-- 
2.16.4

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

Ada configuration options

2019-12-17 Thread Sebastian Huber 

Hello,

we have currently three Ada related configuration options:

* CONFIGURE_GNAT_RTEMS

* CONFIGURE_MAXIMUM_ADA_TASKS

* CONFIGURE_MAXIMUM_FAKE_ADA_TASKS

The CONFIGURE_MAXIMUM_FAKE_ADA_TASKS option has no effect.  The 
CONFIGURE_GNAT_RTEMS is mandatory to use the CONFIGURE_MAXIMUM_ADA_TASKS 
option. So, if you just use


#define CONFIGURE_MAXIMUM_ADA_TASKS 123

then you get a re-definition warning and hopefully pay attention to it. 
This is not very user friendly from point of view.


The CONFIGURE_MAXIMUM_ADA_TASKS just adds the configured count to 
CONFIGURE_MAXIMUM_POSIX_THREADS.


I would obsolete all three options.

--
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: Ada configuration options

2019-12-17 Thread Joel Sherrill 
On Tue, Dec 17, 2019 at 3:45 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> we have currently three Ada related configuration options:
>
> * CONFIGURE_GNAT_RTEMS
>
> * CONFIGURE_MAXIMUM_ADA_TASKS
>
> * CONFIGURE_MAXIMUM_FAKE_ADA_TASKS
>
> The CONFIGURE_MAXIMUM_FAKE_ADA_TASKS option has no effect.  The
> CONFIGURE_GNAT_RTEMS is mandatory to use the CONFIGURE_MAXIMUM_ADA_TASKS
> option. So, if you just use
>
> #define CONFIGURE_MAXIMUM_ADA_TASKS 123
>
> then you get a re-definition warning and hopefully pay attention to it.
> This is not very user friendly from point of view.
>
> The CONFIGURE_MAXIMUM_ADA_TASKS just adds the configured count to
> CONFIGURE_MAXIMUM_POSIX_THREADS.
>
> I would obsolete all three options.
>

The original purpose of these was to:

CONFIGURE_GNAT_RTEMS - add in resources required by Ada run-time independent
of the number of Ada tasks (e.g. POSIX threads)

CONFIGURE_MAXIMUM_ADA_TASKS - add in POSIX threads, condition variable,
and mutex required for each Ada task

CONFIGURE_MAXIMUM_FAKE_ADA_TASKS - add in condition variables and mutex
required by Ada run-time for a task/thread created outside the Ada run-time
which
invokes Ada code and is thus a user of the run-time.

Given that you can turn on unlimited threads now and condition variables
and mutexes
are static, I don't think they have a need any longer. Plus it sounds like
they bit rotted.
If we needed them still, they would have to be fixed.

We still need documentation that Ada tasks are POSIX threads and must be
accounted
for in configuring the system. So when moving documentation around, please
make that
point clear in the CONFIGURE_MAXIMUM_POSIX_THREADS description.

--joel

>
> --
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Ada configuration options

2019-12-17 Thread Sebastian Huber 

On 17/12/2019 14:38, Joel Sherrill wrote:



On Tue, Dec 17, 2019 at 3:45 AM Sebastian Huber 
> wrote:


Hello,

we have currently three Ada related configuration options:

* CONFIGURE_GNAT_RTEMS

* CONFIGURE_MAXIMUM_ADA_TASKS

* CONFIGURE_MAXIMUM_FAKE_ADA_TASKS

The CONFIGURE_MAXIMUM_FAKE_ADA_TASKS option has no effect.  The
CONFIGURE_GNAT_RTEMS is mandatory to use the
CONFIGURE_MAXIMUM_ADA_TASKS
option. So, if you just use

#define CONFIGURE_MAXIMUM_ADA_TASKS 123

then you get a re-definition warning and hopefully pay attention to it.
This is not very user friendly from point of view.

The CONFIGURE_MAXIMUM_ADA_TASKS just adds the configured count to
CONFIGURE_MAXIMUM_POSIX_THREADS.

I would obsolete all three options.


The original purpose of these was to:

CONFIGURE_GNAT_RTEMS - add in resources required by Ada run-time independent
of the number of Ada tasks (e.g. POSIX threads)

CONFIGURE_MAXIMUM_ADA_TASKS - add in POSIX threads, condition variable,
and mutex required for each Ada task

CONFIGURE_MAXIMUM_FAKE_ADA_TASKS - add in condition variables and mutex
required by Ada run-time for a task/thread created outside the Ada 
run-time which

invokes Ada code and is thus a user of the run-time.

Given that you can turn on unlimited threads now and condition variables 
and mutexes
are static, I don't think they have a need any longer. Plus it sounds 
like they bit rotted.

If we needed them still, they would have to be fixed.

We still need documentation that Ada tasks are POSIX threads and must be 
accounted
for in configuring the system. So when moving documentation around, 
please make that

point clear in the CONFIGURE_MAXIMUM_POSIX_THREADS description.


Thanks for your comments. I created a ticket:

https://devel.rtems.org/ticket/3845

--
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: What should confdefs.h do if CONFIGURE_INIT is not defined?

2019-12-17 Thread Joel Sherrill 
On Tue, Dec 17, 2019 at 2:43 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> I plan to move content from confdefs.h to separate header files for
> configuration groups. What should confdefs.h do if CONFIGURE_INIT is not
> defined?
>
> Should we do the consistency checks for example if CONFIGURE_INIT is not
> defined, e.g.
>
> #if defined(CONFIGURE_UNLIMITED_OBJECTS)
>#if !defined(CONFIGURE_UNIFIED_WORK_AREAS) && \
>   !defined(CONFIGURE_EXECUTIVE_RAM_SIZE) && \
>   !defined(CONFIGURE_MEMORY_OVERHEAD)
>   #error "CONFIGURE_UNLIMITED_OBJECTS requires a unified work area,
> an executive RAM size, or a defined workspace memory overhead"
>#endif
>
> vs.
>
> #ifdef CONFIGURE_INIT
> #if defined(CONFIGURE_UNLIMITED_OBJECTS)
>#if !defined(CONFIGURE_UNIFIED_WORK_AREAS) && \
>   !defined(CONFIGURE_EXECUTIVE_RAM_SIZE) && \
>   !defined(CONFIGURE_MEMORY_OVERHEAD)
>   #error "CONFIGURE_UNLIMITED_OBJECTS requires a unified work area,
> an executive RAM size, or a defined workspace memory overhead"
>#endif
>
> What about includes, e.g.
>
> #ifdef CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
>#include 
>
>#ifdef CONFIGURE_INIT
>  RTEMS_SYSINIT_ITEM(
>_Clock_Initialize,
>RTEMS_SYSINIT_DEVICE_DRIVERS,
>RTEMS_SYSINIT_ORDER_THIRD
>  );
>#endif
> #endif
>
> vs.
>
> #ifdef CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
>#ifdef CONFIGURE_INIT
>  #include 
>
>  RTEMS_SYSINIT_ITEM(
>_Clock_Initialize,
>RTEMS_SYSINIT_DEVICE_DRIVERS,
>RTEMS_SYSINIT_ORDER_THIRD
>  );
>#endif
> #endif
>
> ?
>
> My approach would be to place all the define evaluations into a #ifdef
> CONFIGURE_INIT guard, so that #include  provides
> nothing to the C compiler if CONFIGURE_INIT is not defined.
>

Originally, the intent was that user code could use CONFIGURE_MAXIMUM_xxx
if CONFIGURE_INIT was not defined. We likely don't do this much in the
tests but
you could have a header file which did all the CONFIGURE_xxx defines, then
include . Every application file could use the
CONFIGURE_xxx
macros if you did an "appconf.h" type header. Then a "appconf.c" could
define
CONFIGURE_INIT and include rtems/confdefs.h.

Do we have all the rtems_xxx which fetch configuration data documented?
Those
may largely cover the use case I described.

Now I generally recommend putting RTEMS configuration and an init task
to start RTEMS services in a dedicated file and invoking main() to start
the application. There are some of the rtems-examples which follow this
pattern.

--joel


> --
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: What should confdefs.h do if CONFIGURE_INIT is not defined?

2019-12-17 Thread Sebastian Huber 



On 17/12/2019 15:13, Joel Sherrill wrote:


My approach would be to place all the define evaluations into a #ifdef
CONFIGURE_INIT guard, so that #include  provides
nothing to the C compiler if CONFIGURE_INIT is not defined.


Originally, the intent was that user code could use CONFIGURE_MAXIMUM_xxx
if CONFIGURE_INIT was not defined. We likely don't do this much in the 
tests but

you could have a header file which did all the CONFIGURE_xxx defines, then
include . Every application file could use the 
CONFIGURE_xxx
macros if you did an "appconf.h" type header. Then a "appconf.c" could 
define

CONFIGURE_INIT and include rtems/confdefs.h.


Ok, this is an interesting use case. I am not sure if it is a good 
application design if the global limits are widely visible and used.


I guess exposing the header includes is not necessary for this use case.

For this the general pattern would be:

#ifndef XXX
#define XXX default
#endif

#ifdef CONFIGURE_INIT
#if XXX needs configured data structures
#include 
XXX xxx_config;
#endif
#endif



Do we have all the rtems_xxx which fetch configuration data documented? 
Those

may largely cover the use case I described.


Yes, but you have to make a trade-off between compile-time and link-time 
constants.



Now I generally recommend putting RTEMS configuration and an init task
to start RTEMS services in a dedicated file and invoking main() to start
the application. There are some of the rtems-examples which follow this 
pattern.


Yes, this is in line with what I have seen in applications.

--
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

[rtems-tools PATCH] record: Allow to compile with recent llvm version.

2019-12-17 Thread list 
From: Christian Mauderer 

It seems that the API for symbolizeCode changed between llvm8 and llvm9.
This patch uses the same adaption that is used for the llvm-symbolizer
tool in llvm commit b2c4b8bded3ff2efaaebe0d8b33c65116f9ef8de.
---
 trace/record/record-main-lttng.cc | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/trace/record/record-main-lttng.cc 
b/trace/record/record-main-lttng.cc
index f37106b284..c84f40b14d 100644
--- a/trace/record/record-main-lttng.cc
+++ b/trace/record/record-main-lttng.cc
@@ -323,7 +323,12 @@ LTTNGClient::AddressToLineMap::iterator 
LTTNGClient::ResolveAddress(
 const ClientItem& item) {
 #ifdef HAVE_LLVM_DEBUGINFO_SYMBOLIZE_SYMBOLIZE_H
   if (resolve_address_) {
-auto res_or_err = symbolizer_.symbolizeCode(elf_file_, item.data);
+auto res_or_err = symbolizer_.symbolizeCode(elf_file_,
+#if LLVM_VERSION_MAJOR >= 9
+  {item.data, llvm::object::SectionedAddress::UndefSection});
+#else
+  item.data);
+#endif
 
 if (res_or_err) {
   auto info = res_or_err.get();
-- 
2.24.0

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

[rtems-tools] record does not compile with llvm9

2019-12-17 Thread list 
Hello,

if I try to compile the rtems-tools on my Arch Linux system with a llvm
library version 9 I get the error at the end of the mail. It seems that
the API for symbolizeCode changed between version 8 and 9 of llvm.

I created a patch (see follow up mail) that uses the same adaption like
in llvm-symbolizer.cpp in the official llvm sources:

https://github.com/llvm/llvm-project/commit/b2c4b8bded3ff2efaaebe0d8b33c65116f9ef8de#diff-50901f5ee3b98d3dd5cab7c8edf984faR216

It compiles on llvm9 but I didn't test it on llvm7 or 8. Beneath that
it's an untested change.

Best regards

Christian


Error message:

[240/255] Compiling trace/record/record-client.c
[241/255] Compiling trace/record/record-main-lttng.cc
[242/255] Compiling trace/record/record-text.c
[243/255] Compiling trace/record/record-client-base.cc
[244/255] Linking build/rtemstoolkit/librld.a
[245/255] Linking build/linkers/rtems-ld
[246/255] Linking build/linkers/rtems-addr2line
[247/255] Linking build/tester/covoar/libccovoar.a
[248/255] Linking build/linkers/rtems-ra
[249/255] Linking build/tester/covoar/trace-converter
../trace/record/record-main-lttng.cc: In member function 'std::map > >::iterator 
LTTNGClient::ResolveAddress(const ClientItem&)':
../trace/record/record-main-lttng.cc:329:69: error: no matching function for 
call to 'llvm::symbolize::LLVMSymbolizer::symbolizeCode(std::string&, const 
uint64_t&)'
  329 | auto res_or_err = symbolizer_.symbolizeCode(elf_file_, item.data);
  | ^
In file included from ../trace/record/record-main-lttng.cc:45:
/usr/include/llvm/DebugInfo/Symbolize/Symbolize.h:55:24: note: candidate: 
'llvm::Expected 
llvm::symbolize::LLVMSymbolizer::symbolizeCode(const llvm::object::ObjectFile&, 
llvm::object::SectionedAddress)'
   55 |   Expected symbolizeCode(const ObjectFile &Obj,
  |^
/usr/include/llvm/DebugInfo/Symbolize/Symbolize.h:55:56: note:   no known 
conversion for argument 1 from 'std::string' {aka 
'std::__cxx11::basic_string'} to 'const llvm::object::ObjectFile&'
   55 |   Expected symbolizeCode(const ObjectFile &Obj,
  |  ~~^~~
/usr/include/llvm/DebugInfo/Symbolize/Symbolize.h:57:24: note: candidate: 
'llvm::Expected 
llvm::symbolize::LLVMSymbolizer::symbolizeCode(const string&, 
llvm::object::SectionedAddress)'
   57 |   Expected symbolizeCode(const std::string &ModuleName,
  |^
/usr/include/llvm/DebugInfo/Symbolize/Symbolize.h:58:63: note:   no known 
conversion for argument 2 from 'const uint64_t' {aka 'const long unsigned int'} 
to 'llvm::object::SectionedAddress'
   58 |  object::SectionedAddress 
ModuleOffset);
  |  
~^~~~



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

Re: Problem running RTEMS on raspberrypi3

2019-12-17 Thread Christian Mauderer 
I tried booting it on the Pi 1 without success. So it seems that I
either don't have the right steps or that something is broken. I would
lean to the first one because I don't really have put much time into it.

Do you have any old Pi where you could try it first?

Maybe it would be good to ask whether someone is running a recent RTEMS
on any raspberry?

On 16/12/2019 15:41, Niteesh wrote:
> But I am not able to boot using the 3 stage bootloader. Can someone try
> booting any examples on raspi3 or other newer models? If it's work's please
> post the instructions. The steps that I followed are:
> 1. arm-rtems5-objcopy -Obinary hello.exe kernel.img
> 2. copied the kernel image to sd card and modified the config.txt to
> load the kernel img.
> No success in following these steps. 
> I think this is maybe because of the different start addresses. The
> default kernel load address for raspberry pi is 0x8000 in 32bit mode and
> 0x8 in 64bit mode.
> but RTEMS has a start address of 0x200080.
> 
> 
> On Mon, Dec 16, 2019 at 7:51 PM Christian Mauderer  > wrote:
> 
> I think I have guided you to a wrong path here. I mentioned U-Boot
> because it is often used on a lot of evaluation boards. In the raspberry
> case it seems that the stage 3 loader is something different. But
> everything should work with that stage 3 loader. I don't think that
> U-Boot is necessary.
> 
> On 16/12/2019 14:01, Niteesh wrote:
> > I got uboot running on my raspi3. But I can't figure out to load
> and run
> > a custom kernel. Can you explain the steps or point me to some
> > reference.
> > On Mon, Dec 16, 2019 at 5:13 PM Niteesh  
> > >> wrote:
> >
> >     On Mon, Dec 16, 2019 at 2:36 AM Christian Mauderer
> >     mailto:l...@c-mauderer.de>
> >> wrote:
> >
> >
> >
> >         On 15/12/2019 21:29, Niteesh wrote:
> >         >
> >         >
> >         > On Mon, Dec 16, 2019 at 12:53 AM Christian Mauderer
> >         mailto:l...@c-mauderer.de>
> >
> >         > 
>  >         >
> >         >     On 15/12/2019 19:46, Niteesh wrote:
> >         >     >
> >         >     >
> >         >     > On Sun, Dec 15, 2019 at 10:15 PM Christian Mauderer
> >         >     mailto:l...@c-mauderer.de>
> >
> >         
> >>
> >         >     >    >
> >         
>  wrote:
> >         >     >
> >         >     >     Hello Niteesh,
> >         >     >
> >         >     >     On 15/12/2019 09:05, Niteesh wrote:
> >         >     >     > I am trying to get RTEMS examples running on the
> >         RPI3, the
> >         >     RPI3 is
> >         >     >     > similar to RPI2 so the examples built for
> RPI2 should
> >         >     technically
> >         >     >     run on
> >         >     >     > the RPi3.But they don't :(, I am really sure of
> >         what is causing
> >         >     >     the problem.
> >         >     >
> >         >     >     Note that there are at least two different
> versions
> >         of the
> >         >     RPi3 which
> >         >     >     use different chips. The original RPi3 which
> uses a
> >         BCM2837
> >         >     (same like
> >         >     >     later versions of RPi2) and the RPi3+ which uses a
> >         BCM2837B0.
> >         >     Broadcom
> >         >     >     is always quite sparse with documentation so it's
> >         not easy to
> >         >     tell the
> >         >     >     differences. Which one do you have?
> >         >     >
> >         >     > I have Rpi3 model b v1.2 which uses BCM2837 SOC, in my
> >         bare-metal
> >         >     > programming I used the 
> >         >     > 2835 doc as a reference because the only major
> >         difference these
> >         >     two SOC
> >         >     > is the peripheral base address
> >         >     > offset. But this is arm cpu is also capable of
> >         executing in 64bit
> >         >     mode.
> >         >
> >         >     OK. Did you check, whether the offset is correct? In the
> > 

Re: Problem running RTEMS on raspberrypi3

2019-12-17 Thread Christian Mauderer 
That handler doesn't look like an RTEMS handler. So it failed at a very
early stage.

Did you try a go 0x20 instead? Normally the first vector is a reset
vector which jumps to the right start address. The jump can have a mode
with it. So if you directly jump to 0x200080 the core might is in a
wrong mode.

On 16/12/2019 15:54, Niteesh wrote:
> What about using U-boot? I just tried running my own bare metal example
> using u-boot and it works fine.
> The 3rd stage bootloader start the u-boot and I was able to interact
> with it through serial. and then I used
> fatload mmc 0 0x8000 kernel.img ; go 0x8000
> to load and run the img. I tried the same for rtems 
> fatload mmc 0 0x20 rtems_kernel.img ; go 0x200080
> but this result's in a 
> 
> ## Starting application at 0x00200080 ...
> "Synchronous Abort" handler, esr 0x0200
> elr: c1d29080 lr : 000838b0 (reloc)
> elr: 00200080 lr : 3e55a8b0
> x0 : 0001 x1 : 3e15e6c8
> x2 : 3e15e6c8 x3 : 00200080
> x4 :  x5 : 
> x6 : 00c0c0c0 x7 : 000f
> x8 : ffd0 x9 : 0008
> x10: 0010 x11: 3e159cc0
> x12:  x13: 0200
> x14: 0005 x15: 0008
> x16:  x17: 0020
> x18: 3e152de0 x19: 3e15e6c8
> x20: 0002 x21: 00200080
> x22: 3e15e6c0 x23: 0002
> x24: 3e5d4d44 x25: 
> x26:  x27: 
> x28: 3e1567e0 x29: 3e152b20
> 
> Code: 0020b048 0020b048 0020b048 0020b048 (e1a05001)
> Resetting CPU ...
> 
> 
> On Mon, Dec 16, 2019 at 8:11 PM Niteesh  > wrote:
> 
> But I am not able to boot using the 3 stage bootloader. Can someone
> try booting any examples on raspi3 or other newer models? If it's
> work's please
> post the instructions. The steps that I followed are:
> 1. arm-rtems5-objcopy -Obinary hello.exe kernel.img
> 2. copied the kernel image to sd card and modified the config.txt to
> load the kernel img.
> No success in following these steps. 
> I think this is maybe because of the different start addresses. The
> default kernel load address for raspberry pi is 0x8000 in 32bit mode
> and 0x8 in 64bit mode.
> but RTEMS has a start address of 0x200080.
> 
> 
> On Mon, Dec 16, 2019 at 7:51 PM Christian Mauderer
> mailto:l...@c-mauderer.de>> wrote:
> 
> I think I have guided you to a wrong path here. I mentioned U-Boot
> because it is often used on a lot of evaluation boards. In the
> raspberry
> case it seems that the stage 3 loader is something different. But
> everything should work with that stage 3 loader. I don't think that
> U-Boot is necessary.
> 
> On 16/12/2019 14:01, Niteesh wrote:
> > I got uboot running on my raspi3. But I can't figure out to
> load and run
> > a custom kernel. Can you explain the steps or point me to some
> > reference.
> > On Mon, Dec 16, 2019 at 5:13 PM Niteesh  
> > >> wrote:
> >
> >     On Mon, Dec 16, 2019 at 2:36 AM Christian Mauderer
> >     mailto:l...@c-mauderer.de>
> >> wrote:
> >
> >
> >
> >         On 15/12/2019 21:29, Niteesh wrote:
> >         >
> >         >
> >         > On Mon, Dec 16, 2019 at 12:53 AM Christian Mauderer
> >         mailto:l...@c-mauderer.de>
> >
> >         >     >         >
> >         >     On 15/12/2019 19:46, Niteesh wrote:
> >         >     >
> >         >     >
> >         >     > On Sun, Dec 15, 2019 at 10:15 PM Christian
> Mauderer
> >         >     mailto:l...@c-mauderer.de>
> >
> >         
> >>
> >         >     >    >
> >         
>  wrote:
> >         >     >
> >         >     >     Hello Niteesh,
> >         >     >
>

Re: What should confdefs.h do if CONFIGURE_INIT is not defined?

2019-12-17 Thread Chris Johns 
On 18/12/19 1:28 am, Sebastian Huber wrote:
> On 17/12/2019 15:13, Joel Sherrill wrote:
>> Now I generally recommend putting RTEMS configuration and an init task
>> to start RTEMS services in a dedicated file and invoking main() to start
>> the application. There are some of the rtems-examples which follow this 
>> pattern.
> 
> Yes, this is in line with what I have seen in applications.

+1

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

Re: [rtems-tools] record does not compile with llvm9

2019-12-17 Thread Sebastian Huber 

On 17/12/2019 15:48, l...@c-mauderer.de wrote:

It compiles on llvm9 but I didn't test it on llvm7 or 8. Beneath that
it's an untested change.


It works on llvm7. Please check it in.

--
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