[rtems-tools PATCH 2/2] test, rtemstoolkit: Fix regx escape errors on python 3.12
From: Chris Johns
---
tester/rt/pygdb/spark.py | 2 +-
tester/rt/test.py| 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tester/rt/pygdb/spark.py b/tester/rt/pygdb/spark.py
index 0eac365..b669998 100644
--- a/tester/rt/pygdb/spark.py
+++ b/tester/rt/pygdb/spark.py
@@ -119,7 +119,7 @@ class GenericParser:
self.augment(start)
self.ruleschanged = 1
- _NULLABLE = '\e_'
+ _NULLABLE = r'\e_'
_START = 'START'
_BOF = '|-'
diff --git a/tester/rt/test.py b/tester/rt/test.py
index db5939b..9108206 100644
--- a/tester/rt/test.py
+++ b/tester/rt/test.py
@@ -71,7 +71,7 @@ class log_capture(object):
def get(self):
s = []
status = []
-status_regx = re.compile('^\[\s*\d+/\s*\d+\] p:.+')
+status_regx = re.compile(r'^\[\s*\d+/\s*\d+\] p:.+')
for l in self.log:
if status_regx.match(l):
status += [l]
@@ -175,7 +175,7 @@ def find_executables(paths, glob):
for f in files:
if fnmatch.fnmatch(f.lower(), glob):
executables += [path.join(root, f)]
-norun = re.compile('.*\.norun.*')
+norun = re.compile(r'.*\.norun.*')
executables = [e for e in executables if not norun.match(e)]
return sorted(executables)
--
2.39.3 (Apple Git-146)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[rtems-tools PATCH 1/2] rtemstoolkit: Fix decoding unicode strings in output
From: Chris Johns
---
rtemstoolkit/execute.py | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/rtemstoolkit/execute.py b/rtemstoolkit/execute.py
index 31d3a8a..c7d8134 100755
--- a/rtemstoolkit/execute.py
+++ b/rtemstoolkit/execute.py
@@ -37,6 +37,7 @@
from __future__ import print_function
import functools
+import codecs
import io
import os
import re
@@ -203,6 +204,10 @@ class execute(object):
stacktraces.trace()
if trace_threads:
print('execute:_readthread: start')
+if sys.stdout.encoding is not None:
+decoder = codecs.getincrementaldecoder(sys.stdout.encoding)()
+else:
+decoder = None
count = 0
line = ''
try:
@@ -222,8 +227,8 @@ class execute(object):
_output_line(line + '\n', exe, prefix, out, count)
break
# str and bytes are the same type in Python2
-if type(data) is not str and type(data) is bytes:
-data = data.decode(sys.stdout.encoding)
+if decoder is not None and type(data) is not str and
type(data) is bytes:
+data = decoder.decode(data)
last_ch = data[-1]
sd = (line + data).split('\n')
if last_ch != '\n':
@@ -382,6 +387,9 @@ class execute(object):
if self.verbose:
log.output(what + ': ' + cs)
log.trace('exe: %s' % (cs))
+if shell and self.shell_exe:
+command = arg_list(command)
+command[:0] = self.shell_exe
if not stdin and self.input:
stdin = subprocess.PIPE
if not stdout:
--
2.39.3 (Apple Git-146)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: RSB format changes to meet coding standard
On Thu, Apr 18, 2024, 7:31 PM Chris Johns wrote: > Hi, > > I would like to run the python code we own through yapf and it's default to > standardise the formatting and to being it inline with the coding > standards. It > would be good to do this before we branch for RTEMS 6. > > I can crate a patch and post if required but it will be noise and doubt > anyone > will review it, I would not. I will run builds etc to make sure the > conversion > is clean. > > Do I have permission to make the format change as a single commit and push > it? > I'm certainly ok with this. > > Thanks > Chris > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RSB format changes to meet coding standard
Hi, I would like to run the python code we own through yapf and it's default to standardise the formatting and to being it inline with the coding standards. It would be good to do this before we branch for RTEMS 6. I can crate a patch and post if required but it will be noise and doubt anyone will review it, I would not. I will run builds etc to make sure the conversion is clean. Do I have permission to make the format change as a single commit and push it? Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RFC] rtems: Add options to kernel output char handler
On 18/4/2024 4:16 pm, Sebastian Huber wrote: > On 18.04.24 04:02, Chris Johns wrote: >> On 17/4/2024 11:06 pm, Sebastian Huber wrote: >>> Make the kernel I/O output character device processing configurable >>> through an option set parameter. Add RTEMS_NO_OUTPUT and RTEMS_FLUSH >>> options. The goal of this API change is to enable flushing the kernel >>> output device in the system termination process before a reset is >>> issued. A use case for using RTEMS_NO_WAIT is the polled processing of >>> an input and output stream from and to the I/O device. >> >> Thanks for providing this overview. >> >> I am still confused about the differences in terms of why you would need the >> RTEMS_NO_WAIT. Do you have a specific application where this is required? It >> might help me understand the need for the change? Examples are need to reset >> in >> a specific period, a test mode you are running in a system, etc? > > The RTEMS_NO_WAIT can be used to process an input stream using getchark() and > then send responses using a non-blocking output char variant. This helps to > have > enough processing time and allows an overlapping send/receive. > >> >> Is this change for RTEMS 7? > > Yes, this would be good. Great, I think it is too late for 6. >> In the context of the change: >> >> 1. RTEMS_FLUSH etc are too generic. > > I added them to , so they could be reused in other > directives. A bit less generic names could be: > > * RTEMS_IO_FLUSH > > * RTEMS_IO_DRAIN > > * RTEMS_IO_NO_OUTPUT > Sure, that is better. > This would be in the IO namespace similar to RTEMS_EVENT_ANY and > RTEMS_EVENT_ALL. Yeap >> 2. The language used needs some work, maybe fewer "while"s. For example: >> >> While the #RTEMS_NO_WAIT option is set in the option_set parameter, while >> the #RTEMS_NO_OUTPUT option is cleared in the option_set parameter, while >> the device can immediately accept a character for output, the character in >> out shall be hand over to the device for output. >> >> This is difficult to read and when it is probability easier to read the code >> it >> is of questionable value. I appreciate it is not always easy to write but I >> feel >> clarity would be a good to have here. > > This is the documentation of a function pointer type, so there is no direct > code. With three flags, you have to specify for eight variants what should > happen. The wording is in EARS. It should be easy to translate this into code > for a particular device. > > https://docs.rtems.org/branches/master/eng/req/req-for-req.html#syntax I think EARS is too specialised for RTEMS and here in this small isolated case. If it was taught in first year undergrad courses and widely adopted it would be a different. It is not used in RTEMS and starting here and now only makes this piece of code harder to maintain. >> Another example: >> >> While no character is available in the device, a polled >> character input functions shall return minus one. >> >> It could be written as: >> >> A polled character input function shall return a character if the device >> has successfully received one else the function returns minus one. > > I would prefer the EARS variant. This function type should define requirements > for the associated implementations. I do not agree and until EARS is agreed to at the project level this will not change. >> I think receive and transmit is better than for example "be hand over to the >> device for output", maybe "shall be transmitted by the device". > > The name of this function type is BSP_output_char_function_type and not > BSP_transmit_char_function_type, so I used "output" here and not "transmit". The function outputs data, the device transmits. If the requirement is to output the data it does not cover the transmission and the transmission is the important part. > Also, the character may not get immediately transmitted if FIFOs are involved > (thus the need for the flush). Maybe my understanding of transmitted is wrong, > but for me transmitting has something to do with signals on a medium. I have never heard of a device that has data loaded into a FIFO to transmit has a mode that transmits sooner or faster? I would have assumed outputting the data to the FIFO would sent it. There is a distinct difference between output and transmit and I would like to see the transmit aspect be specified and met. >> 3. Flush needs to be worded in terms of successfully transmitted by the >> device >> to avoid the case of data being written to the device is held in FIFOs >> awaiting >> transmission and reset is asserted. Maybe FLUSH is the wrong term because it >> is >> so overloaded in what it means? An alternative could be >> RTEMS_BSP_IO_TRANSMISSION_COMPLETE? And following on you could have >> RTEMS_BSP_IO_NO_TRANSMISSION? The key point is "transmission" relates to the >> external data pin of the interface. > > The no-output option is used to just flush the device without transmitting a > new >
Re: rtems-kernel-init.c tries to re-make existing "/etc"
> On Apr 18, 2024, at 10:55 AM, Joel Sherrill wrote: > > > > On Thu, Apr 18, 2024 at 9:50 AM Peter Dufault wrote: > > > > On Apr 18, 2024, at 10:34 AM, Kinsey Moore wrote: > > > > A patch for EEXIST here should be fine. It would be nice if the caller were > > more resilient. > > > > I also changed "default-network-init.h" to assert rtems_bsd_initialize() > worked. > > sc = rtems_bsd_initialize(); > assert(sc == RTEMS_SUCCESSFUL); > > At least you get a panic message. I'll submit a patch. > > Why does /etc already exist? Is it really an error if it already exists? > > If the startup code untar'ed some initial file system contents before calling > this, then /etc would almost certainly exist. > > Unless I am missing something EEXIST should be acceptable. Other errors are > most likely really fatal. > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/mkdir.html > > --joel > > Peter > - > Peter Dufault > HD Associates, Inc. Software and System Engineering > Oh, and maybe you misunderstood: The "assert()" is in *addition* to allowing EEXIST for the "mkdir()" call. It avoids a weird crash in case "rtems_bsd_initialize()" fails for some other reason. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-kernel-init.c tries to re-make existing "/etc"
> On Apr 18, 2024, at 10:55 AM, Joel Sherrill wrote: > > > > On Thu, Apr 18, 2024 at 9:50 AM Peter Dufault wrote: > > > > On Apr 18, 2024, at 10:34 AM, Kinsey Moore wrote: > > > > A patch for EEXIST here should be fine. It would be nice if the caller were > > more resilient. > > > > I also changed "default-network-init.h" to assert rtems_bsd_initialize() > worked. > > sc = rtems_bsd_initialize(); > assert(sc == RTEMS_SUCCESSFUL); > > At least you get a panic message. I'll submit a patch. > > Why does /etc already exist? Is it really an error if it already exists? > > If the startup code untar'ed some initial file system contents before calling > this, then /etc would almost certainly exist. > > Unless I am missing something EEXIST should be acceptable. Other errors are > most likely really fatal. > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/mkdir.html > > --joel > The function "_libcsupport_pwdgrp_init()" over in RTEMS also creates "/etc" through a "pthread_once()". A call to "getpwnam()", "getpwuid()", "getgrnam()" and family will create it. Apparently that is called first. Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: 6.1rc3 CentOS 7 Build Sweep Report
On Thu, Apr 18, 2024 at 2:00 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hallo Joel, > > it would be nice to have the interrupt get/set priority directives in > RTEMS 6. When do you want to create the RTEMS 6 branch? > Last spring. Seriously, Chris has been cutting 6.1 rc snapshots to help shake out lurking issues. We use tarballs on rtems.org for the RSB and this had to be worked through. rc1 including tools not building at all. rc2 had some issues and I don't recall even getting to building the BSPs. rc3 is looking better. If you have something you want to make 6, I think there is still time. But hopefully very little. We have been working to reduce tickets identifying 6.1 as a milestone for months. --joel > > -- > embedded brains GmbH & Co. KG > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@embedded-brains.de > phone: +49-89-18 94 741 - 16 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-kernel-init.c tries to re-make existing "/etc"
On Thu, Apr 18, 2024 at 9:50 AM Peter Dufault wrote: > > > > On Apr 18, 2024, at 10:34 AM, Kinsey Moore > wrote: > > > > A patch for EEXIST here should be fine. It would be nice if the caller > were more resilient. > > > > I also changed "default-network-init.h" to assert rtems_bsd_initialize() > worked. > > sc = rtems_bsd_initialize(); > assert(sc == RTEMS_SUCCESSFUL); > > At least you get a panic message. I'll submit a patch. > Why does /etc already exist? Is it really an error if it already exists? If the startup code untar'ed some initial file system contents before calling this, then /etc would almost certainly exist. Unless I am missing something EEXIST should be acceptable. Other errors are most likely really fatal. https://pubs.opengroup.org/onlinepubs/9699919799/functions/mkdir.html --joel > > Peter > - > Peter Dufault > HD Associates, Inc. Software and System Engineering > > > > ___ > 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: rtems-kernel-init.c tries to re-make existing "/etc"
> On Apr 18, 2024, at 10:34 AM, Kinsey Moore wrote: > > A patch for EEXIST here should be fine. It would be nice if the caller were > more resilient. > I also changed "default-network-init.h" to assert rtems_bsd_initialize() worked. sc = rtems_bsd_initialize(); assert(sc == RTEMS_SUCCESSFUL); At least you get a panic message. I'll submit a patch. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-kernel-init.c tries to re-make existing "/etc"
On Thu, Apr 18, 2024 at 9:18 AM Peter Dufault wrote:
> I just rebased to "6-freebsd-12". This change:
>
> ###
> commit 62e0ca8283603573d42a0f15da044cd406a2f00a
> Author: Kinsey Moore
> Date: Tue Jan 23 13:25:45 2024 -0600
>
> rtemsbsd/rtems: Check function return values
> ###
> [dufault@gen6 rtems-libbsd]$ git diff
> 6514d561587fd1527fe6a26cb43e6b5742c8c779 rtemsbsd/rtems/rtems-kernel-init.c
> diff --git a/rtemsbsd/rtems/rtems-kernel-init.c
> b/rtemsbsd/rtems/rtems-kernel-init.c
> index 90a9c80..8ac2f59 100644
> --- a/rtemsbsd/rtems/rtems-kernel-init.c
> +++ b/rtemsbsd/rtems/rtems-kernel-init.c
> @@ -223,7 +223,9 @@ rtems_bsd_initialize(void)
> return RTEMS_UNSATISFIED;
> }
>
> - mkdir("/etc", S_IRWXU | S_IRWXG | S_IRWXO);
> + if (mkdir("/etc", S_IRWXU | S_IRWXG | S_IRWXO) != 0) {
> + return RTEMS_UNSATISFIED;
> + }
>
> sc = rtems_timer_initiate_server(rtems_bsd_get_task_priority(name),
> rtems_bsd_get_task_stack_size(name), RTEMS_DEFAULT_ATTRIBUTES);
> ###
>
> causes a crash at startup in "uma_zalloc()" (in at least the "telnetd01"
> test).
> I printed out the error, the directory already exists:
>
> mkdir("/etc",...): File exists
>
> For now I'm just checking for EEXIST and ignoring the error.
> Does anyone care to object now and say I should investigate further to fix
> the caller before I submit a patch?
>
A patch for EEXIST here should be fine. It would be nice if the caller were
more resilient.
Kinsey
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
rtems-kernel-init.c tries to re-make existing "/etc"
I just rebased to "6-freebsd-12". This change:
###
commit 62e0ca8283603573d42a0f15da044cd406a2f00a
Author: Kinsey Moore
Date: Tue Jan 23 13:25:45 2024 -0600
rtemsbsd/rtems: Check function return values
###
[dufault@gen6 rtems-libbsd]$ git diff 6514d561587fd1527fe6a26cb43e6b5742c8c779
rtemsbsd/rtems/rtems-kernel-init.c
diff --git a/rtemsbsd/rtems/rtems-kernel-init.c
b/rtemsbsd/rtems/rtems-kernel-init.c
index 90a9c80..8ac2f59 100644
--- a/rtemsbsd/rtems/rtems-kernel-init.c
+++ b/rtemsbsd/rtems/rtems-kernel-init.c
@@ -223,7 +223,9 @@ rtems_bsd_initialize(void)
return RTEMS_UNSATISFIED;
}
- mkdir("/etc", S_IRWXU | S_IRWXG | S_IRWXO);
+ if (mkdir("/etc", S_IRWXU | S_IRWXG | S_IRWXO) != 0) {
+ return RTEMS_UNSATISFIED;
+ }
sc = rtems_timer_initiate_server(rtems_bsd_get_task_priority(name),
rtems_bsd_get_task_stack_size(name), RTEMS_DEFAULT_ATTRIBUTES);
###
causes a crash at startup in "uma_zalloc()" (in at least the "telnetd01" test).
I printed out the error, the directory already exists:
mkdir("/etc",...): File exists
For now I'm just checking for EEXIST and ignoring the error.
Does anyone care to object now and say I should investigate further to fix the
caller before I submit a patch?
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: 6.1rc3 CentOS 7 Build Sweep Report
Hallo Joel, it would be nice to have the interrupt get/set priority directives in RTEMS 6. When do you want to create the RTEMS 6 branch? -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RFC] rtems: Add options to kernel output char handler
On 18.04.24 04:02, Chris Johns wrote:
On 17/4/2024 11:06 pm, Sebastian Huber wrote:
Make the kernel I/O output character device processing configurable
through an option set parameter. Add RTEMS_NO_OUTPUT and RTEMS_FLUSH
options. The goal of this API change is to enable flushing the kernel
output device in the system termination process before a reset is
issued. A use case for using RTEMS_NO_WAIT is the polled processing of
an input and output stream from and to the I/O device.
Thanks for providing this overview.
I am still confused about the differences in terms of why you would need the
RTEMS_NO_WAIT. Do you have a specific application where this is required? It
might help me understand the need for the change? Examples are need to reset in
a specific period, a test mode you are running in a system, etc?
The RTEMS_NO_WAIT can be used to process an input stream using
getchark() and then send responses using a non-blocking output char
variant. This helps to have enough processing time and allows an
overlapping send/receive.
Is this change for RTEMS 7?
Yes, this would be good.
In the context of the change:
1. RTEMS_FLUSH etc are too generic.
I added them to , so they could be reused in
other directives. A bit less generic names could be:
* RTEMS_IO_FLUSH
* RTEMS_IO_DRAIN
* RTEMS_IO_NO_OUTPUT
This would be in the IO namespace similar to RTEMS_EVENT_ANY and
RTEMS_EVENT_ALL.
2. The language used needs some work, maybe fewer "while"s. For example:
While the #RTEMS_NO_WAIT option is set in the option_set parameter, while
the #RTEMS_NO_OUTPUT option is cleared in the option_set parameter, while
the device can immediately accept a character for output, the character in
out shall be hand over to the device for output.
This is difficult to read and when it is probability easier to read the code it
is of questionable value. I appreciate it is not always easy to write but I feel
clarity would be a good to have here.
This is the documentation of a function pointer type, so there is no
direct code. With three flags, you have to specify for eight variants
what should happen. The wording is in EARS. It should be easy to
translate this into code for a particular device.
https://docs.rtems.org/branches/master/eng/req/req-for-req.html#syntax
Another example:
While no character is available in the device, a polled
character input functions shall return minus one.
It could be written as:
A polled character input function shall return a character if the device
has successfully received one else the function returns minus one.
I would prefer the EARS variant. This function type should define
requirements for the associated implementations.
I think receive and transmit is better than for example "be hand over to the
device for output", maybe "shall be transmitted by the device".
The name of this function type is BSP_output_char_function_type and not
BSP_transmit_char_function_type, so I used "output" here and not
"transmit". Also, the character may not get immediately transmitted if
FIFOs are involved (thus the need for the flush). Maybe my understanding
of transmitted is wrong, but for me transmitting has something to do
with signals on a medium.
3. Flush needs to be worded in terms of successfully transmitted by the device
to avoid the case of data being written to the device is held in FIFOs awaiting
transmission and reset is asserted. Maybe FLUSH is the wrong term because it is
so overloaded in what it means? An alternative could be
RTEMS_BSP_IO_TRANSMISSION_COMPLETE? And following on you could have
RTEMS_BSP_IO_NO_TRANSMISSION? The key point is "transmission" relates to the
external data pin of the interface.
The no-output option is used to just flush the device without
transmitting a new character. For the flush, we could add something like
this:
Flushing the device should ensure that all characters handed over to the
device for output are visible to external consumers. For example, the
device output FIFO and transmit shift registers should be empty.
Chris
---
cpukit/include/rtems/bspIo.h | 50 ++--
cpukit/include/rtems/rtems/options.h | 20 ++-
2 files changed, 67 insertions(+), 3 deletions(-)
diff --git a/cpukit/include/rtems/bspIo.h b/cpukit/include/rtems/bspIo.h
index 31580cd800..09a3c47243 100644
--- a/cpukit/include/rtems/bspIo.h
+++ b/cpukit/include/rtems/bspIo.h
@@ -10,7 +10,7 @@
*/
/*
- * Copyright (C) 2020, 2021 embedded brains GmbH & Co. KG
+ * Copyright (C) 2020, 2024 embedded brains GmbH & Co. KG
* Copyright (C) 2015 On-Line Applications Research Corporation (OAR)
*
* Redistribution and use in source and binary forms, with or without
@@ -58,6 +58,8 @@
#define _RTEMS_BSPIO_H
#include
+#include
+#include
#include
#ifdef __cplusplus
@@ -89,8 +91,42 @@ extern "C" {
* @ingroup RTEMSAPIKernelCharIO
*
* @brief Polled character
