Re: New validation test suites
On 16/12/2021 04:51, Chris Johns wrote: On 16/12/21 3:27 am, Sebastian Huber wrote: On 15/12/2021 06:46, Chris Johns wrote: On 14/12/21 6:24 pm, Sebastian Huber wrote: Hello Chris, On 13/12/2021 22:01, Chris Johns wrote: On 14/12/21 1:53 am, Sebastian Huber wrote: [...] We finished the specification of the pre-qualified RTEMS feature set. The specification is available in an RTEMS Project repository: https://git.rtems.org/rtems-central/tree/spec I had a quick look. Is there a more user friendly view of this data? I think the term "specification" is a little bit misleading because the data files are not easily read by a person. I understand this is the specification data set however it is not what I am traditionally use to seeing. You can use the "./specview.py" script to get views of the specification. For example, this command displays the transition map for the rtems_signal_send() directive: Is specview.py part of rtems.git? No, this script is in rtems-central. This is also the location of the specification items. I am not sure linking a script from that repo like this is helpful. If not part of rtems.git how much data is there for all the output? That is it is generated and held in the repo with the tests? In rtems.git, there are only the generated sources. [...] There should be no reach back to the upstream specs, scripts etc and for good reasons. The information you posted is nice and useful and I do not wish to release manage rtems-central to accommodate these tests in a release. Would capturing that information with the tests be something worth doing? I don't think it would be useful. If you want to modify the tests you should work with the specification items and the corresponding scripts. Adding the tables as comments would blow up the sources considerably. Some tests have about 5 table entries and the table entries depend on C preprocessor defines. [...] In an earlier version of the header, we had a link which you didn't like: If I need to look at the formatting rules the heading "Software Development Management" is easy to see and then a click on "Coding Standards" gives me what I am looking for. To generate these headers I click on "Software Requirements Engineering" and then do I just guess until I find it in the "How To" section? I am actually asking this be sorted out so it is not left hanging and we are not left guessing what to do. If it can be rearrange into something meaningful it would help. :) Well, if you read the text in the header: * For information on updating and regenerating please refer to the How-To * section in the Software Requirements Engineering chapter of the * RTEMS Software Engineering manual. The manual is provided as a part of * a release. For development sources please refer to the online * documentation at: * * https://docs.rtems.org You should read the How-to section or not? Yes I should have and thanks for pointing this out but I did not see this and the manual as it stands did not help. I think it should change. It can be performed post this patch set but I think the documentation would read better if changed. Could you please make a suggestions how the text should be changed? What hardware have the validation tests been run on? Any tier 1 archs? I tested with the sparc/leon3 BSPs and the arm/realview_pbx_a9_qemu. Is the leon3 tested on hardware or simulation? You need a full implementation of the new Interrupt Manager directives and a working Cache Manager implementation. Is this documented? I am sorry I do not know the list of archs and bsps that support the new interrupt manager directives. Maybe it would be good to list them? All BSPs have at least a stub implementation of the new directives. The directives are tested in a dedicated test suite. You will notice failures in this test suite if the directives are not implemented. Are these expected failures? Yes, they would be expected failures. I can add the test information. For which BSPs should I do this? I noticed an issue with the thread restart on aarch64/a53_lp64_qemu. On powerpc/psim there is an issue in one test case, due to: #define CPU_ALL_TASKS_ARE_FP CPU_HARDWARE_FP Sorry, I am not following what the issue is? Does this effect all PPC BSPS? Not all, the newer BSPs have no separate floating-point context. Which ones have the issue, the newer BSPs or the older ones? The older ones. This is something which needs to be fixed in the specification. Of? < From my point of view this is just a minor issue. As in fixing these tests? Another issue is that the tm27 interrupt must be independent of the clock driver interrupt. This is not the case for powerpc/psim. There is definitely some work left to cover all edge cases. Some tests are quite complicated. Sure. I would like to understand the effects this has? Maybe I can rearrange the test cases so that the tm27 support is only used if no
[PATCH] c-user: Clarify time formats
Update #4572.
---
c-user/clock/background.rst | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/c-user/clock/background.rst b/c-user/clock/background.rst
index 64e8311..9e76a02 100644
--- a/c-user/clock/background.rst
+++ b/c-user/clock/background.rst
@@ -1,5 +1,6 @@
.. SPDX-License-Identifier: CC-BY-SA-4.0
+.. Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
Background
@@ -29,7 +30,7 @@ and date format:
.. code-block:: c
-struct rtems_tod_control {
+typedef struct {
uint32_t year; /* greater than 1987 */
uint32_t month; /* 1 - 12 */
uint32_t day;/* 1 - 31 */
@@ -37,20 +38,28 @@ and date format:
uint32_t minute; /* 0 - 59 */
uint32_t second; /* 0 - 59 */
uint32_t ticks; /* elapsed between seconds */
-};
-typedef struct rtems_tod_control rtems_time_of_day;
+} rtems_time_of_day;
The native date and time format is the only format supported when setting the
-system date and time using the ``rtems_clock_set`` directive. Some
+system date and time using the :ref:`InterfaceRtemsClockSet` directive. Some
applications expect to operate on a *UNIX-style* date and time data structure.
-The ``rtems_clock_get_tod_timeval`` always returns the date and time in
-``struct timeval`` format.
-
-The ``struct timeval`` data structure has two fields: ``tv_sec`` and
-``tv_usec`` which are seconds and microseconds, respectively. The ``tv_sec``
-field in this data structure is the number of seconds since the POSIX epoch of
-*January 1, 1970* but will never be prior to the RTEMS epoch of *January 1,
-1988*.
+For example, the :ref:`InterfaceRtemsClockGetTodTimeval` returns the date and
+time in ``struct timeval`` format.
+
+Some directives use data structures defined by :term:`POSIX`. The ``struct
+timeval`` data structure has two members: ``tv_sec`` and ``tv_usec`` which are
+seconds and microseconds, respectively. The ``struct timespec`` data structure
+has two members: ``tv_sec`` and ``tv_nsec`` which are seconds and nanoseconds,
+respectively. For :term:`CLOCK_REALTIME` time points, the ``tv_sec`` member in
+these data structures is the number of seconds since the :term:`Unix epoch` but
+will never be prior to the :term:`RTEMS epoch`.
+
+The ``struct bintime`` and ``sbintime_t`` time formats used by some directives
+originate in FreeBSD. The ``struct bintime`` data structure which represents
+time in a binary time format has two members: ``sec`` and ``frac`` which are
+seconds and fractions of a second in units of :math:`1 / 2^{64}` seconds,
+respectively. The ``sbintime_t`` type is a signed 64-bit integer type used to
+represent time in units of :math:`1 / 2^{32}` seconds.
.. index:: timeslicing
--
2.31.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd] Import arm64 in_cksum.h correctly
OK
Thanks
Chris
On 16/12/21 3:05 am, Kinsey Moore wrote:
> When this file was brought in, it came from the wrong location or
> freebsd-org hash. This corrects the file such that freebsd-to-rtems.py
> runs cleanly.
> ---
> freebsd/sys/arm64/include/machine/in_cksum.h | 43 +++-
> 1 file changed, 6 insertions(+), 37 deletions(-)
>
> diff --git a/freebsd/sys/arm64/include/machine/in_cksum.h
> b/freebsd/sys/arm64/include/machine/in_cksum.h
> index d55b838b..522ba005 100644
> --- a/freebsd/sys/arm64/include/machine/in_cksum.h
> +++ b/freebsd/sys/arm64/include/machine/in_cksum.h
> @@ -1,6 +1,4 @@
> /*-
> - * SPDX-License-Identifier: BSD-3-Clause
> - *
> * Copyright (c) 1990 The Regents of the University of California.
> * All rights reserved.
> *
> @@ -31,7 +29,6 @@
> * from tahoe: in_cksum.c 1.2 86/01/05
> * from: @(#)in_cksum.c 1.3 (Berkeley) 1/19/91
> * from: Id: in_cksum.c,v 1.8 1995/12/03 18:35:19 bde Exp
> - * from: src/sys/alpha/include/in_cksum.h,v 1.7 2005/03/02 21:33:20 joerg
> * $FreeBSD$
> */
>
> @@ -40,44 +37,16 @@
>
> #include
>
> +#ifdef _KERNEL
> #define in_cksum(m, len)in_cksum_skip(m, len, 0)
> -
> +u_short in_addword(u_short sum, u_short b);
> +u_short in_cksum_skip(struct mbuf *m, int len, int skip);
> +u_int do_cksum(const void *, int);
> #if defined(IPVERSION) && (IPVERSION == 4)
> -/*
> - * It it useful to have an Internet checksum routine which is inlineable
> - * and optimized specifically for the task of computing IP header checksums
> - * in the normal case (where there are no options and the header length is
> - * therefore always exactly five 32-bit words.
> - */
> -#ifdef __CC_SUPPORTS___INLINE
> -
> -static __inline void
> -in_cksum_update(struct ip *ip)
> -{
> - int __tmpsum;
> - __tmpsum = (int)ntohs(ip->ip_sum) + 256;
> - ip->ip_sum = htons(__tmpsum + (__tmpsum >> 16));
> -}
> -
> -#else
> -
> -#define in_cksum_update(ip)
> \
> - do {\
> - int __tmpsum; \
> - __tmpsum = (int)ntohs(ip->ip_sum) + 256;\
> - ip->ip_sum = htons(__tmpsum + (__tmpsum >> 16));\
> - } while(0)
> -
> -#endif
> +u_int in_cksum_hdr(const struct ip *);
> #endif
>
> -#ifdef _KERNEL
> -#if defined(IPVERSION) && (IPVERSION == 4)
> -u_int in_cksum_hdr(const struct ip *ip);
> -#endif
> -u_short in_addword(u_short sum, u_short b);
> u_short in_pseudo(u_int sum, u_int b, u_int c);
> -u_short in_cksum_skip(struct mbuf *m, int len, int skip);
> -#endif
>
> +#endif /* _KERNEL */
> #endif /* _MACHINE_IN_CKSUM_H_ */
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH RSB 5] sb: Merge mailer changes from rtems-tools
OK
Thanks
Chris
On 16/12/21 8:38 am, Alex White wrote:
> This adds the improved mailer.py script from rtems-tools.
>
> Closes #4554
> ---
> source-builder/sb/mailer.py | 194
> +---
> source-builder/sb/options.py| 26 +-
> source-builder/sb/setbuilder.py | 2 +
> 3 files changed, 189 insertions(+), 33 deletions(-)
>
> diff --git a/source-builder/sb/mailer.py b/source-builder/sb/mailer.py
> index 42b4fa6..1d3cbb5 100644
> --- a/source-builder/sb/mailer.py
> +++ b/source-builder/sb/mailer.py
> @@ -1,21 +1,33 @@
> #
> # RTEMS Tools Project (http://www.rtems.org/)
> -# Copyright 2013 Chris Johns (chr...@rtems.org)
> +# Copyright 2013-2016 Chris Johns (chr...@rtems.org)
> +# Copyright (C) 2021 On-Line Applications Research Corporation (OAR)
> # All rights reserved.
> #
> # This file is part of the RTEMS Tools package in 'rtems-tools'.
> #
> -# Permission to use, copy, modify, and/or distribute this software for any
> -# purpose with or without fee is hereby granted, provided that the above
> -# copyright notice and this permission notice appear in all copies.
> +# 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 HOLDER 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.
> #
> -# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> -# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> -# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> -# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> -# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> -# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> -# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>
> #
> # Manage emailing results or reports.
> @@ -28,18 +40,72 @@ import smtplib
> import socket
>
> import error
> +import execute
> import options
> import path
>
> +_options = {
> +'--mail' : 'Send email report or results.',
> +'--use-gitconfig': 'Use mail configuration from git config.',
> +'--mail-to' : 'Email address to send the email to.',
> +'--mail-from': 'Email address the report is from.',
> +'--smtp-host': 'SMTP host to send via.',
> +'--smtp-port': 'SMTP port to send via.',
> +'--smtp-user': 'User for SMTP authentication.',
> +'--smtp-password': 'Password for SMTP authentication.'
> +}
> +
> def append_options(opts):
> -opts['--mail'] = 'Send email report or results.'
> -opts['--smtp-host'] = 'SMTP host to send via.'
> -opts['--mail-to'] = 'Email address to send the email too.'
> -opts['--mail-from'] = 'Email address the report is from.'
> +for o in _options:
> +opts[o] = _options[o]
> +
> +def add_arguments(argsp):
> +argsp.add_argument('--mail', help = _options['--mail'], action =
> 'store_true')
> +argsp.add_argument('--use-gitconfig', help =
> _options['--use-gitconfig'], action = 'store_true')
> +no_add = ['--mail', '--use-gitconfig']
> +for o in [opt for opt in list(_options) if opt not in no_add]:
> +argsp.add_argument(o, help = _options[o], type = str)
>
> class mail:
> def __init__(self, opts):
> self.opts = opts
> +self.gitconfig_lines = None
> +if opts.find_arg('--use-gitconfig') is not None:
> +# Read the output of `git config --list` instead of reading the
> +# .gitconfig file directly because Python 2 ConfigParser does not
> +# accept tabs at the beginning of lines.
> +e = execute.capture_execution()
> +exit_code, proc, output = e.open('git config --list', shell=True)
> +if exit_code == 0:
> +
Re: [PATCH rtems-tools 5 0/5] Port mailer.py fixes to rtems-tools 5 branch
OK Thanks Chris On 16/12/21 8:32 am, Alex White wrote: > Hi, > > This patch set adds the changes related to report mailing to rtems-tools 5. > > See #4553 > > Thanks, > > Alex White > > Alex White (5): > rtemstoolkit/mailer.py: Return full smtp-host arg value > rtemstoolkit: Filter mail options from log output > rtemstoolkit/mailer.py: Add SMTP login options > rtemstoolkit/mailer.py: Add --use-gitconfig option > rtems-bsp-builder: Fix mail support > > rtemstoolkit/mailer.py | 86 + > rtemstoolkit/options.py | 17 +++- > tester/rt/check.py | 17 +++- > 3 files changed, 111 insertions(+), 9 deletions(-) > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New validation test suites
On 16/12/21 3:27 am, Sebastian Huber wrote: > On 15/12/2021 06:46, Chris Johns wrote: >> On 14/12/21 6:24 pm, Sebastian Huber wrote: >>> Hello Chris, >>> >>> On 13/12/2021 22:01, Chris Johns wrote: On 14/12/21 1:53 am, Sebastian Huber wrote: > [...] > We finished the specification of the pre-qualified RTEMS feature set. The > specification is available in an RTEMS Project repository: > > https://git.rtems.org/rtems-central/tree/spec I had a quick look. Is there a more user friendly view of this data? I think the term "specification" is a little bit misleading because the data files are not easily read by a person. I understand this is the specification data set however it is not what I am traditionally use to seeing. >>> >>> You can use the "./specview.py" script to get views of the specification. >>> For >>> example, this command displays the transition map for the >>> rtems_signal_send() >>> directive: >> >> Is specview.py part of rtems.git? > > No, this script is in rtems-central. This is also the location of the > specification items. I am not sure linking a script from that repo like this is helpful. >> If not part of rtems.git how much data is there for all the output? That is >> it >> is generated and held in the repo with the tests? > > In rtems.git, there are only the generated sources. > > [...] There should be no reach back to the upstream specs, scripts etc and for good reasons. The information you posted is nice and useful and I do not wish to release manage rtems-central to accommodate these tests in a release. Would capturing that information with the tests be something worth doing? > The validation tests are generated from the specification using the > "./spec2modules.py" script and end up in the RTEMS sources of a Git > submodule. I > think the specification and the generation tool is now sufficiently > stable so > that the validation test code can be integrated in the RTEMS master > branch. > The > patch set is too big for the mailing list, so you can review it here: > > https://git.rtems.org/sebh/rtems.git/log/?h=validation The link failed. >>> >>> Yes, viewing my personal repository no longer works. I am not sure if this >>> is a >>> temporary issue. This is why I added the github link. >> >> It seems to have been temporary. It is back again. >> >>> > https://github.com/sebhub/rtems/tree/validation The header in a test says the regeneration instructions are in the engineering manual but I could not quickly find them? >>> >>> https://docs.rtems.org/branches/master/eng/req/howto.html#generate-content-after-changes >>> >>> >>> >>> In an earlier version of the header, we had a link which you didn't like: >> >> If I need to look at the formatting rules the heading "Software Development >> Management" is easy to see and then a click on "Coding Standards" gives me >> what >> I am looking for. >> >> To generate these headers I click on "Software Requirements Engineering" and >> then do I just guess until I find it in the "How To" section? I am actually >> asking this be sorted out so it is not left hanging and we are not left >> guessing >> what to do. If it can be rearrange into something meaningful it would help. >> :) > > Well, if you read the text in the header: > > * For information on updating and regenerating please refer to the How-To > * section in the Software Requirements Engineering chapter of the > * RTEMS Software Engineering manual. The manual is provided as a part of > * a release. For development sources please refer to the online > * documentation at: > * > * https://docs.rtems.org > > You should read the How-to section or not? Yes I should have and thanks for pointing this out but I did not see this and the manual as it stands did not help. I think it should change. It can be performed post this patch set but I think the documentation would read better if changed. What hardware have the validation tests been run on? Any tier 1 archs? >>> >>> I tested with the sparc/leon3 BSPs and the arm/realview_pbx_a9_qemu. >> >> Is the leon3 tested on hardware or simulation? >> >>> You need a >>> full implementation of the new Interrupt Manager directives and a working >>> Cache >>> Manager implementation. >> >> Is this documented? >> >> I am sorry I do not know the list of archs and bsps that support the new >> interrupt manager directives. Maybe it would be good to list them? > > All BSPs have at least a stub implementation of the new directives. The > directives are tested in a dedicated test suite. You will notice failures in > this test suite if the directives are not implemented. Are these expected failures? >>> I noticed an issue with the thread restart on aarch64/a53_lp64_qemu. >>> >>> On powerpc/psim there is an issue in one test case, due to: >>> >>> #define CPU_ALL_TASKS_ARE_FP
How To Turn off Werror for gdb on rtems5
Hi On operating systems with newer gcc versions, gdb 8 fails to compile with warnings that are errors. How can we disable-werror on that branch? Should it be for all architectures or just the offending ones (which might be all)? Help appreciated. Thanks --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH RSB 5] sb: Merge mailer changes from rtems-tools
This adds the improved mailer.py script from rtems-tools.
Closes #4554
---
source-builder/sb/mailer.py | 194 +---
source-builder/sb/options.py| 26 +-
source-builder/sb/setbuilder.py | 2 +
3 files changed, 189 insertions(+), 33 deletions(-)
diff --git a/source-builder/sb/mailer.py b/source-builder/sb/mailer.py
index 42b4fa6..1d3cbb5 100644
--- a/source-builder/sb/mailer.py
+++ b/source-builder/sb/mailer.py
@@ -1,21 +1,33 @@
#
# RTEMS Tools Project (http://www.rtems.org/)
-# Copyright 2013 Chris Johns (chr...@rtems.org)
+# Copyright 2013-2016 Chris Johns (chr...@rtems.org)
+# Copyright (C) 2021 On-Line Applications Research Corporation (OAR)
# All rights reserved.
#
# This file is part of the RTEMS Tools package in 'rtems-tools'.
#
-# Permission to use, copy, modify, and/or distribute this software for any
-# purpose with or without fee is hereby granted, provided that the above
-# copyright notice and this permission notice appear in all copies.
+# 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 HOLDER 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.
#
-# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
-# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
-# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
-# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
-# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
-# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
-# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
#
# Manage emailing results or reports.
@@ -28,18 +40,72 @@ import smtplib
import socket
import error
+import execute
import options
import path
+_options = {
+'--mail' : 'Send email report or results.',
+'--use-gitconfig': 'Use mail configuration from git config.',
+'--mail-to' : 'Email address to send the email to.',
+'--mail-from': 'Email address the report is from.',
+'--smtp-host': 'SMTP host to send via.',
+'--smtp-port': 'SMTP port to send via.',
+'--smtp-user': 'User for SMTP authentication.',
+'--smtp-password': 'Password for SMTP authentication.'
+}
+
def append_options(opts):
-opts['--mail'] = 'Send email report or results.'
-opts['--smtp-host'] = 'SMTP host to send via.'
-opts['--mail-to'] = 'Email address to send the email too.'
-opts['--mail-from'] = 'Email address the report is from.'
+for o in _options:
+opts[o] = _options[o]
+
+def add_arguments(argsp):
+argsp.add_argument('--mail', help = _options['--mail'], action =
'store_true')
+argsp.add_argument('--use-gitconfig', help = _options['--use-gitconfig'],
action = 'store_true')
+no_add = ['--mail', '--use-gitconfig']
+for o in [opt for opt in list(_options) if opt not in no_add]:
+argsp.add_argument(o, help = _options[o], type = str)
class mail:
def __init__(self, opts):
self.opts = opts
+self.gitconfig_lines = None
+if opts.find_arg('--use-gitconfig') is not None:
+# Read the output of `git config --list` instead of reading the
+# .gitconfig file directly because Python 2 ConfigParser does not
+# accept tabs at the beginning of lines.
+e = execute.capture_execution()
+exit_code, proc, output = e.open('git config --list', shell=True)
+if exit_code == 0:
+self.gitconfig_lines = output.split(os.linesep)
+
+def _args_are_macros(self):
+return isinstance(self.opts, options.command_line)
+
+def _get_arg(self, arg):
+if self._args_are_macros():
+value = self.opts.find_arg(arg)
+if
[PATCH rtems-tools 5 5/5] rtems-bsp-builder: Fix mail support
This fixes a problem with mailer options support that occurred because
check.py uses argparse.ArgumentParser instead of tester.rt.options.
Closes #4553
---
rtemstoolkit/mailer.py | 5 +++--
tester/rt/check.py | 17 -
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/rtemstoolkit/mailer.py b/rtemstoolkit/mailer.py
index ae51d78..09e4a26 100644
--- a/rtemstoolkit/mailer.py
+++ b/rtemstoolkit/mailer.py
@@ -61,14 +61,15 @@ def append_options(opts):
def add_arguments(argsp):
argsp.add_argument('--mail', help = _options['--mail'], action =
'store_true')
argsp.add_argument('--use-gitconfig', help = _options['--use-gitconfig'],
action = 'store_true')
-for o in list(_options)[1:]:
+no_add = ['--mail', '--use-gitconfig']
+for o in [opt for opt in list(_options) if opt not in no_add]:
argsp.add_argument(o, help = _options[o], type = str)
class mail:
def __init__(self, opts):
self.opts = opts
self.gitconfig_lines = None
-if opts.find_arg('--use-gitconfig') is not None:
+if self._get_arg('--use-gitconfig'):
# Read the output of `git config --list` instead of reading the
# .gitconfig file directly because Python 2 ConfigParser does not
# accept tabs at the beginning of lines.
diff --git a/tester/rt/check.py b/tester/rt/check.py
index 2a38d99..deac19d 100755
--- a/tester/rt/check.py
+++ b/tester/rt/check.py
@@ -105,7 +105,22 @@ def title():
return 'RTEMS Tools Project - RTEMS Kernel BSP Builder, %s' %
(version.string())
def command_line():
-return wrap(('command: ', ' '.join(sys.argv)), lineend = '\\')
+# Filter potentially sensitive mail options out.
+filtered_args = [
+arg for arg in sys.argv
+if all(
+smtp_opt not in arg
+for smtp_opt in [
+'--smtp-host',
+'--mail-to',
+'--mail-from',
+'--smtp-user',
+'--smtp-password',
+'--smtp-port'
+]
+)
+]
+return wrap(('command: ', ' '.join(filtered_args)), lineend = '\\')
def jobs_option_parse(jobs_option):
try:
--
2.27.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-tools 5 4/5] rtemstoolkit/mailer.py: Add --use-gitconfig option
This adds the option to pull mail-related configuration values from the
user's git configuration.
Updates #4553
---
rtemstoolkit/mailer.py | 46 --
1 file changed, 44 insertions(+), 2 deletions(-)
diff --git a/rtemstoolkit/mailer.py b/rtemstoolkit/mailer.py
index aa804ae..ae51d78 100644
--- a/rtemstoolkit/mailer.py
+++ b/rtemstoolkit/mailer.py
@@ -39,11 +39,13 @@ import smtplib
import socket
from rtemstoolkit import error
+from rtemstoolkit import execute
from rtemstoolkit import options
from rtemstoolkit import path
_options = {
'--mail' : 'Send email report or results.',
+'--use-gitconfig': 'Use mail configuration from git config.',
'--mail-to' : 'Email address to send the email to.',
'--mail-from': 'Email address the report is from.',
'--smtp-host': 'SMTP host to send via.',
@@ -58,12 +60,22 @@ def append_options(opts):
def add_arguments(argsp):
argsp.add_argument('--mail', help = _options['--mail'], action =
'store_true')
+argsp.add_argument('--use-gitconfig', help = _options['--use-gitconfig'],
action = 'store_true')
for o in list(_options)[1:]:
argsp.add_argument(o, help = _options[o], type = str)
class mail:
def __init__(self, opts):
self.opts = opts
+self.gitconfig_lines = None
+if opts.find_arg('--use-gitconfig') is not None:
+# Read the output of `git config --list` instead of reading the
+# .gitconfig file directly because Python 2 ConfigParser does not
+# accept tabs at the beginning of lines.
+e = execute.capture_execution()
+exit_code, proc, output = e.open('git config --list', shell=True)
+if exit_code == 0:
+self.gitconfig_lines = output.split(os.linesep)
def _args_are_macros(self):
return isinstance(self.opts, options.command_line)
@@ -83,6 +95,16 @@ class mail:
value = None
return value
+def _get_from_gitconfig(self, variable_name):
+if self.gitconfig_lines is None:
+return None
+
+for line in self.gitconfig_lines:
+if line.startswith(variable_name):
+ls = line.split('=')
+if len(ls) >= 2:
+return ls[1]
+
def from_address(self):
def _clean(l):
@@ -97,6 +119,12 @@ class mail:
addr = self._get_arg('--mail-from')
if addr is not None:
return addr
+addr = self._get_from_gitconfig('user.email')
+if addr is not None:
+name = self._get_from_gitconfig('user.name')
+if name is not None:
+addr = '%s <%s>' % (name, addr)
+return addr
mailrc = None
if 'MAILRC' in os.environ:
mailrc = os.environ['MAILRC']
@@ -125,6 +153,9 @@ class mail:
def smtp_host(self):
host = self._get_arg('--smtp-host')
+if host is not None:
+return host
+host = self._get_from_gitconfig('sendemail.smtpserver')
if host is not None:
return host
if self._args_are_macros():
@@ -135,6 +166,9 @@ class mail:
def smtp_port(self):
port = self._get_arg('--smtp-port')
+if port is not None:
+return port
+port = self._get_from_gitconfig('sendemail.smtpserverport')
if port is not None:
return port
if self._args_are_macros():
@@ -142,10 +176,18 @@ class mail:
return port
def smtp_user(self):
-return self._get_arg('--smtp-user')
+user = self._get_arg('--smtp-user')
+if user is not None:
+return user
+user = self._get_from_gitconfig('sendemail.smtpuser')
+return user
def smtp_password(self):
-return self._get_arg('--smtp-password')
+password = self._get_arg('--smtp-password')
+if password is not None:
+return password
+password = self._get_from_gitconfig('sendemail.smtppass')
+return password
def send(self, to_addr, subject, body):
from_addr = self.from_address()
--
2.27.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-tools 5 0/5] Port mailer.py fixes to rtems-tools 5 branch
Hi, This patch set adds the changes related to report mailing to rtems-tools 5. See #4553 Thanks, Alex White Alex White (5): rtemstoolkit/mailer.py: Return full smtp-host arg value rtemstoolkit: Filter mail options from log output rtemstoolkit/mailer.py: Add SMTP login options rtemstoolkit/mailer.py: Add --use-gitconfig option rtems-bsp-builder: Fix mail support rtemstoolkit/mailer.py | 86 + rtemstoolkit/options.py | 17 +++- tester/rt/check.py | 17 +++- 3 files changed, 111 insertions(+), 9 deletions(-) -- 2.27.0 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-tools 5 3/5] rtemstoolkit/mailer.py: Add SMTP login options
This adds more options so that the user can authenticate with the SMTP
server.
Updates #4553
---
rtemstoolkit/mailer.py | 41 +++--
1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/rtemstoolkit/mailer.py b/rtemstoolkit/mailer.py
index 3ea9d98..aa804ae 100644
--- a/rtemstoolkit/mailer.py
+++ b/rtemstoolkit/mailer.py
@@ -43,10 +43,13 @@ from rtemstoolkit import options
from rtemstoolkit import path
_options = {
-'--mail' : 'Send email report or results.',
-'--smtp-host': 'SMTP host to send via.',
-'--mail-to' : 'Email address to send the email too.',
-'--mail-from': 'Email address the report is from.'
+'--mail' : 'Send email report or results.',
+'--mail-to' : 'Email address to send the email to.',
+'--mail-from': 'Email address the report is from.',
+'--smtp-host': 'SMTP host to send via.',
+'--smtp-port': 'SMTP port to send via.',
+'--smtp-user': 'User for SMTP authentication.',
+'--smtp-password': 'Password for SMTP authentication.'
}
def append_options(opts):
@@ -55,7 +58,7 @@ def append_options(opts):
def add_arguments(argsp):
argsp.add_argument('--mail', help = _options['--mail'], action =
'store_true')
-for o in ['--smtp-host', '--mail-to', '--mail-from']:
+for o in list(_options)[1:]:
argsp.add_argument(o, help = _options[o], type = str)
class mail:
@@ -130,12 +133,38 @@ class mail:
return host
return 'localhost'
+def smtp_port(self):
+port = self._get_arg('--smtp-port')
+if port is not None:
+return port
+if self._args_are_macros():
+port = self.opts.defaults.get_value('%{_mail_smtp_port}')
+return port
+
+def smtp_user(self):
+return self._get_arg('--smtp-user')
+
+def smtp_password(self):
+return self._get_arg('--smtp-password')
+
def send(self, to_addr, subject, body):
from_addr = self.from_address()
msg = "From: %s\r\nTo: %s\r\nSubject: %s\r\n\r\n" % \
(from_addr, to_addr, subject) + body
+port = self.smtp_port()
+
try:
-s = smtplib.SMTP(self.smtp_host())
+s = smtplib.SMTP(self.smtp_host(), port, timeout=10)
+
+password = self.smtp_password()
+# If a password is provided, assume that authentication is
required.
+if password is not None:
+user = self.smtp_user()
+if user is None:
+user = from_addr
+s.starttls()
+s.login(user, password)
+
s.sendmail(from_addr, [to_addr], msg)
except smtplib.SMTPException as se:
raise error.general('sending mail: %s' % (str(se)))
--
2.27.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-tools 5 2/5] rtemstoolkit: Filter mail options from log output
This filters mail-related options out before logging the command line options. This is needed to prevent leaking potentially sensitive information via logs and emails. Updates #4553 --- rtemstoolkit/options.py | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/rtemstoolkit/options.py b/rtemstoolkit/options.py index 32a7016..5ebe3bc 100644 --- a/rtemstoolkit/options.py +++ b/rtemstoolkit/options.py @@ -508,7 +508,22 @@ class command_line(object): return None def log_info(self): -log.output(log.info(self.argv)) +# Filter potentially sensitive mail options out. +filtered_args = [ +arg for arg in self.argv +if all( +smtp_opt not in arg +for smtp_opt in [ +'--smtp-host', +'--mail-to', +'--mail-from', +'--smtp-user', +'--smtp-password', +'--smtp-port' +] +) +] +log.output(log.info(filtered_args)) def load(opts): """ -- 2.27.0 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-tools 5 1/5] rtemstoolkit/mailer.py: Return full smtp-host arg value
This fixes mail.smtp_host() so that it returns the full argument value
rather than just the second character.
Updates #4553
---
rtemstoolkit/mailer.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rtemstoolkit/mailer.py b/rtemstoolkit/mailer.py
index f8f813c..3ea9d98 100644
--- a/rtemstoolkit/mailer.py
+++ b/rtemstoolkit/mailer.py
@@ -123,7 +123,7 @@ class mail:
def smtp_host(self):
host = self._get_arg('--smtp-host')
if host is not None:
-return host[1]
+return host
if self._args_are_macros():
host = self.opts.defaults.get_value('%{_mail_smtp_host}')
if host is not None:
--
2.27.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: New validation test suites
On 15/12/2021 17:01, Joel Sherrill wrote: I waited to reply because Chris got most of my questions in his first response. :) On Tue, Dec 14, 2021 at 11:46 PM Chris Johns wrote: On 14/12/21 6:24 pm, Sebastian Huber wrote: Hello Chris, On 13/12/2021 22:01, Chris Johns wrote: On 14/12/21 1:53 am, Sebastian Huber wrote: Hello, the ESA activity to pre-qualify parts of RTEMS according to ECSS requirements is nearly complete. There is a short presentation available here: https://indico.esa.int/event/374/timetable/ Was the change in memory usage for 4.8 of 23812 bytes to 68896 explained? The foot print increase has mainly five reasons: * General GCC code generation * Chip errata workarounds done by GCC * More features used from RTEMS (for example uniprocessor synchronization done via task priorities vs. mutex synchronization) * SMP support of RTEMS * New RTEMS features such as transitive priority inheritance Thanks. If the 4.8 size was based on the Edisoft version, it was also stripped of functionality even within methods in RTEMS itself. Combine that with uniprocessor vs SMP and more robust algorithms in the current RTEMS and it creeps up. It would be interesting to see a straight uniprocessor comparison but even that would not have feature parity. I didn't have time to do a thorough comparison. The above numbers are obtain from totally different applications. Anyway, reducing the code size would be a difficult task. [...] The header in a test says the regeneration instructions are in the engineering manual but I could not quickly find them? https://docs.rtems.org/branches/master/eng/req/howto.html#generate-content-after-changes In an earlier version of the header, we had a link which you didn't like: If I need to look at the formatting rules the heading "Software Development Management" is easy to see and then a click on "Coding Standards" gives me what I am looking for. To generate these headers I click on "Software Requirements Engineering" and then do I just guess until I find it in the "How To" section? I am actually asking this be sorted out so it is not left hanging and we are not left guessing what to do. If it can be rearrange into something meaningful it would help. :) Have you had anyone not directly involved in the generation process try this from the instructions? That always seems to be when the holes show up. Frank was able to specify (and test) the Timer Manager, Clock Manager, Rate-Monotonic Manager, and Message Manager. You need a bit of time to get accustomed to the work flow. However, the table based specification worked really well for the project. commit a6689fb147649a29ff5533cec8a53635e2c95ec6 Author: Sebastian Huber Date: Fri Jan 22 16:01:46 2021 +0100 Improve file header comment in generated files diff --git a/cpukit/include/rtems/rtems/types.h b/cpukit/include/rtems/rtems/types.h index 32b45113c8..a058eedea1 100644 --- a/cpukit/include/rtems/rtems/types.h +++ b/cpukit/include/rtems/rtems/types.h @@ -38,11 +38,15 @@ * worded better please post a report or patch to an RTEMS mailing list * or raise a bug report: * - * https://docs.rtems.org/branches/master/user/support/bugs.html + * https://www.rtems.org/bugs.html * - * For information on updating and regenerating please refer to: + * For information on updating and regenerating please refer to the How-To + * section in the Software Requirements Engineering chapter of the + * RTEMS Software Engineering manual. The manual is provided as a part of + * a release. For development sources please refer to the online + * documentation at: * - * https://docs.rtems.org/branches/master/eng/req/howto.html + * https://docs.rtems.org */ /* Generated from spec:/rtems/type/if/header */ I am fine with the header, as we know links to the documentation is really hard long term. Early on, we discussed some annotation maybe like SPDX to note that a file had higher rigor with requirements and tests. Is this Generated note implying this? Is it sufficient to note that if you touch this, we would really like you to address the full chain on this? Yes, this would be great. If you modify API header files through specification items, then you get for example an up to date RTEMS Classic API Guide automatically. The patch set is organized so that general support code for the validation tests is added first and then there are commits for each pre-qualified Classic API Manager or subsystem. I did build all BSPs with the patch set. The validation tests use only statically allocated resources. Are the validation tests compatible with rtems-test? Yes. Great. How many test executables does this add to the testsuite? If RTEMS_SMP is disabled, then there are 19 new executables in the patch set. If RTEMS_SMP is enable, then there are 28 new executables. Nice. What hardware have the validation tests been run on? Any tier 1 archs? I tested with the sparc/leon3
Re: New validation test suites
On 15/12/2021 06:46, Chris Johns wrote: On 14/12/21 6:24 pm, Sebastian Huber wrote: Hello Chris, On 13/12/2021 22:01, Chris Johns wrote: On 14/12/21 1:53 am, Sebastian Huber wrote: [...] We finished the specification of the pre-qualified RTEMS feature set. The specification is available in an RTEMS Project repository: https://git.rtems.org/rtems-central/tree/spec I had a quick look. Is there a more user friendly view of this data? I think the term "specification" is a little bit misleading because the data files are not easily read by a person. I understand this is the specification data set however it is not what I am traditionally use to seeing. You can use the "./specview.py" script to get views of the specification. For example, this command displays the transition map for the rtems_signal_send() directive: Is specview.py part of rtems.git? No, this script is in rtems-central. This is also the location of the specification items. If not part of rtems.git how much data is there for all the output? That is it is generated and held in the repo with the tests? In rtems.git, there are only the generated sources. [...] The validation tests are generated from the specification using the "./spec2modules.py" script and end up in the RTEMS sources of a Git submodule. I think the specification and the generation tool is now sufficiently stable so that the validation test code can be integrated in the RTEMS master branch. The patch set is too big for the mailing list, so you can review it here: https://git.rtems.org/sebh/rtems.git/log/?h=validation The link failed. Yes, viewing my personal repository no longer works. I am not sure if this is a temporary issue. This is why I added the github link. It seems to have been temporary. It is back again. https://github.com/sebhub/rtems/tree/validation The header in a test says the regeneration instructions are in the engineering manual but I could not quickly find them? https://docs.rtems.org/branches/master/eng/req/howto.html#generate-content-after-changes In an earlier version of the header, we had a link which you didn't like: If I need to look at the formatting rules the heading "Software Development Management" is easy to see and then a click on "Coding Standards" gives me what I am looking for. To generate these headers I click on "Software Requirements Engineering" and then do I just guess until I find it in the "How To" section? I am actually asking this be sorted out so it is not left hanging and we are not left guessing what to do. If it can be rearrange into something meaningful it would help. :) Well, if you read the text in the header: * For information on updating and regenerating please refer to the How-To * section in the Software Requirements Engineering chapter of the * RTEMS Software Engineering manual. The manual is provided as a part of * a release. For development sources please refer to the online * documentation at: * * https://docs.rtems.org You should read the How-to section or not? [...] What hardware have the validation tests been run on? Any tier 1 archs? I tested with the sparc/leon3 BSPs and the arm/realview_pbx_a9_qemu. Is the leon3 tested on hardware or simulation? You need a full implementation of the new Interrupt Manager directives and a working Cache Manager implementation. Is this documented? I am sorry I do not know the list of archs and bsps that support the new interrupt manager directives. Maybe it would be good to list them? All BSPs have at least a stub implementation of the new directives. The directives are tested in a dedicated test suite. You will notice failures in this test suite if the directives are not implemented. I noticed an issue with the thread restart on aarch64/a53_lp64_qemu. On powerpc/psim there is an issue in one test case, due to: #define CPU_ALL_TASKS_ARE_FP CPU_HARDWARE_FP Sorry, I am not following what the issue is? Does this effect all PPC BSPS? Not all, the newer BSPs have no separate floating-point context. This is something which needs to be fixed in the specification. From my point of view this is just a minor issue. Another issue is that the tm27 interrupt must be independent of the clock driver interrupt. This is not the case for powerpc/psim. There is definitely some work left to cover all edge cases. Some tests are quite complicated. Sure. I would like to understand the effects this has? Maybe I can rearrange the test cases so that the tm27 support is only used if no clock driver is needed. The tm27 support is used to run handlers in interrupt context. Is there anything that interprets the new test output format? It looks like lots of great info but a little difficult to read. EDISOFT worked on a test report generator, however, it is not yet in a reviewable state. OK. I think something that handles this data would be good to have. Yes, maybe we could let a student work on this.
[PATCH rtems-libbsd] Import arm64 in_cksum.h correctly
When this file was brought in, it came from the wrong location or
freebsd-org hash. This corrects the file such that freebsd-to-rtems.py
runs cleanly.
---
freebsd/sys/arm64/include/machine/in_cksum.h | 43 +++-
1 file changed, 6 insertions(+), 37 deletions(-)
diff --git a/freebsd/sys/arm64/include/machine/in_cksum.h
b/freebsd/sys/arm64/include/machine/in_cksum.h
index d55b838b..522ba005 100644
--- a/freebsd/sys/arm64/include/machine/in_cksum.h
+++ b/freebsd/sys/arm64/include/machine/in_cksum.h
@@ -1,6 +1,4 @@
/*-
- * SPDX-License-Identifier: BSD-3-Clause
- *
* Copyright (c) 1990 The Regents of the University of California.
* All rights reserved.
*
@@ -31,7 +29,6 @@
* from tahoe: in_cksum.c 1.2 86/01/05
* from: @(#)in_cksum.c 1.3 (Berkeley) 1/19/91
* from: Id: in_cksum.c,v 1.8 1995/12/03 18:35:19 bde Exp
- * from: src/sys/alpha/include/in_cksum.h,v 1.7 2005/03/02 21:33:20 joerg
* $FreeBSD$
*/
@@ -40,44 +37,16 @@
#include
+#ifdef _KERNEL
#definein_cksum(m, len)in_cksum_skip(m, len, 0)
-
+u_short in_addword(u_short sum, u_short b);
+u_short in_cksum_skip(struct mbuf *m, int len, int skip);
+u_int do_cksum(const void *, int);
#if defined(IPVERSION) && (IPVERSION == 4)
-/*
- * It it useful to have an Internet checksum routine which is inlineable
- * and optimized specifically for the task of computing IP header checksums
- * in the normal case (where there are no options and the header length is
- * therefore always exactly five 32-bit words.
- */
-#ifdef __CC_SUPPORTS___INLINE
-
-static __inline void
-in_cksum_update(struct ip *ip)
-{
- int __tmpsum;
- __tmpsum = (int)ntohs(ip->ip_sum) + 256;
- ip->ip_sum = htons(__tmpsum + (__tmpsum >> 16));
-}
-
-#else
-
-#definein_cksum_update(ip)
\
- do {\
- int __tmpsum; \
- __tmpsum = (int)ntohs(ip->ip_sum) + 256;\
- ip->ip_sum = htons(__tmpsum + (__tmpsum >> 16));\
- } while(0)
-
-#endif
+u_int in_cksum_hdr(const struct ip *);
#endif
-#ifdef _KERNEL
-#if defined(IPVERSION) && (IPVERSION == 4)
-u_int in_cksum_hdr(const struct ip *ip);
-#endif
-u_short in_addword(u_short sum, u_short b);
u_short in_pseudo(u_int sum, u_int b, u_int c);
-u_short in_cksum_skip(struct mbuf *m, int len, int skip);
-#endif
+#endif /* _KERNEL */
#endif /* _MACHINE_IN_CKSUM_H_ */
--
2.30.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: New validation test suites
I waited to reply because Chris got most of my questions in his first response. :) On Tue, Dec 14, 2021 at 11:46 PM Chris Johns wrote: > > On 14/12/21 6:24 pm, Sebastian Huber wrote: > > Hello Chris, > > > > On 13/12/2021 22:01, Chris Johns wrote: > >> On 14/12/21 1:53 am, Sebastian Huber wrote: > >>> Hello, > >>> > >>> the ESA activity to pre-qualify parts of RTEMS according to ECSS > >>> requirements is > >>> nearly complete. There is a short presentation available here: > >>> > >>> https://indico.esa.int/event/374/timetable/ > >> > >> Was the change in memory usage for 4.8 of 23812 bytes to 68896 explained? > > > > The foot print increase has mainly five reasons: > > > > * General GCC code generation > > > > * Chip errata workarounds done by GCC > > > > * More features used from RTEMS (for example uniprocessor synchronization > > done > > via task priorities vs. mutex synchronization) > > > > * SMP support of RTEMS > > > > * New RTEMS features such as transitive priority inheritance > > > > Thanks. If the 4.8 size was based on the Edisoft version, it was also stripped of functionality even within methods in RTEMS itself. Combine that with uniprocessor vs SMP and more robust algorithms in the current RTEMS and it creeps up. It would be interesting to see a straight uniprocessor comparison but even that would not have feature parity. > > >>> We finished the specification of the pre-qualified RTEMS feature set. The > >>> specification is available in an RTEMS Project repository: > >>> > >>> https://git.rtems.org/rtems-central/tree/spec > >> > >> I had a quick look. Is there a more user friendly view of this data? > >> > >> I think the term "specification" is a little bit misleading because the > >> data > >> files are not easily read by a person. I understand this is the > >> specification > >> data set however it is not what I am traditionally use to seeing. > > > > You can use the "./specview.py" script to get views of the specification. > > For > > example, this command displays the transition map for the > > rtems_signal_send() > > directive: > > Is specview.py part of rtems.git? > > If not part of rtems.git how much data is there for all the output? That is it > is generated and held in the repo with the tests? > > > > > ./specview.py --filter=action-table /rtems/signal/req/send > > .. table:: > > :class: longtable > > > > = == = === === == == > > = > > = > > Entry Descriptor Task Set Handler ASR Nested Status Handler > > Recursive > > = == = === === == == > > = > > = > > 0 0 NoObj ZeroInvalid Enabled YesInvNum NoCall > > No > > 1 0 NoObj ZeroInvalid Enabled No InvNum NoCall > > No > > 2 0 NoObj ZeroInvalid Disabled YesInvNum NoCall > > No > > 3 0 NoObj ZeroInvalid Disabled No InvNum NoCall > > No > > 4 0 NoObj ZeroValid Enabled YesInvNum NoCall > > No > > 5 0 NoObj ZeroValid Enabled No InvNum NoCall > > No > > 6 0 NoObj ZeroValid Disabled YesInvNum NoCall > > No > > 7 0 NoObj ZeroValid Disabled No InvNum NoCall > > No > > 8 1 NoObj NonZero Invalid Enabled YesInvId NoCall > >No > > 9 1 NoObj NonZero Invalid Enabled No InvId NoCall > >No > > 101 NoObj NonZero Invalid Disabled YesInvId NoCall > >No > > 111 NoObj NonZero Invalid Disabled No InvId NoCall > >No > > 121 NoObj NonZero Valid Enabled YesInvId NoCall > >No > > 131 NoObj NonZero Valid Enabled No InvId NoCall > >No > > 141 NoObj NonZero Valid Disabled YesInvId NoCall > >No > > 151 NoObj NonZero Valid Disabled No InvId NoCall > >No > > 160 Self ZeroInvalid Enabled YesInvNum NoCall > > No > > 170 Self ZeroInvalid Enabled No InvNum NoCall > > No > > 180 Self ZeroInvalid Disabled YesInvNum NoCall > > No > > 190 Self ZeroInvalid Disabled No InvNum NoCall > > No > > 200 Self ZeroValid Enabled YesInvNum NoCall > > No > > 210 Self ZeroValid Enabled No InvNum NoCall > > No > > 220 Self ZeroValid Disabled YesInvNum NoCall > > No > > 230 Self ZeroValid Disabled No InvNum NoCall > > No > > 242 Self NonZero Invalid Enabled YesNotDef NoCall > > No > > 252
Re: arm64 support for libbsd
On 12/15/2021 01:32, Sebastian Huber wrote: Hello Kinsey, I didn't work with libbsd for a while and noticed now that there are changes after calling: ./freebsd-to-rtems.py -R ./freebsd-to-rtems.py git status modified: freebsd/sys/arm64/include/machine/in_cksum.h I don't know how you imported the in_cksum.h, but there should be no modified files after running the script. I could swear I imported that correctly and even verified that the import was clean, but either that wasn't the case or I had a non-clean/correct freebsd-org tree. I've verified that everything still compiles correctly with the changes and will submit patches for the affected branches. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
