date:20201002

[PATCH 1/3] rtemstoolkit: Fix macro's use of 'is'

2020-10-02 Thread chrisj

From: Chris Johns 

Updates #4111
---
 rtemstoolkit/macros.py | 90 +-
 1 file changed, 45 insertions(+), 45 deletions(-)

diff --git a/rtemstoolkit/macros.py b/rtemstoolkit/macros.py
index 4eb8829..be983f1 100644
--- a/rtemstoolkit/macros.py
+++ b/rtemstoolkit/macros.py
@@ -189,24 +189,24 @@ class macros:
 
 def __setitem__(self, key, value):
 key = self._unicode_to_str(key)
-if type(key) is not str:
+if type(key) != str:
 raise TypeError('bad key type (want str): %s' % (type(key)))
-if type(value) is not tuple:
+if type(value) != tuple:
 value = self._unicode_to_str(value)
-if type(value) is str:
+if type(value) == str:
 value = ('none', 'none', value)
-if type(value) is not tuple:
+if type(value) != tuple:
 raise TypeError('bad value type (want tuple): %s' % (type(value)))
 if len(value) != 3:
 raise TypeError('bad value tuple (len not 3): %d' % (len(value)))
 value = (self._unicode_to_str(value[0]),
  self._unicode_to_str(value[1]),
  self._unicode_to_str(value[2]))
-if type(value[0]) is not str:
+if type(value[0]) != str:
 raise TypeError('bad value tuple type field: %s' % 
(type(value[0])))
-if type(value[1]) is not str:
+if type(value[1]) != str:
 raise TypeError('bad value tuple attrib field: %s' % 
(type(value[1])))
-if type(value[2]) is not str:
+if type(value[2]) != str:
 raise TypeError('bad value tuple value field: %s' % 
(type(value[2])))
 if value[0] not in ['none', 'triplet', 'dir', 'file', 'exe']:
 raise TypeError('bad value tuple (type field): %s' % (value[0]))
@@ -238,7 +238,7 @@ class macros:
 return sorted(set(keys))
 
 def has_key(self, key):
-if type(key) is not str:
+if type(key) != str:
 raise TypeError('bad key type (want str): %s' % (type(key)))
 if self.key_filter(key) not in list(self.keys()):
 return False
@@ -251,7 +251,7 @@ class macros:
 return [rm[5:] for rm in self.read_maps]
 
 def key_filter(self, key):
-if key.startswith('%{') and key[-1] is '}':
+if key.startswith('%{') and key[-1] == '}':
 key = key[2:-1]
 return key.lower()
 
@@ -286,29 +286,29 @@ class macros:
 print(' c:%s(%d) s:%s t:"%s" m:%r M:%s' % \
 (c, ord(c), state, token, macro, map))
 l_remaining = l_remaining[1:]
-if c is '#' and not state.startswith('value'):
+if c == '#' and not state.startswith('value'):
 break
 if c == '\n' or c == '\r':
-if not (state is 'key' and len(token) == 0) and \
+if not (state == 'key' and len(token) == 0) and \
 not state.startswith('value-multiline'):
 self.macros = orig_macros
 raise error.general('malformed macro line:%d: %s' % 
(lc, l))
-if state is 'key':
+if state == 'key':
 if c not in string.whitespace:
-if c is '[':
+if c == '[':
 state = 'map'
-elif c is '%':
+elif c == '%':
 state = 'directive'
-elif c is ':':
+elif c == ':':
 macro += [token]
 token = ''
 state = 'attribs'
-elif c is '#':
+elif c == '#':
 break
 else:
 token += c
-elif state is 'map':
-if c is ']':
+elif state == 'map':
+if c == ']':
 if token not in self.macros:
 self.macros[token] = {}
 map = token
@@ -319,7 +319,7 @@ class macros:
 else:
 self.macros = orig_macros
 raise error.general('invalid macro map:%d: %s' % (lc, 
l))
-elif state is 'directive':
+elif state == 'directive':
 if c in string.whitespace:
 if token == 'include':
 self.load(_clean(l_remaining))
@@ -331,8 +331,8 @@ class macros:
 else:
 self.macros = orig_macros
 raise error.general('invalid macro directive:%d: %s' % 
(lc, l))
-elif state is 'include':
-if c is string.whitespace:
+

[PATCH 3/3] rtemstoolkit/linux: Fix the host support

2020-10-02 Thread chrisj

From: Chris Johns 

Updates #4111
---
 rtemstoolkit/linux.py | 20 
 1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/rtemstoolkit/linux.py b/rtemstoolkit/linux.py
index 15c6132..1ce6739 100644
--- a/rtemstoolkit/linux.py
+++ b/rtemstoolkit/linux.py
@@ -33,6 +33,7 @@
 # RTEMS project's spec files.
 #
 
+import multiprocessing
 import pprint
 import os
 import platform
@@ -42,28 +43,14 @@ import platform
 # If there is a better way to let us know.
 #
 try:
-from . import execute
 from . import path
 except (ValueError, SystemError):
-import execute
 import path
 
 def load():
 uname = os.uname()
 smp_mflags = ''
-processors = '/bin/grep processor /proc/cpuinfo'
-e = execute.capture_execution()
-exit_code, proc, output = e.shell(processors)
-ncpus = 0
-if exit_code == 0:
-try:
-for l in output.split('\n'):
-count = l.split(':')[1].strip()
-if int(count) > ncpus:
-ncpus = int(count)
-except:
-pass
-ncpus = str(ncpus + 1)
+ncpus = str(multiprocessing.cpu_count())
 if uname[4].startswith('arm'):
 cpu = 'arm'
 else:
@@ -89,8 +76,9 @@ def load():
 try:
 distro = platform.dist()[0]
 distro_ver = float(platform.dist()[1])
-except ValueError:
+except (AttributeError, ValueError):
 # Non LSB distro found, use failover"
+distro = ''
 pass
 
 # Non LSB - fail over to issue
-- 
2.24.1

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

[PATCH] bsps/arm: Workaround for Errata 845369

2020-10-02 Thread Sebastian Huber

Add a workaround for Cortex-A9 Errata 845369: Under Very Rare Timing
Circumstances Transition into Streaming Mode Might Create Data Corruption
845369: Under Very Rare Timing Circumstances Transition into Streaming Mode
Might Create Data Corruption.

Close #4115.
---
 bsps/arm/include/bsp/arm-a9mpcore-start.h | 15 +
 .../score/cpu/arm/include/libcpu/arm-cp15.h   | 32 +++
 2 files changed, 47 insertions(+)

diff --git a/bsps/arm/include/bsp/arm-a9mpcore-start.h 
b/bsps/arm/include/bsp/arm-a9mpcore-start.h
index 8423e64e9d..83c84f1c72 100644
--- a/bsps/arm/include/bsp/arm-a9mpcore-start.h
+++ b/bsps/arm/include/bsp/arm-a9mpcore-start.h
@@ -123,6 +123,20 @@ arm_a9mpcore_start_enable_smp_in_auxiliary_control(void)
   actlr |= ARM_CORTEX_A9_ACTL_SMP | ARM_CORTEX_A9_ACTL_FW;
   arm_cp15_set_auxiliary_control(actlr);
 }
+
+BSP_START_TEXT_SECTION static inline void
+arm_a9mpcore_start_errata_845369_handler(void)
+{
+  uint32_t diag;
+
+  /*
+   * Workaround for Errata 845369: Under Very Rare Timing Circumstances
+   * Transition into Streaming Mode Might Create Data Corruption.
+   */
+  diag = arm_cp15_get_diagnostic_control();
+  diag |= 1U << 22;
+  arm_cp15_set_diagnostic_control(diag);
+}
 #endif
 
 BSP_START_TEXT_SECTION static inline void arm_a9mpcore_start_hook_0(void)
@@ -138,6 +152,7 @@ BSP_START_TEXT_SECTION static inline void 
arm_a9mpcore_start_hook_0(void)
   }
 
 #ifdef RTEMS_SMP
+  arm_a9mpcore_start_errata_845369_handler();
   arm_a9mpcore_start_enable_smp_in_auxiliary_control();
 #endif
 
diff --git a/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h 
b/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h
index 6097d60ba6..5bc01dcb32 100644
--- a/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h
+++ b/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h
@@ -2308,6 +2308,38 @@ arm_cp15_set_counter_virtual_offset(uint64_t val)
   );
 }
 
+/* Diagnostic Control Register */
+ARM_CP15_TEXT_SECTION static inline uint32_t
+arm_cp15_get_diagnostic_control(void)
+{
+  ARM_SWITCH_REGISTERS;
+  uint32_t val;
+
+  __asm__ volatile (
+ARM_SWITCH_TO_ARM
+"mrc p15, 0, %[val], c15, c0, 1\n"
+ARM_SWITCH_BACK
+: [val] "=&r" (val) ARM_SWITCH_ADDITIONAL_OUTPUT
+  );
+
+  return val;
+}
+
+/* Diagnostic Control Register */
+ARM_CP15_TEXT_SECTION static inline void
+arm_cp15_set_diagnostic_control(uint32_t val)
+{
+  ARM_SWITCH_REGISTERS;
+
+  __asm__ volatile (
+ARM_SWITCH_TO_ARM
+"mcr p15, 0, %[val], c15, c0, 1\n"
+ARM_SWITCH_BACK
+: ARM_SWITCH_OUTPUT
+: [val] "r" (val)
+  );
+}
+
 /**
  * @brief Sets the @a section_flags for the address range [@a begin, @a end).
  *
-- 
2.26.2

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

Re: [PATCH 0/1] c-user: Generate I/O Manager documentation

2020-10-02 Thread Sebastian Huber


On 29/09/2020 16:59, Sebastian Huber wrote:


This is the first generated documentation of a manager. For the PDF
output please have a look at:

https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf

Please review the layout.  I changed the layout to use definition lists
instead of tables.  The benefit of definition lists is that the layout
of longer text paragraphs is much nicer compared to tables (at least for
the PDF output).


A new layout variant is available. This one has the description followed 
by the notes after the calling sequence:


https://ftp.rtems.org/pub/rtems/people/sebh/c-user-5.pdf

It also has the IO Manager directives in the order present in the 
current manual.


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

Re: waf bsp_defaults sometimes includes multiple BSPs

2020-10-02 Thread Joel Sherrill

On Fri, Oct 2, 2020 at 12:57 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 01/10/2020 23:38, Joel Sherrill wrote:
>
> > I am generating a uniquely named ini file per BSP. In doing an ls -l,
> > I noticed the size varied by at least a factor of three. This is
> > because when some BSPs are put in, the entire family is being
> > included.  I suspected this happens when a BSP name matches the family
> > name but leon3 doesn't trip this behavior. Here is an example:
> >
> > config-arm-lpc32xx_mzx.ini:[arm/lpc32xx_mzx]
> > config-arm-lpc32xx_mzx.ini:[arm/lpc32xx_mzx_stage_1]
> > config-arm-lpc32xx_mzx.ini:[arm/lpc32xx_mzx_stage_2]
> >
> > I don't think this behavior is correct. I am asking for the bsp
> > defaults for a single BSP variant.
>
> I guess you refer to the behaviour of:
>
>  --rtems-bsps=REGEX,...
>  a comma-separated list of Python regular
> expressions which select the desired BSP variants (e.g. 'sparc/erc32');
> it may be used in the bsp_defaults and bsp_list commands
>
> It is currently used like this:
>
> def is_in_white_list(variant, white_list):
>  if not white_list:
>  return True
>  for pattern in white_list:
>  if re.search(pattern, variant):
>  return True
>  return False
>
> Maybe we should change it to:
>
> def is_in_white_list(variant, white_list):
>  if not white_list:
>  return True
>  for pattern in white_list:
>  if re.match(pattern + "$", variant):
>  return True
>  return False
>

Yes. That would seem to be more right. Should it have a ^ at the front?
I think we want an exact match versus a partial one.

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

Re: waf bsp_defaults sometimes includes multiple BSPs

2020-10-02 Thread Sebastian Huber


On 02/10/2020 16:26, Joel Sherrill wrote:


Maybe we should change it to:

def is_in_white_list(variant, white_list):
 if not white_list:
 return True
 for pattern in white_list:
 if re.match(pattern + "$", variant):
 return True
 return False


Yes. That would seem to be more right. Should it have a ^ at the front?

No, for the re.match() you don't need the ^.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Approachability of Documentation Generation

2020-10-02 Thread Joel Sherrill

Hi

The other thread has a mix of detailed "review this" versus philosophy on
how to make the documentation generation process approachable so Sebastian
isn't the only human capable of maintaining it. I want to talk at a high
level about making the process approachable. The major factor in the push
from texinfo to Sphinx was to increase the number of people who knew the
format markup language and tools. We are now moving in a direction where we
have a very unique system that we are responsible for making approachable.
Otherwise, we are stuck with a system even fewer people know than texinfo.

These are random thoughts about different ways to address this problem:

   - Do not generate the documentation
  - Although this is an option, I think we all agree that there is
  value to generating multiple artifacts from the same sources for
  consistency. This unfortunately puts the burden on us to avoid having the
  generation process
   - Clear way to identify generated sections
   - Clear way to trace generated sections to yaml file source
  - All sections of generated documentation could be "fenced" with
  "start generated from XXX" and "end generated from XXX".  The
XXX should be
  very specific.
  - Another approach which I don't think I like as much is to have a
  roadmap sister document which follows the outline and shows
where each part
  came from. This would have to be automatically generated to be accurate.
  This seems to just create burden and yet another document which a human
  would have to look at and correlate to figure out what they should edit.
   - Exception documentation on writing RtEMS documentation (tests,
   headers, etc) including extremely accurate and detailed information on the
   Yaml files.
  - This is mandatory. We are heading to a very project
  specific workflow and toolchain.
   - Chris' thought that in the case manually generated content  is added,
   we need a way to know and check that so it isn't lost.
  - Possible solution. Generation tool adds checksum and checks that
  generated file matches before replacing it.

I'm sure there are other challenges but this particular generation process
flies in the face of what drove many of the RTEMS process changes over the
past decade. We went from CVS to git, texinfo to Sphinx, and autoconf to
waf because we wanted to move to more modern tools that more people knew.
With texinfo, we also had our own texinfo to html converter and had to
switch to the official one before the Sphinx conversion to avoid owning a
tool not core to our mission. I believe this generation process is good for
the RTEMS mission but we need to be very cognizant of the impact this has.
How can we avoid mistakes in the workflow? How do we bring new users up to
speed?

The idea that very few people have contributed to our documentation is now
a good thing and unless we are very careful, the promise of Sphinx opening
that group up is not going to happen. Worse, it could easily shrink the set
of people who contribute to the documentation.

Thanks for doing this but it needs to be approachable to a high school
student. We need to remember that.

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

white space in build path?

2020-10-02 Thread Gedare Bloom

Can we make spaces in paths work, or be checked/rejected, in the waf
build without too much trouble?

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

If so, we may want to move this ticket and set as something to do. If
not, I would close this as wontfix.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: white space in build path?

2020-10-02 Thread Joel Sherrill

On Fri, Oct 2, 2020 at 11:43 AM Gedare Bloom  wrote:

> Can we make spaces in paths work, or be checked/rejected, in the waf
> build without too much trouble?
>

I'd be prone to make it an error and not worry about it
deeper in the code. It would have to be properly quoted everywhere which
might be a burden.

Thinking broadly about paths, do we want to consider all the possible
screwups people make.

I have seen people use ~ on --prefix with the RSB. I don't
recall if Chris fixed that one or not.

What about any wildcards in the path name?

Similarly, an install path under the source tree is almost certainly wrong.

Just wondering if we should accept a lot or just error check
more aggressively and reject. Could avoid a number of odd
user reports by being more aggressive.

--joel

> https://devel.rtems.org/ticket/3450
>
> If so, we may want to move this ticket and set as something to do. If
> not, I would close this as wontfix.
> ___
> 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: Approachability of Documentation Generation

2020-10-02 Thread Gedare Bloom

On Fri, Oct 2, 2020 at 8:57 AM Joel Sherrill  wrote:
>
> Hi
>
> The other thread has a mix of detailed "review this" versus philosophy on how 
> to make the documentation generation process approachable so Sebastian isn't 
> the only human capable of maintaining it. I want to talk at a high level 
> about making the process approachable. The major factor in the push from 
> texinfo to Sphinx was to increase the number of people who knew the format 
> markup language and tools. We are now moving in a direction where we have a 
> very unique system that we are responsible for making approachable. 
> Otherwise, we are stuck with a system even fewer people know than texinfo.
>

Thanks for pulling this out. I think it is an important discussion to
separate for posterity too.

>From an historical perspective, I would also say that texinfo was
technically dying/dead. Sphinx provided a popular approach that
supported our requirements for HTML and PDF generation with latex-like
quality. So I wouldn't necessarily say that lowering the bar was the
primary decision to use Sphinx. If we just wanted simplicity we would
have picked one of the alternatives we discussed such as markdown and
asciidoc. The use of ReST introduced a learning curve for some of us.
Any change in formatting is going to have some learning curve.

I think one issue to consider is that tooling can help a lot with
formatting concerns. The specification items use a custom format to
encode them. Perhaps there is a better syntax (syntactic sugar) to
simplify how we refer to them, if you find the ${.*:/.*} format hard
to understand/parse. Once it is explained though, if it makes sense,
then maybe that is not so relevant; just part of the learning curve.

I do agree that we have to consider the "debt" we incur to make our
documentation system approachable. This is nothing new however in the
past the burden for the learning curve has been shifted on to the
formatting tools (e.g., texinfo or ReST/Sphinx documentation). If we
have to generate our own tutorials/HOWTOs we should be aware of that,
and make those easy to find.

Sebastian has started this here:
https://docs.rtems.org/branches/master/eng/req/howto.html#interface-specification

Certainly, this needs to be expanded especially to facilitate
documentation patches from new contributors or even non-coders
(technical writers).

> These are random thoughts about different ways to address this problem:
>
> Do not generate the documentation
>
> Although this is an option, I think we all agree that there is value to 
> generating multiple artifacts from the same sources for consistency. This 
> unfortunately puts the burden on us to avoid having the generation process
>

I lost your rich formatting/bullets. I'm going to respond by 1st level
groups. Looks like your thought trailed off at the end there. Anyway,
I think this is a non-starter. We want to avoid repetition and
copy-paste (as a project-level unofficial goal).

> Clear way to identify generated sections

I think what you want here is to understand the relationship between
the Sections, which are determined by the generator tool, and the
items that go in them, which comes from the specification. Probably
the biggest gap is understanding the mapping between the YAML
key-value pairs that get parsed for generating the documentation
content.

> Clear way to trace generated sections to yaml file source
>
> All sections of generated documentation could be "fenced" with "start 
> generated from XXX" and "end generated from XXX".  The XXX should be very 
> specific.
> Another approach which I don't think I like as much is to have a roadmap 
> sister document which follows the outline and shows where each part came 
> from. This would have to be automatically generated to be accurate.  This 
> seems to just create burden and yet another document which a human would have 
> to look at and correlate to figure out what they should edit.
>
I agree that the generator should generate comments to embed in the
documentation to help with this relationship. My guess is that
actually it won't be that hard to describe where each part comes from,
e.g., a log of the generator could be made that provides a mechanical
trace (matrix). I wouldn't use this as a documentation
writer/developer tool though.

> Exception documentation on writing RtEMS documentation (tests, headers, etc) 
> including extremely accurate and detailed information on the Yaml files.
>
> This is mandatory. We are heading to a very project specific workflow and 
> toolchain.
>
By "exception" I guess you mean the directions/tutorials that go
beyond what someone can find out from the public/search of the
wider-used formatting tools. This would be about documentation for the
RTEMS Project specific tooling and custom formats. I think actually a
lot of this has been creeping in to
https://docs.rtems.org/branches/master/eng/req/howto.html#how-to for
example your question about what ${.*:/.*} means is described

Interest in Virtual RTEMS Workshop

2020-10-02 Thread Joel Sherrill

Hi

In the past, we have internally discussed an RTEMS Workshop but always got
hung up on the basic logistics. There had to be a host site which usually
means cost. Although OAR now has access to a facility that could host about
40-50. Travel required to all be in a central location would be burdensome
based on time and cost. Remember the core developers are spread across
three continents.

The pandemic has made it clear that virtual meetings, conferences, birthday
parties, etc. are possible. Based on ideas from other open source projects,
I am curious if there would be interest in having a virtual workshop.

One thought is that given the time zones, it might be nice to do it as a
TBD number of 2-3 hour sessions which vary in time across 2-3 days. That
should let different people participate. One open source project did a 24
hour event which spanned the world. I do not want to do that. :)

I think recording the presentations beforehand and making them available
afterwards would be ideal. I have seen formal setups where questions are
restricted to the end of the presentation but like the idea of the
presenter able to chat while their presentation is going.

In my perfect world, most presentations would be from people using RTEMS,
although I expect core developer presentations would add depth to what they
are working on and the goals.

Is there interest? Would you be willing to present? participate? Advice?

Thanks.

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

[PATCH v4] cpukit/librcxx: Add a C++ thread interface with attributes

2020-10-02 Thread chrisj

From: Chris Johns 

---
 cpukit/include/rtems/c++/error|  65 +++
 cpukit/include/rtems/c++/thread   | 469 ++
 cpukit/librtemscxx/error.cc   |  76 
 cpukit/librtemscxx/thread.cc  | 416 +++
 spec/build/cpukit/grp.yml |   2 +
 spec/build/cpukit/librtemscxx.yml |  21 +
 spec/build/testsuites/libtests/grp.yml|   2 +
 spec/build/testsuites/libtests/rcxx01.yml |  22 +
 testsuites/libtests/rcxx01/init.c |  69 
 testsuites/libtests/rcxx01/rcxx01.doc |  16 +
 testsuites/libtests/rcxx01/rcxx01.scn |  13 +
 testsuites/libtests/rcxx01/thread.cc  |  90 +
 12 files changed, 1261 insertions(+)
 create mode 100644 cpukit/include/rtems/c++/error
 create mode 100644 cpukit/include/rtems/c++/thread
 create mode 100644 cpukit/librtemscxx/error.cc
 create mode 100644 cpukit/librtemscxx/thread.cc
 create mode 100644 spec/build/cpukit/librtemscxx.yml
 create mode 100644 spec/build/testsuites/libtests/rcxx01.yml
 create mode 100644 testsuites/libtests/rcxx01/init.c
 create mode 100644 testsuites/libtests/rcxx01/rcxx01.doc
 create mode 100644 testsuites/libtests/rcxx01/rcxx01.scn
 create mode 100644 testsuites/libtests/rcxx01/thread.cc

diff --git a/cpukit/include/rtems/c++/error b/cpukit/include/rtems/c++/error
new file mode 100644
index 00..8b9d875e0f
--- /dev/null
+++ b/cpukit/include/rtems/c++/error
@@ -0,0 +1,65 @@
+/* -*- C++ -*-
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2020 Chris Johns (http://contemporary.software)
+ *
+ * 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.
+ */
+/**
+ * @file
+ *
+ * @ingroup RTEMSC++
+ *
+ * RTEMS Error exception.
+ */
+
+#if !defined(RTEMS_CXX_ERROR)
+#define RTEMS_CXX_ERROR
+
+#include 
+#include 
+
+#include 
+
+namespace rtems
+{
+  class runtime_error :
+public std::runtime_error
+  {
+const rtems_status_code sc;
+  public:
+runtime_error (const rtems_status_code sc);
+runtime_error (const rtems_status_code sc, const std::string& what);
+runtime_error (const rtems_status_code sc, const char* what);
+~runtime_error ();
+  };
+
+  /**
+   * Throw a rtems::runtime_error exception if the RTEMS status code is
+   * not RTEMS_SUCCESSFUL.
+   */
+  void runtime_error_check (const rtems_status_code sc);
+  void runtime_error_check (const rtems_status_code sc, const std::string& 
what);
+  void runtime_error_check (const rtems_status_code sc, const char* what);
+};
+
+#endif
diff --git a/cpukit/include/rtems/c++/thread b/cpukit/include/rtems/c++/thread
new file mode 100644
index 00..c3f18ab3cf
--- /dev/null
+++ b/cpukit/include/rtems/c++/thread
@@ -0,0 +1,469 @@
+/* -*- C++ -*-
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2020 Chris Johns (http://contemporary.software)
+ *
+ * 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, INCID

Re: waf default number of jobs

2020-10-02 Thread Chris Johns

On 2/10/20 5:53 am, Joel Sherrill wrote:
> On Thu, Oct 1, 2020 at 2:39 PM Sebastian Huber
>  >
> wrote:
> 
> On 01/10/2020 20:09, Joel Sherrill wrote:
> 
> > What was the rationale behind the choice of the default for the number
> > of jobs for the waf build system?
> I don't know. It is the default behaviour of waf. I noticed also
> scalability problems but had no time to track them down. It could be
> also a limitation of the Python multiprocessing capabilities. I am also
> not a waf expert, I may have produced some bottlenecks.
> 
> 
> I don't think you produced any bottlenecks. Here are a couple of fragments
> from my build. I have attached the ini file so you can double check that it
> does match. Please let me know if the ini matches the configure command
> or not. If it doesn't, then I have a lot of bogus builds. :(
> 
>  ../rtems/configure --target=arm-rtems6 --enable-rtemsbsp=gumstix
> --prefix=/home/joel/rtems-cron-6/tools/6/bsp-install --disable-networking
> --enable-posix --disable-smp --disable-multiprocessing --enable-rtems-debug
> --enable-profiling --enable-tests --enable-cxx --enable-maintainer-mode
> + make -j24
> 
> real    1m53.064s
> user    7m14.675s
> sys     1m45.913s
> .
> 
> + ./waf -j 24
> 
> real    1m1.404s
> user    0m9.601s
> sys     0m1.547s
> 
> Notice how the build time for waf is 50 seconds faster but that doesn't 
> match the user and system time. Perhaps the Python jobs model doesn't
> keep them as children the same way so time doesn't get to count them.
> 
> I honestly can't explain that.
> 

Which host OS?

I am running a waf build of 5 BSPs with tests on FreeBSD 12.1 and I ran `systat
-vmstat 1` at the same time and it shows idle is around 0%, 25% is in sys and
75% is in user. The machine has with 8 cores. The powerpc/mvme5500 took 58
seconds. Python is 3.7.6.

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

[PATCH 1/3] rtemstoolkit: Fix macro's use of 'is'

[PATCH 3/3] rtemstoolkit/linux: Fix the host support

[PATCH] bsps/arm: Workaround for Errata 845369

Re: [PATCH 0/1] c-user: Generate I/O Manager documentation

Re: waf bsp_defaults sometimes includes multiple BSPs

Re: waf bsp_defaults sometimes includes multiple BSPs

Approachability of Documentation Generation

white space in build path?

Re: white space in build path?

Re: Approachability of Documentation Generation

Interest in Virtual RTEMS Workshop

[PATCH v4] cpukit/librcxx: Add a C++ thread interface with attributes

Re: waf default number of jobs

13 matches

Site Navigation

Mail list logo

Footer information