[PATCH 1/3] rtems/confdefs.h add another initial extension set
This adds back the capability for the BSP to configure an initial extension that is specific to itself. The parameter BSP_INITIAL_EXTENSION was taken over by having a standard fatal extension installed using the same name. --- cpukit/include/rtems/confdefs.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/cpukit/include/rtems/confdefs.h b/cpukit/include/rtems/confdefs.h index 5eb5425..e1a255a 100644 --- a/cpukit/include/rtems/confdefs.h +++ b/cpukit/include/rtems/confdefs.h @@ -2136,6 +2136,9 @@ extern rtems_initialization_tasks_table Initialization_tasks[]; #if defined(CONFIGURE_INITIAL_EXTENSIONS) CONFIGURE_INITIAL_EXTENSIONS, #endif +#if defined(BSP_INITIAL2_EXTENSIONS) + BSP_INITIAL2_EXTENSIONS, +#endif #if defined(BSP_INITIAL_EXTENSION) BSP_INITIAL_EXTENSION #endif -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 3/3] cpukit/headers.am: Regenerate
--- cpukit/headers.am | 1 + 1 file changed, 1 insertion(+) diff --git a/cpukit/headers.am b/cpukit/headers.am index 3386f77..e9d266d 100644 --- a/cpukit/headers.am +++ b/cpukit/headers.am @@ -183,6 +183,7 @@ include_rtems_HEADERS += include/rtems/userenv.h include_rtems_HEADERS += include/rtems/version.h include_rtems_HEADERS += include/rtems/vmeintr.h include_rtems_HEADERS += include/rtems/watchdogdrv.h +include_rtems_debugger_HEADERS += include/rtems/debugger/rtems-debugger-bsp.h include_rtems_debugger_HEADERS += include/rtems/debugger/rtems-debugger-remote.h include_rtems_debugger_HEADERS += include/rtems/debugger/rtems-debugger-server.h include_rtems_posix_HEADERS += include/rtems/posix/aio_misc.h -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/3] Add hook for BSP to act when time is set
This hook is only enabled when paravirtualized. It allows
the application running on RTEMS in a paravirtualized
environment to have its set time operations impact
the hosting environment. This requires support specific
to the paravirtualized environment. The hosting environment
may refuse to let the paravirtualized application set the
time and this is reflected to the application as a
permissions or not owner of resource issue.
---
cpukit/headers.am| 1 +
cpukit/include/rtems/score/tod.h | 51
cpukit/include/rtems/score/todimpl.h | 8 +-
cpukit/posix/src/clocksettime.c | 6 -
cpukit/rtems/src/clockset.c | 6 -
cpukit/score/src/coretodadjust.c | 2 +-
cpukit/score/src/coretodset.c| 15 ++-
7 files changed, 84 insertions(+), 5 deletions(-)
create mode 100644 cpukit/include/rtems/score/tod.h
diff --git a/cpukit/headers.am b/cpukit/headers.am
index 008b7cc..3386f77 100644
--- a/cpukit/headers.am
+++ b/cpukit/headers.am
@@ -399,6 +399,7 @@ include_rtems_score_HEADERS +=
include/rtems/score/timespec.h
include_rtems_score_HEADERS += include/rtems/score/timestamp.h
include_rtems_score_HEADERS += include/rtems/score/timestampimpl.h
include_rtems_score_HEADERS += include/rtems/score/tls.h
+include_rtems_score_HEADERS += include/rtems/score/tod.h
include_rtems_score_HEADERS += include/rtems/score/todimpl.h
include_rtems_score_HEADERS += include/rtems/score/userext.h
include_rtems_score_HEADERS += include/rtems/score/userextdata.h
diff --git a/cpukit/include/rtems/score/tod.h b/cpukit/include/rtems/score/tod.h
new file mode 100644
index 000..3b06642
--- /dev/null
+++ b/cpukit/include/rtems/score/tod.h
@@ -0,0 +1,51 @@
+/**
+ * @file
+ *
+ * @ingroup ScoreTOD
+ *
+ * @brief Time of Day Handler API
+ */
+
+/*
+ * COPYRIGHT (c) 1989-2009.
+ * On-Line Applications Research Corporation (OAR).
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+#ifndef _RTEMS_SCORE_TOD_H
+#define _RTEMS_SCORE_TOD_H
+
+#include
+
+#include
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#if defined(RTEMS_PARAVIRT)
+/**
+ * @brief Method Invoked When TOD is Set
+ *
+ * This method is invoked when the TOD is set. It can be overridden
+ * by the BSP to allow it to set the TOD in the host in a paravirtualized
+ * environment.
+ *
+ * @param tod points to the new TOD
+ *
+ * @note This is invoked with the TOD locked.
+ */
+bool _TOD_Set_hook(
+ const struct timespec *tod
+);
+#endif
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif
+/* end of include file */
diff --git a/cpukit/include/rtems/score/todimpl.h
b/cpukit/include/rtems/score/todimpl.h
index 0d4faac..25bb979 100644
--- a/cpukit/include/rtems/score/todimpl.h
+++ b/cpukit/include/rtems/score/todimpl.h
@@ -183,8 +183,14 @@ static inline void _TOD_Acquire( ISR_lock_Context
*lock_context )
* @param lock_context The ISR lock context used for the corresponding
* _TOD_Acquire(). The caller must be the owner of the TOD lock. This
* function will release the TOD lock.
+ *
+ * @note This method currently always returns true in non-paravirtualized
+ * configuration. In a paravirtualized envivonment, it may fail if
+ * the container does not have permission to set the time.
+ *
+ * @return This method returns true if successful and false otherwise.
*/
-void _TOD_Set(
+bool _TOD_Set(
const struct timespec *tod,
ISR_lock_Context *lock_context
);
diff --git a/cpukit/posix/src/clocksettime.c b/cpukit/posix/src/clocksettime.c
index a0fdd91..387de4e 100644
--- a/cpukit/posix/src/clocksettime.c
+++ b/cpukit/posix/src/clocksettime.c
@@ -32,6 +32,8 @@ int clock_settime(
const struct timespec *tp
)
{
+ bool rc;
+
if ( !tp )
rtems_set_errno_and_return_minus_one( EINVAL );
@@ -43,8 +45,10 @@ int clock_settime(
_TOD_Lock();
_TOD_Acquire( &lock_context );
-_TOD_Set( tp, &lock_context );
+rc = _TOD_Set( tp, &lock_context );
_TOD_Unlock();
+if (rc == false)
+ rtems_set_errno_and_return_minus_one( EPERM );
}
#ifdef _POSIX_CPUTIME
else if ( clock_id == CLOCK_PROCESS_CPUTIME_ID )
diff --git a/cpukit/rtems/src/clockset.c b/cpukit/rtems/src/clockset.c
index d772682..9acb8d7 100644
--- a/cpukit/rtems/src/clockset.c
+++ b/cpukit/rtems/src/clockset.c
@@ -26,6 +26,8 @@ rtems_status_code rtems_clock_set(
const rtems_time_of_day *tod
)
{
+ bool rc;
+
if ( !tod )
return RTEMS_INVALID_ADDRESS;
@@ -39,8 +41,10 @@ rtems_status_code rtems_clock_set(
_TOD_Lock();
_TOD_Acquire( &lock_context );
-_TOD_Set( &tod_as_timespec, &lock_context );
+rc = _TOD_Set( &tod_as_timespec, &lock_context );
_TOD_Unlock();
+if (rc == false)
+ return RTEMS_NOT_OWNER_OF_RESOURCE;
return RTEMS_SUCCESSFUL;
}
diff --git a/cpukit/score/src/coretodadjust.c b/cpuki
[PATCH 0/3] Intro to Patch Series
Hi This is a collection of odds and ends that have been gathering dust. 0001-rtems-confdefs.h-add-another-initial-extension-set.patch While working on the paravirtualized RTEMS on Deos, we discovered that the addition of the default extension used the BSP_INITIAL_EXTENSION configuration parameter. This eliminated the possibility of the BSP having its own which in fact, the Deos/RTEMS BSP does. The name I chose is awful. I think I would prefer to add one for the BSP default extension to use and free up the old name. This certainly would simplify documentation clean up. The documentation still refers to BSP_INITIAL_EXTENSION as available for a BSP to use. How about we add BSP_INITIAL_DEFAULT_EXTENSION or something and use it for the default-initial-extension.h one? 0002-Add-hook-for-BSP-to-act-when-time-is-set.patch In the Deos/RTEMS paravirtualized environment, an RTEMS application can set the date and time across all virtualized environments if it has been given permission to do so via the environment specific APIs. This patch adds a hook called during _TOD_Set() to allow a paravirtualized BSP to attempt to set the TOD in the hosting environment. 0003-cpukit-headers.am-Regenerate.patch While updating my tree, I noticed headers.am needed regenerating from something I didn't touch. This does it. Joel Sherrill (3): rtems/confdefs.h add another initial extension set Add hook for BSP to act when time is set cpukit/headers.am: Regenerate cpukit/headers.am| 2 ++ cpukit/include/rtems/confdefs.h | 3 +++ cpukit/include/rtems/score/tod.h | 51 cpukit/include/rtems/score/todimpl.h | 8 +- cpukit/posix/src/clocksettime.c | 6 - cpukit/rtems/src/clockset.c | 6 - cpukit/score/src/coretodadjust.c | 2 +- cpukit/score/src/coretodset.c| 15 ++- 8 files changed, 88 insertions(+), 5 deletions(-) create mode 100644 cpukit/include/rtems/score/tod.h -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/3] Add hook for BSP to act when time is set
On 4/10/19 8:08 am, Joel Sherrill wrote:
> This hook is only enabled when paravirtualized. It allows
> the application running on RTEMS in a paravirtualized
> environment to have its set time operations impact
> the hosting environment. This requires support specific
> to the paravirtualized environment. The hosting environment
> may refuse to let the paravirtualized application set the
> time and this is reflected to the application as a
> permissions or not owner of resource issue.
> ---
> cpukit/headers.am| 1 +
> cpukit/include/rtems/score/tod.h | 51
>
> cpukit/include/rtems/score/todimpl.h | 8 +-
> cpukit/posix/src/clocksettime.c | 6 -
> cpukit/rtems/src/clockset.c | 6 -
> cpukit/score/src/coretodadjust.c | 2 +-
> cpukit/score/src/coretodset.c| 15 ++-
> 7 files changed, 84 insertions(+), 5 deletions(-)
> create mode 100644 cpukit/include/rtems/score/tod.h
>
> diff --git a/cpukit/headers.am b/cpukit/headers.am
> index 008b7cc..3386f77 100644
> --- a/cpukit/headers.am
> +++ b/cpukit/headers.am
> @@ -399,6 +399,7 @@ include_rtems_score_HEADERS +=
> include/rtems/score/timespec.h
> include_rtems_score_HEADERS += include/rtems/score/timestamp.h
> include_rtems_score_HEADERS += include/rtems/score/timestampimpl.h
> include_rtems_score_HEADERS += include/rtems/score/tls.h
> +include_rtems_score_HEADERS += include/rtems/score/tod.h
> include_rtems_score_HEADERS += include/rtems/score/todimpl.h
> include_rtems_score_HEADERS += include/rtems/score/userext.h
> include_rtems_score_HEADERS += include/rtems/score/userextdata.h
> diff --git a/cpukit/include/rtems/score/tod.h
> b/cpukit/include/rtems/score/tod.h
> new file mode 100644
> index 000..3b06642
> --- /dev/null
> +++ b/cpukit/include/rtems/score/tod.h
> @@ -0,0 +1,51 @@
> +/**
> + * @file
> + *
> + * @ingroup ScoreTOD
> + *
> + * @brief Time of Day Handler API
> + */
> +
> +/*
> + * COPYRIGHT (c) 1989-2009.
> + * On-Line Applications Research Corporation (OAR).
> + *
> + * The license and distribution terms for this file may be
> + * found in the file LICENSE in this distribution or at
> + * http://www.rtems.org/license/LICENSE.
> + */
> +
> +#ifndef _RTEMS_SCORE_TOD_H
> +#define _RTEMS_SCORE_TOD_H
> +
> +#include
> +
> +#include
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#if defined(RTEMS_PARAVIRT)
> +/**
> + * @brief Method Invoked When TOD is Set
> + *
> + * This method is invoked when the TOD is set. It can be overridden
> + * by the BSP
How is it overridden?
> to allow it to set the TOD in the host in a paravirtualized
> + * environment.
> + *
> + * @param tod points to the new TOD
> + *
> + * @note This is invoked with the TOD locked.
> + */
> +bool _TOD_Set_hook(
I initially read this as setting the "hook" and not the "set hook".
> + const struct timespec *tod
> +);
> +#endif
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif
> +/* end of include file */
> diff --git a/cpukit/include/rtems/score/todimpl.h
> b/cpukit/include/rtems/score/todimpl.h
> index 0d4faac..25bb979 100644
> --- a/cpukit/include/rtems/score/todimpl.h
> +++ b/cpukit/include/rtems/score/todimpl.h
> @@ -183,8 +183,14 @@ static inline void _TOD_Acquire( ISR_lock_Context
> *lock_context )
> * @param lock_context The ISR lock context used for the corresponding
> * _TOD_Acquire(). The caller must be the owner of the TOD lock. This
> * function will release the TOD lock.
> + *
> + * @note This method currently always returns true in non-paravirtualized
> + * configuration. In a paravirtualized envivonment, it may fail if
> + * the container does not have permission to set the time.
> + *
> + * @return This method returns true if successful and false otherwise.
> */
> -void _TOD_Set(
> +bool _TOD_Set(
Why bool? Would returning an `int` let the BSP determine the error code
returned?
>const struct timespec *tod,
>ISR_lock_Context *lock_context
> );
> diff --git a/cpukit/posix/src/clocksettime.c b/cpukit/posix/src/clocksettime.c
> index a0fdd91..387de4e 100644
> --- a/cpukit/posix/src/clocksettime.c
> +++ b/cpukit/posix/src/clocksettime.c
> @@ -32,6 +32,8 @@ int clock_settime(
>const struct timespec *tp
> )
> {
> + bool rc;
> +
>if ( !tp )
> rtems_set_errno_and_return_minus_one( EINVAL );
>
> @@ -43,8 +45,10 @@ int clock_settime(
>
> _TOD_Lock();
> _TOD_Acquire( &lock_context );
> -_TOD_Set( tp, &lock_context );
> +rc = _TOD_Set( tp, &lock_context );
> _TOD_Unlock();
> +if (rc == false)
> + rtems_set_errno_and_return_minus_one( EPERM );
ie is this the only error that can ever be returned for type of call? What about
EIO, EACCES, EINVAL, etc.
>}
> #ifdef _POSIX_CPUTIME
>else if ( clock_id == CLOCK_PROCESS_CPUTIME_ID )
> diff --git a/cpukit/rtems/src/clockset.c b/cpukit/rtems/src/clockset.c
> index d772682..9acb8d7 100644
Re: [PATCH 1/3] rtems/confdefs.h add another initial extension set
On 04/10/2019 00:08, Joel Sherrill wrote: This adds back the capability for the BSP to configure an initial extension that is specific to itself. The parameter BSP_INITIAL_EXTENSION was taken over by having a standard fatal extension installed using the same name. --- cpukit/include/rtems/confdefs.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/cpukit/include/rtems/confdefs.h b/cpukit/include/rtems/confdefs.h index 5eb5425..e1a255a 100644 --- a/cpukit/include/rtems/confdefs.h +++ b/cpukit/include/rtems/confdefs.h @@ -2136,6 +2136,9 @@ extern rtems_initialization_tasks_table Initialization_tasks[]; #if defined(CONFIGURE_INITIAL_EXTENSIONS) CONFIGURE_INITIAL_EXTENSIONS, #endif +#if defined(BSP_INITIAL2_EXTENSIONS) + BSP_INITIAL2_EXTENSIONS, +#endif #if defined(BSP_INITIAL_EXTENSION) BSP_INITIAL_EXTENSION #endif I don't think this patch is necessary. A BSP is free to provide its own initial extension. Just don't add the #include to the bsp.h. -- 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: [PATCH 2/3] Add hook for BSP to act when time is set
On 04/10/2019 04:44, Chris Johns wrote:
Is this only useful for virtual BSPs and is it always a requirement to implement
this call in those environments?
Would this call be useful to a non-virtual BSP, for example one with a battery
backed RTC device?
Would a hook API along the lines of
typedef int (*_TOD_Set_Handler)(const struct timespec *tod);
_TOD_Set_Handler _TOD_Set_hook(_TOD_Set_Handler handler);
... be more flexible?
Yes, I think this should be generalized to allow RTC drivers to use this
API as well. I think it should be possible to install (and remove) more
than one hook, e.g.
typedef enum {
TOD_ACTION_SET_CLOCK
} TOD_Action;
typedef struct TOD_Hook {
Chain_Node Node;
int (*handler)(struct TOD_Handler *, TOD_Action, const struct
timespec *);
} TOD_Hook;
--
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: Waf and Ada?
On 03/10/2019 04:38, Chris Johns wrote: On 2/10/19 9:21 pm, Sebastian Huber wrote: the waf build prototype contains no examples for building Ada objects, libraries and executables. https://git.rtems.org/amar/waf-old.git/ Searching the internet revealed also nothing. It would be great to have an example for building an Ada test executable (mix of C and Ada files). The best way to handle this is to create a tool for Ada ... https://gitlab.com/ita1024/waf/tree/master/waflib/Tools https://github.com/BNLIF/waf-tools I am sure Thomas would be happy to accept such a tool. He is on IRC #rtems as ita. Thanks for the hint. So, the Ada support for RTEMS first requires Ada support for waf. I will probably work on this with a low priority. -- 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: [PATCH v2 3/3] ttest01: New test
On 02/10/2019 19:48, Gedare Bloom wrote: On Tue, Oct 1, 2019 at 10:52 PM Sebastian Huber wrote: On 01/10/2019 23:40, Gedare Bloom wrote: +/* + * SPDX-License-Identifier: BSD-2-Clause + * SPDX-License-Identifier: CC-BY-SA-4.0 + * + * Copyright (C) 2018, 2019 embedded brains GmbH + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + * POSSIBILITY OF SUCH DAMAGE. + * + * ALTERNATIVELY, this software may be distributed under the terms of the + * Creative Commons Attribution-ShareAlike 4.0 International Public License as + * published by Creative Commons, PO Box 1866, Mountain View, CA 94042 + * (https://creativecommons.org/licenses/by-sa/4.0/legalcode). + */ Is there any standing for dual-licensing 2BSD with CC-BY-SA? diff --git a/testsuites/libtests/ttest01/ttest01.doc b/testsuites/libtests/ttest01/ttest01.doc new file mode 100644 index 00..37d9ff8535 --- /dev/null +++ b/testsuites/libtests/ttest01/ttest01.doc @@ -0,0 +1,19 @@ +This file describes the directives and concepts tested by this test set. + +test set name: ttest01 + +The test-*.c files must place the license header at the bottom of the file. +This allows a copy and past of the test code into documentation sources and paste +enables a constent line numbering between the documentation code fragements and constant ... fragments +the actual test output. For the same reason the T_TEST_OUTPUT() macros must be +placed after the actual test cases. The test source files are dual licensesd licensed +BSD-2-Clause and CC-BY-SA-4.0. + Thanks for the above explanation, it was helpful for this example. For future tests, do you anticipate any text here such as a short narrative description? Or this text should be deleted if it gets copy-paste into new tests? Everything which may end up in the documentation (such as code examples) should be dual licensed BSD-2-Clause and CC-BY-SA-4.0 from my point of view. Otherwise we would have to deal with BSD-2-Clause also in the documentation set. Not every test needs this, just the one that may be used in the documentation, e.g. https://docs.rtems.org/branches/master/eng/test-framework.html#test-fixture Yes, I understand, my point was that the explanation of this dual-licensing doesn't need to exist in every dual-licensed test. It just needs to be understood (by developers/test-writers, maybe users) It is just in the ttest01.doc file. I think this should be enough. Maybe we should change the * SPDX-License-Identifier: BSD-2-Clause * SPDX-License-Identifier: CC-BY-SA-4.0 in * SPDX-License-Identifier: BSD-2-Clause OR CC-BY-SA-4.0 since this seems to be the prevailing style in the Linux kernel for dual-licensed files. I would like to add also code examples to the RTEMS Classic API Guide for the managers (not in the next weeks). Examples for using them? I can see this would be nice to dual-license. Yes, examples for using them. Another candidate for dual licensing are the interface specification items. I would like to generate the API header files with Doxygen markup and the API documentation from a single source - the interface specification items. I might have missed something. Do you mean there is plan for an interface specification using something like an interface definition language (IDL), and you would like to generate header files such as include/rtems/rtems/task.h, from IDL? Or something else? Yes, but not IDL. My proposal is to use Doorstop YAML files with specialized attributes (key-value pairs) for the API (e.g. rtems_task_create(), but not internal stuff like _Thread_Set_name()). -- 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-Mai
Re: [PATCH 2/3] Add hook for BSP to act when time is set
On 4/10/19 3:10 pm, Sebastian Huber wrote:
> On 04/10/2019 04:44, Chris Johns wrote:
>> Is this only useful for virtual BSPs and is it always a requirement to
>> implement
>> this call in those environments?
>>
>> Would this call be useful to a non-virtual BSP, for example one with a
>> battery
>> backed RTC device?
>>
>> Would a hook API along the lines of
>>
>> typedef int (*_TOD_Set_Handler)(const struct timespec *tod);
>> _TOD_Set_Handler _TOD_Set_hook(_TOD_Set_Handler handler);
>>
>> ... be more flexible?
>
> Yes, I think this should be generalized to allow RTC drivers to use this API
> as
> well. I think it should be possible to install (and remove) more than one
> hook,
> e.g.
>
> typedef enum {
> TOD_ACTION_SET_CLOCK
> } TOD_Action;
Nice.
> typedef struct TOD_Hook {
> Chain_Node Node;
> int (*handler)(struct TOD_Handler *, TOD_Action, const struct timespec *);
> } TOD_Hook;
I like the simpler interface of returning the current hook and specifying those
who obtain a hook call the returned hook pointer if it is not NULL. This way we
only need to hold a single pointer and there is no complexity around locking etc
to update a list as the hook holder has to deal with that locally.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Waf and Ada?
On 4/10/19 3:17 pm, Sebastian Huber wrote: > On 03/10/2019 04:38, Chris Johns wrote: >> On 2/10/19 9:21 pm, Sebastian Huber wrote: >>> >>> the waf build prototype contains no examples for building Ada objects, >>> libraries >>> and executables. >>> >>> https://git.rtems.org/amar/waf-old.git/ >>> >>> Searching the internet revealed also nothing. It would be great to have an >>> example for building an Ada test executable (mix of C and Ada files). >> >> The best way to handle this is to create a tool for Ada ... >> >> https://gitlab.com/ita1024/waf/tree/master/waflib/Tools >> https://github.com/BNLIF/waf-tools >> >> I am sure Thomas would be happy to accept such a tool. He is on IRC #rtems as >> ita. > > Thanks for the hint. So, the Ada support for RTEMS first requires Ada support > for waf. I will probably work on this with a low priority. > It is not an absolute requirement however adding a tool upstream makes the long term maintenance simpler for RTEMS. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: How to build start.o using waf?
On 03/10/2019 04:32, Chris Johns wrote: On 3/10/19 3:30 am, Gedare Bloom wrote: On Wed, Oct 2, 2019 at 5:12 AM Sebastian Huber wrote: On 30/09/2019 15:14, Sebastian Huber wrote: Hello, I would like to work on a new build system prototype. The idea is to use specification items maintained by Doorstop (YAML files), a Python configuration script and waf to build RTEMS and the tests. This is similar to the libbsd build. The difference is that in libbsd the build data is maintained directly in Python code (libbsd.py). A key design aspect is how the configuration of RTEMS is handled and maintained. Amar's solution provides a specific model for managing settings and specifically BSP options. We need a way to add options for a BSP that lets us collect, document and validate these settings. We need a way to query and review option defaults. The solution needs to be able to add and remove BSPs with minimal impact and this leads to being able to build a BSP that is external to the RTEMS source tree. There are BSPs that are private or export restricted. Another issue to consider is how we deprecate, update or alter options. I suspect we will have an iterating design around the internal design and implementation complexity and suitable external user work-flows. Now is a good time to create a wish list for the new build system. I cannot implement everything, but I can try to make a substantial initial step forward. Doorstop is a tool to manage a directed, acyclic graph of items. Each item has a set of attributes (key-value pairs). Some attributes are pre-defined by Doorstop with requirements management in mind. You can also add an arbitrary number of custom attributes. With this data structure you can tackle a lot of problems. The items are stored in YAML format files. My approach would be to store all the data that defines the build in build item files. The wscript file reads the build items, configures the build and performs the build as specified also by command line options, e.g. which BSP, with tests, etc. The build item files can be also used by other tools. A BSP is represented by a BSP build item which links to BSP option items, object items (start.o) and file groups for librtemsbsp.a. A BSP is just a node in the graph, you can ask for example: if I remove this BSP item, does it create isolated items? The isolated items can be removed if the BSP is removed. If you change an option, you can figure out the impact, e.g. which BSP uses this option. Since the build is driven by item files which just reside in a directory, you can also point the build script to another directory with items defined externally. The question is if waf is capable to build files outside the top directory. Building externally defined stuff has a very low priority for me. I just want to point out that there are no fundamental obstacles with this approach. The details of BSP options can be easily managed with specialized attributes, e.g. type, min, max, default value, etc. We can utilize the full power of https://docs.python.org/3.6/library/optparse.html which is a very nice Python module. We may use https://docs.python.org/3.6/library/optparse.html#optparse-option-callbacks to provide services we need for this BSP (and others): https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/atsam/configure.ac The callbacks can be stored in the items files as Python code and imported with exec(). The callbacks need an ability to install a post-processing handler which is invoked during the waf configure(), e.g. to generate the linker command file based on 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: Waf and Ada?
On 04/10/2019 08:08, Chris Johns wrote: On 4/10/19 3:17 pm, Sebastian Huber wrote: On 03/10/2019 04:38, Chris Johns wrote: On 2/10/19 9:21 pm, Sebastian Huber wrote: the waf build prototype contains no examples for building Ada objects, libraries and executables. https://git.rtems.org/amar/waf-old.git/ Searching the internet revealed also nothing. It would be great to have an example for building an Ada test executable (mix of C and Ada files). The best way to handle this is to create a tool for Ada ... https://gitlab.com/ita1024/waf/tree/master/waflib/Tools https://github.com/BNLIF/waf-tools I am sure Thomas would be happy to accept such a tool. He is on IRC #rtems as ita. Thanks for the hint. So, the Ada support for RTEMS first requires Ada support for waf. I will probably work on this with a low priority. It is not an absolute requirement however adding a tool upstream makes the long term maintenance simpler for RTEMS. Yes, this is definitely the way to go. -- 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: [PATCH 2/3] Add hook for BSP to act when time is set
On 04/10/2019 08:06, Chris Johns wrote:
On 4/10/19 3:10 pm, Sebastian Huber wrote:
On 04/10/2019 04:44, Chris Johns wrote:
Is this only useful for virtual BSPs and is it always a requirement to implement
this call in those environments?
Would this call be useful to a non-virtual BSP, for example one with a battery
backed RTC device?
Would a hook API along the lines of
typedef int (*_TOD_Set_Handler)(const struct timespec *tod);
_TOD_Set_Handler _TOD_Set_hook(_TOD_Set_Handler handler);
... be more flexible?
Yes, I think this should be generalized to allow RTC drivers to use this API as
well. I think it should be possible to install (and remove) more than one hook,
e.g.
typedef enum {
TOD_ACTION_SET_CLOCK
} TOD_Action;
Nice.
typedef struct TOD_Hook {
Chain_Node Node;
int (*handler)(struct TOD_Handler *, TOD_Action, const struct timespec *);
} TOD_Hook;
I like the simpler interface of returning the current hook and specifying those
who obtain a hook call the returned hook pointer if it is not NULL. This way we
only need to hold a single pointer and there is no complexity around locking etc
to update a list as the hook holder has to deal with that locally.
We already have _TOD_Lock() which uses a full mutex. If you let the
caller handle the potential chaining, then you may loose events.
--
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: Testing the interrupt extension API?
On 02/10/2019 19:44, Gedare Bloom wrote:
On Wed, Oct 2, 2019 at 1:28 AM Sebastian Huber
wrote:
Hello,
the interrupt extension API implementation is already quite complex and
not covered by the test suite:
https://git.rtems.org/rtems/tree/bsps/shared/irq
In order to write generic tests for this we have to know which interrupt
vector can be controlled by software. One approach would be to add an
rtems_interrupt_get_capabilities() function:
/**
* @brief A bit field indicating interrupt capabilities.
*/
I don't care for the term 'capabilities' here, maybe 'attributes' is
OK? Can we overload these fields onto rtems_attribute?
Yes, attributes is better.
typedef struct {
/**
* @brief Is set, if the interrupt can be enabled through
* rtems_interrupt_vector_enable(), otherwise cleared.
*/
unsigned int can_enable : 1;
/**
* @brief Is set, if the interrupt can be enabled through
* rtems_interrupt_vector_enable(), otherwise cleared.
disabled / disable()
*/
unsigned int can_disable : 1;
Curious: are there vectors that can be enabled but not disabled (or vice versa)?
Probably not.
/**
* @brief Is set, if the interrupt can be raised through
* rtems_interrupt_raise(), otherwise cleared.
*/
unsigned int can_raise : 1;
/**
* @brief Is set, if the interrupt can be cleared through
* rtems_interrupt_clear(), otherwise cleared.
*/
unsigned int can_clear : 1;
/**
* @brief Is set, if the interrupt supports a setting of its priority
through
* rtems_interrupt_set_priority(), otherwise cleared.
*/
unsigned int can_set_priority : 1;
/**
* @brief Is set, if the interrupt supports a setting of its processor
* affinity through rtems_interrupt_set_affinity(), otherwise cleared.
*/
unsigned int can_set_affinity : 1;
/**
* @brief Is set, if the interrupt has a pending state which can be
obtained
* through rtems_interrupt_is_pending(), otherwise cleared.
*/
unsigned int has_pending_state : 1;
This is strange wording, because it implies a currently pending state.
Maybe, "can_be_pending"?
/**
* @brief Is set, if the interrupt has an active state which can be
obtained
* through rtems_interrupt_is_active(), otherwise cleared.
*/
unsigned int has_active_state : 1;
ditto: can_be_active?
Yes, sounds good.
/**
* @brief Is set, if the interrupt is connected to a peripheral,
otherwise
* cleared.
*/
unsigned int has_peripheral : 1;
I guess this one is more a statement of fact.
What do you mean by this?
We have to know if an interrupt is connected to a peripheral function.
Since these interrupts must not be used by a generic test. The generic
test has no idea in which state a peripheral is.
/**
* @brief Is set, if the interrupt must be raised through
* rtems_interrupt_raise_on(), otherwise cleared.
*/
unsigned int needs_target : 1;
/**
* @brief Is set, if the interrupt is triggered by a raising signal edge,
* otherwise cleared.
*/
unsigned int is_raising_edge_triggered : 1;
/**
* @brief Is set, if the interrupt is triggered by a falling signal edge,
* otherwise cleared.
*/
unsigned int is_falling_edge_triggered : 1;
/**
* @brief Is set, if the interrupt is triggered by a low signal level,
* otherwise cleared.
*/
unsigned int is_low_level_triggered : 1;
/**
* @brief Is set, if the interrupt is triggered by a high signal level,
* otherwise cleared.
*/
unsigned int is_high_level_triggered : 1;
} rtems_interrupt_capabilities;
/**
* @brief Gets the capabilities of the specified interrupt.
*
* @retval RTEMS_SUCCESSFUL Successful operation.
* @retval RTEMS_INVALID_ID The specified vector number is invalid.
*/
rtems_status_code rtems_interrupt_get_capabilities(
rtems_vector_number vector,
rtems_interrupt_capabilities *capabilities
);
Interrupts with cap.can_raise set and cap.has_peripheral cleared can be
safely software controlled and used for tests.
Why not just have an "is_software_triggered"?
As a replacement for has_peripheral?
--
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: Testing the interrupt extension API?
On 03/10/2019 07:44, Chris Johns wrote: On 2/10/19 5:28 pm, Sebastian Huber wrote: the interrupt extension API implementation is already quite complex and not covered by the test suite: https://git.rtems.org/rtems/tree/bsps/shared/irq In order to write generic tests for this we have to know which interrupt vector can be controlled by software. Do I assume the testsuite's tests are for hard IP resources? The test would only use interrupts which are not connected to a peripheral. One approach would be to add an rtems_interrupt_get_capabilities() function: It would be nice to be able to add and remove entries based on soft IP that can be runtime loaded. :) Every BSP needs to implement this function on their own. -- 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
