date:20200916

Re: [PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning

2020-09-16 Thread Chris Johns

On 17/9/20 9:50 am, Joel Sherrill wrote:
> On Wed, Sep 16, 2020, 6:43 PM Chris Johns  > wrote:
> 
> On 16/9/20 11:42 pm, Joel Sherrill wrote:
> > snprintf() is a safe method and I strongly disagree with the blanket
> replacement
> > of many safe methods with memcpy().
> >
> > Based on what POSIX profiles snprintf() is included in and the safety 
> and
> > security requirements those profiles are designed to meet, snprintf() is
> > supported by RTOSes that can meet DO-178 Level A.
> >
> > If the POSIX method being reviewed is in the FACE Safety Base or Safety
> Extended
> > profile, then it is OK to use and has been used in flight qualified
> > applications. And that is a general statement meaning running on any of 
> a
> > variety of RTOSes. If the usage is incorrect, let's fix it but blanket
> changing
> > them is wrong.
> 
> This is really good information, thank you.
> 
> No problem. That doesn't mean you can't do something stupid with it but
> sprintf() would be discouraged and isn't in those profiles as I recall.
> 
> I see EPICS is reporting similar issues at the moment and looking to work 
> around
> them.
> 
> And no one is questioning why? What's the risk? 
> 
> Is there a history of why this has been added to compilers as a warning?
> 
> I have no idea..snprintf has a length and avoids overwrites.
> 
> I would suggest that we find a safety or security coding standard that warns
> about whatever methods this catches. 
> 
> Personally replacing snprintf and strong operations with memmove is 
> semantically
> wrong.

I found this

https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/

The "Handling Truncation When It Occurs" section in the blog post is something
worth considering. It seems the return value of call should be checked. That
seems reasonable.

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

Re: [PATCH v1 2/6] waf: Add path-mappings feature

2020-09-16 Thread Chris Johns

On 16/9/20 8:06 pm, jan.som...@dlr.de wrote:
> Hi Chris,
> 
>> -Original Message-
>> From: Chris Johns 
>> Sent: Thursday, September 10, 2020 6:44 AM
>> To: Sommer, Jan ; devel@rtems.org
>> Subject: Re: [PATCH v1 2/6] waf: Add path-mappings feature
>>
>> On 15/8/20 5:57 am, Jan Sommer wrote:
>>> - path-mappings allow to fix autogenerated include paths for some
>>> corner cases of target platforms without the need to change the build
>>> system
>>> - Currently used for i386 based bsps
>>
>> I will need to take in this patch into my development libbsd branchs and
>> merge.
>> I will try and get this done ASAP.
>>
> 
> I am not sure I understand everything completely.
> Do you need me to update anything in the patch?
> 

Thanks but there is no need to do anything. The patches have been merged. I will
not bother about the 5 branch as I think the release branches will change around
once I get to that task.

My review of the build system found that part of this patch set on 6-freebsd-12
and so I picked it up and integrated it with my changes I had for master.

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

[PATCH] build: Fix dependencies for start and asm files

2020-09-16 Thread Sebastian Huber

Add explicit asm target feature.  Add a build start file node list and
use it as a test program dependency.

Close #3846.
Close #4080.
---
 wscript | 41 -
 1 file changed, 36 insertions(+), 5 deletions(-)

diff --git a/wscript b/wscript
index 2e42918ebb..d47f25c094 100755
--- a/wscript
+++ b/wscript
@@ -40,6 +40,8 @@ try:
 except:
 import ConfigParser as configparser
 
+from waflib.TaskGen import after, before_method, feature
+
 is_windows_host = os.name == "nt" or sys.platform in ["msys", "cygwin"]
 default_prefix = "/opt/rtems/6"
 compilers = ["gcc", "clang"]
@@ -149,6 +151,31 @@ def _is_enabled(enabled, enabled_by):
 return enabled_by in enabled
 
 
+def _explicit_asm_target(self, node):
+task = self.create_task(
+"asm", node, self.bld.bldnode.make_node(self.target)
+)
+try:
+self.compiled_tasks.append(task)
+except AttributeError:
+self.compiled_tasks = [task]
+return task
+
+
+@feature("explicit_asm_target")
+@before_method("process_source")
+def _enable_explicit_asm_target(self):
+self.mappings = dict(self.mappings)  # Copy
+self.mappings[".S"] = _explicit_asm_target
+
+
+@after("apply_link")
+@feature("cprogram", "cxxprogram")
+def process_start_files(self):
+if getattr(self, "start_files", False):
+self.link_task.dep_nodes.extend(self.bld.start_files)
+
+
 class Item(object):
 def __init__(self, uid, data):
 self.uid = uid
@@ -246,12 +273,10 @@ class Item(object):
 target = os.path.splitext(source)[0] + ".o"
 bld(
 asflags=self.data["asflags"],
-before=["cstlib"],
 cppflags=cppflags + self.data["cppflags"],
-features="asm c",
+features="explicit_asm_target asm c",
 includes=bic.includes + self.data["includes"],
-rule="${CC} ${ASFLAGS} ${CPPFLAGS} ${DEFINES_ST:DEFINES} 
${CPPPATH_ST:INCPATHS} -c ${SRC[0]} -o ${TGT}",
-source=[source] + deps,
+source=source + deps,
 target=target,
 )
 return target
@@ -532,7 +557,12 @@ class StartFileItem(Item):
 super(StartFileItem, self).__init__(uid, data)
 
 def do_build(self, bld, bic):
-self.asm(bld, bic, self.data["source"], self.get(bld, "target"))
+tgt = self.asm(bld, bic, self.data["source"], self.get(bld, "target"))
+node = bld.bldnode.make_node(tgt)
+try:
+bld.start_files.append(node)
+except AttributeError:
+bld.start_files = [node]
 self.install_target(bld)
 
 
@@ -626,6 +656,7 @@ class TestProgramItem(Item):
 install_path=None,
 ldflags=bic.ldflags + self.data["ldflags"],
 source=self.data["source"],
+start_files=True,
 stlib=self.data["stlib"],
 target=self.get(bld, "target"),
 use=self.data["use-before"] + bic.use + self.data["use-after"],
-- 
2.26.2

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

Re: [PATCH] build: Fix dependencies for start and asm files

2020-09-16 Thread Sebastian Huber


Hello,

On 17/09/2020 07:57, Sebastian Huber wrote:

Add explicit asm target feature.  Add a build start file node list and
use it as a test program dependency.

Close #3846.
Close #4080.


I only have a vague feeling what these changes do. Thomas Nagy provided 
me with a couple of code snippets and explanations which helped me to 
write this stuff. It seems to work.


The start.o dependency tracking is something which didn't work in the 
old build system.


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

Re: [PATCH] build: Fix dependencies for start and asm files

2020-09-16 Thread Chris Johns




On 17/9/20 3:57 pm, Sebastian Huber wrote:
> Add explicit asm target feature.  Add a build start file node list and
> use it as a test program dependency.
> 
> Close #3846.
> Close #4080.
> ---
>  wscript | 41 -
>  1 file changed, 36 insertions(+), 5 deletions(-)
> 
> diff --git a/wscript b/wscript
> index 2e42918ebb..d47f25c094 100755
> --- a/wscript
> +++ b/wscript
> @@ -40,6 +40,8 @@ try:
>  except:
>  import ConfigParser as configparser
>  
> +from waflib.TaskGen import after, before_method, feature
> +
>  is_windows_host = os.name == "nt" or sys.platform in ["msys", "cygwin"]
>  default_prefix = "/opt/rtems/6"
>  compilers = ["gcc", "clang"]
> @@ -149,6 +151,31 @@ def _is_enabled(enabled, enabled_by):
>  return enabled_by in enabled
>  
>  
> +def _explicit_asm_target(self, node):
> +task = self.create_task(
> +"asm", node, self.bld.bldnode.make_node(self.target)
> +)
> +try:
> +self.compiled_tasks.append(task)
> +except AttributeError:
> +self.compiled_tasks = [task]
> +return task
> +
> +
> +@feature("explicit_asm_target")

explicit_asm?

> +@before_method("process_source")
> +def _enable_explicit_asm_target(self):
> +self.mappings = dict(self.mappings)  # Copy
> +self.mappings[".S"] = _explicit_asm_target
> +
> +
> +@after("apply_link")
> +@feature("cprogram", "cxxprogram")
> +def process_start_files(self):
> +if getattr(self, "start_files", False):
> +self.link_task.dep_nodes.extend(self.bld.start_files)
> +
> +
>  class Item(object):
>  def __init__(self, uid, data):
>  self.uid = uid
> @@ -246,12 +273,10 @@ class Item(object):
>  target = os.path.splitext(source)[0] + ".o"
>  bld(
>  asflags=self.data["asflags"],
> -before=["cstlib"],
>  cppflags=cppflags + self.data["cppflags"],
> -features="asm c",
> +features="explicit_asm_target asm c",

I think ...

   features="explicit_asm asm c",

... reads better.

Chris

>  includes=bic.includes + self.data["includes"],
> -rule="${CC} ${ASFLAGS} ${CPPFLAGS} ${DEFINES_ST:DEFINES} 
> ${CPPPATH_ST:INCPATHS} -c ${SRC[0]} -o ${TGT}",
> -source=[source] + deps,
> +source=source + deps,
>  target=target,
>  )
>  return target
> @@ -532,7 +557,12 @@ class StartFileItem(Item):
>  super(StartFileItem, self).__init__(uid, data)
>  
>  def do_build(self, bld, bic):
> -self.asm(bld, bic, self.data["source"], self.get(bld, "target"))
> +tgt = self.asm(bld, bic, self.data["source"], self.get(bld, 
> "target"))
> +node = bld.bldnode.make_node(tgt)
> +try:
> +bld.start_files.append(node)
> +except AttributeError:
> +bld.start_files = [node]
>  self.install_target(bld)
>  
>  
> @@ -626,6 +656,7 @@ class TestProgramItem(Item):
>  install_path=None,
>  ldflags=bic.ldflags + self.data["ldflags"],
>  source=self.data["source"],
> +start_files=True,
>  stlib=self.data["stlib"],
>  target=self.get(bld, "target"),
>  use=self.data["use-before"] + bic.use + self.data["use-after"],
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Fix dependencies for start and asm files

2020-09-16 Thread Sebastian Huber


On 17/09/2020 08:07, Chris Johns wrote:



On 17/9/20 3:57 pm, Sebastian Huber wrote:

Add explicit asm target feature.  Add a build start file node list and
use it as a test program dependency.

Close #3846.
Close #4080.
---
  wscript | 41 -
  1 file changed, 36 insertions(+), 5 deletions(-)

diff --git a/wscript b/wscript
index 2e42918ebb..d47f25c094 100755
--- a/wscript
+++ b/wscript
@@ -40,6 +40,8 @@ try:
  except:
  import ConfigParser as configparser
  
+from waflib.TaskGen import after, before_method, feature

+
  is_windows_host = os.name == "nt" or sys.platform in ["msys", "cygwin"]
  default_prefix = "/opt/rtems/6"
  compilers = ["gcc", "clang"]
@@ -149,6 +151,31 @@ def _is_enabled(enabled, enabled_by):
  return enabled_by in enabled
  
  
+def _explicit_asm_target(self, node):

+task = self.create_task(
+"asm", node, self.bld.bldnode.make_node(self.target)
+)
+try:
+self.compiled_tasks.append(task)
+except AttributeError:
+self.compiled_tasks = [task]
+return task
+
+
+@feature("explicit_asm_target")

explicit_asm?

asm_explicit_target? The target is the important thing here.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Fix dependencies for start and asm files

2020-09-16 Thread Chris Johns

On 17/9/20 4:11 pm, Sebastian Huber wrote:
> On 17/09/2020 08:07, Chris Johns wrote:
> 
>>
>> On 17/9/20 3:57 pm, Sebastian Huber wrote:
>>> Add explicit asm target feature.  Add a build start file node list and
>>> use it as a test program dependency.
>>>
>>> Close #3846.
>>> Close #4080.
>>> ---
>>>   wscript | 41 -
>>>   1 file changed, 36 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/wscript b/wscript
>>> index 2e42918ebb..d47f25c094 100755
>>> --- a/wscript
>>> +++ b/wscript
>>> @@ -40,6 +40,8 @@ try:
>>>   except:
>>>   import ConfigParser as configparser
>>>   +from waflib.TaskGen import after, before_method, feature
>>> +
>>>   is_windows_host = os.name == "nt" or sys.platform in ["msys", "cygwin"]
>>>   default_prefix = "/opt/rtems/6"
>>>   compilers = ["gcc", "clang"]
>>> @@ -149,6 +151,31 @@ def _is_enabled(enabled, enabled_by):
>>>   return enabled_by in enabled
>>>     +def _explicit_asm_target(self, node):
>>> +    task = self.create_task(
>>> +    "asm", node, self.bld.bldnode.make_node(self.target)
>>> +    )
>>> +    try:
>>> +    self.compiled_tasks.append(task)
>>> +    except AttributeError:
>>> +    self.compiled_tasks = [task]
>>> +    return task
>>> +
>>> +
>>> +@feature("explicit_asm_target")
>> explicit_asm?
> asm_explicit_target? The target is the important thing here.

Hmmm ... oh .. it is a dependency of a test to rebuild a test. Is this because
the test is not directly dependent on the start object file self?

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

Re: [PATCH] build: Fix dependencies for start and asm files

2020-09-16 Thread Sebastian Huber


On 17/09/2020 08:21, Chris Johns wrote:


On 17/9/20 4:11 pm, Sebastian Huber wrote:

On 17/09/2020 08:07, Chris Johns wrote:


On 17/9/20 3:57 pm, Sebastian Huber wrote:

Add explicit asm target feature.  Add a build start file node list and
use it as a test program dependency.

Close #3846.
Close #4080.
---
   wscript | 41 -
   1 file changed, 36 insertions(+), 5 deletions(-)

diff --git a/wscript b/wscript
index 2e42918ebb..d47f25c094 100755
--- a/wscript
+++ b/wscript
@@ -40,6 +40,8 @@ try:
   except:
   import ConfigParser as configparser
   +from waflib.TaskGen import after, before_method, feature
+
   is_windows_host = os.name == "nt" or sys.platform in ["msys", "cygwin"]
   default_prefix = "/opt/rtems/6"
   compilers = ["gcc", "clang"]
@@ -149,6 +151,31 @@ def _is_enabled(enabled, enabled_by):
   return enabled_by in enabled
     +def _explicit_asm_target(self, node):
+    task = self.create_task(
+    "asm", node, self.bld.bldnode.make_node(self.target)
+    )
+    try:
+    self.compiled_tasks.append(task)
+    except AttributeError:
+    self.compiled_tasks = [task]
+    return task
+
+
+@feature("explicit_asm_target")

explicit_asm?

asm_explicit_target? The target is the important thing here.

Hmmm ... oh .. it is a dependency of a test to rebuild a test. Is this because
the test is not directly dependent on the start object file self?


Unfortunately the fix for #3846 and #4080 needs to be combined, because 
the fix for #3846 requires the removal of "before=["cstlib"]". This 
patch fixes two issues.


1. The tracking of start file dependencies.

2. Reflect that executables depend on the start files.

We need a start.o file in the right path, and not for example a 
start.S.17.o file in some path. This part is addressed by the 
"explicit_asm_target" feature.


This:

@after("apply_link")
@feature("cprogram", "cxxprogram")
def process_start_files(self):
    if getattr(self, "start_files", False):
    self.link_task.dep_nodes.extend(self.bld.start_files)

addresses 2.

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

Re: [PATCH] build: Fix dependencies for start and asm files

2020-09-16 Thread Chris Johns

On 17/9/20 4:26 pm, Sebastian Huber wrote:
> On 17/09/2020 08:21, Chris Johns wrote:
>> On 17/9/20 4:11 pm, Sebastian Huber wrote:
>>> On 17/09/2020 08:07, Chris Johns wrote:
 On 17/9/20 3:57 pm, Sebastian Huber wrote:
> +@feature("explicit_asm_target")
 explicit_asm?
>>> asm_explicit_target? The target is the important thing here.
>> Hmmm ... oh .. it is a dependency of a test to rebuild a test. Is this 
>> because
>> the test is not directly dependent on the start object file self?
> 
> Unfortunately the fix for #3846 and #4080 needs to be combined, because the 
> fix
> for #3846 requires the removal of "before=["cstlib"]". This patch fixes two 
> issues.
> 
> 1. The tracking of start file dependencies.
> 
> 2. Reflect that executables depend on the start files.
> 
> We need a start.o file in the right path, and not for example a start.S.17.o
> file in some path. This part is addressed by the "explicit_asm_target" 
> feature.
> 
> This:
> 
> @after("apply_link")
> @feature("cprogram", "cxxprogram")
> def process_start_files(self):
>     if getattr(self, "start_files", False):
>     self.link_task.dep_nodes.extend(self.bld.start_files)
> 
> addresses 2.
> 

Thank you for the explanation. OK to push.

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

Re: New build system ready for testing

2020-09-16 Thread Chris Johns

On 16/9/20 4:45 pm, Karel Gardas wrote:
> Looks great, but on submit attempt I've been welcome by "Akismet says
> content is spam" and I guess I solved math exercise well...

I am sorry, I have no idea why that would happen.

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

RE: [PATCH v1 7/9] bsps/pc386: Separate smp API functions. Makes smpfatal08 link

2020-09-16 Thread Jan.Sommer

Hi Sebastian,

Sure.
Is there an easy way to only send the updated patch to the mailinglist or 
should I send in the full patch set with v2?

Cheers,

  Jan

> -Original Message-
> From: Sebastian Huber 
> Sent: Tuesday, September 15, 2020 6:38 AM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: [PATCH v1 7/9] bsps/pc386: Separate smp API functions. Makes
> smpfatal08 link
> 
> Hello Jan,
> 
> On 31/05/2020 16:22, Jan Sommer wrote:
> > diff --git a/bsps/i386/pc386/start/bspsmp.c
> > b/bsps/i386/pc386/start/bspsmp.c new file mode 100644 index
> > 00..026f86916f
> > --- /dev/null
> > +++ b/bsps/i386/pc386/start/bspsmp.c
> > @@ -0,0 +1,43 @@
> > +
> > +#include 
> 
> this file has no license and copyright header. Would you mind sending a patch
> which adds one. Ideally based on this template:
> 
> https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#c-c-
> assembler-source-file-template

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

RE: [PATCH v1 2/6] waf: Add path-mappings feature

2020-09-16 Thread Jan.Sommer

Hi Chris,

> -Original Message-
> From: Chris Johns 
> Sent: Thursday, September 10, 2020 6:44 AM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: [PATCH v1 2/6] waf: Add path-mappings feature
> 
> On 15/8/20 5:57 am, Jan Sommer wrote:
> > - path-mappings allow to fix autogenerated include paths for some
> > corner cases of target platforms without the need to change the build
> > system
> > - Currently used for i386 based bsps
> 
> I will need to take in this patch into my development libbsd branchs and
> merge.
> I will try and get this done ASAP.
> 

I am not sure I understand everything completely.
Do you need me to update anything in the patch?

Best regards,

   Jan

> I am refactoring parts of the libbsd builder.py and related files to separate
> the user and kernel space headers. There are conflicts in these files that
> become apparent with some of the FreeBSD source. It looks like I based my
> work on this patch and these changes so I hope it will be easy to sort out. I
> would prefer to bring this into my branch, sort out what is happening and
> push them.
> Sorry this will not happen today but it will get done as it is top of my list.
> 
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1 7/9] bsps/pc386: Separate smp API functions. Makes smpfatal08 link

2020-09-16 Thread Sebastian Huber


On 16/09/2020 12:06, jan.som...@dlr.de wrote:


Is there an easy way to only send the updated patch to the mailinglist or 
should I send in the full patch set with v2?

It seems the patch set is already included in the RTEMS master.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v1 7/9] bsps/pc386: Separate smp API functions. Makes smpfatal08 link

2020-09-16 Thread Jan.Sommer



> -Original Message-
> From: Sebastian Huber 
> Sent: Wednesday, September 16, 2020 12:30 PM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: [PATCH v1 7/9] bsps/pc386: Separate smp API functions. Makes
> smpfatal08 link
> 
> On 16/09/2020 12:06, jan.som...@dlr.de wrote:
> 
> > Is there an easy way to only send the updated patch to the mailinglist or
> should I send in the full patch set with v2?
> It seems the patch set is already included in the RTEMS master.

Ok, then I will simply send a update.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: legacy stack or libbsd

2020-09-16 Thread Gabriel.Moyano

>On 5/8/20 2:13 pm, Gedare Bloom wrote:
>> On Tue, Aug 4, 2020 at 6:41 PM Chris Johns  wrote:
>
>>> On 5/8/20 10:23 am, Chris Johns wrote:
 On 5/8/20 2:04 am, Heinz Junkes wrote:
> Because the libbsd stack does not support some things yet (e.g. ntp)
>
 I have PTP running on libbsd. I currently have no time (ha) to clean up 
 the work
>> Is it precisely no time? ;)
>
>About +/- 0, I am not sure which! 
>
 and create a patch. It requires some extra support in the score.
>
>> Is the hacked approach available, or you will get around to it eventually?
>
>I will get back around to it. There are 2 sets of changes. In PTP itself a
>change is to add kqueue support because select in libbsd does not support
>signals. The PTP code runs a number of timers and they run of an alarm signal.
>The other piece of support is to the score to bring in the FreeBSD kern_ntp
>support to sit besides the timercounters.
>
>There will be some unresolved issues like RTC driver support. I have this
>commented out as I do not need it.
>
>I would like to upstream the code however adding kqueue will trip that 
>interface
>on FreeBSD and may be others so I am not sure how much work that will create.

Hi Chris,

We are also interested on getting running PTP on RTEMS. We can get this done in 
a joint effort.
Please let me know how we can help.

Best regards,
Gabriel


--
Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)
Institute for Software Technology | SC-OSS | Lilienthalplatz 7 | 38108 
Braunschweig  | Germany

Gabriel Moyano | Research Scientist in Onboard Software Systems group
gabriel.moy...@dlr.de
DLR.de


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

Re: [PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning

2020-09-16 Thread Joel Sherrill

snprintf() is a safe method and I strongly disagree with the blanket
replacement of many safe methods with memcpy().

Based on what POSIX profiles snprintf() is included in and the safety and
security requirements those profiles are designed to meet, snprintf() is
supported by RTOSes that can meet DO-178 Level A.

If the POSIX method being reviewed is in the FACE Safety Base or Safety
Extended profile, then it is OK to use and has been used in flight
qualified applications. And that is a general statement meaning running on
any of a variety of RTOSes. If the usage is incorrect, let's fix it but
blanket changing them is wrong.

--joel

On Wed, Sep 16, 2020 at 12:57 AM Chris Johns  wrote:

> On 16/9/20 2:36 pm, Sebastian Huber wrote:
> > On 16/09/2020 05:59, Chris Johns wrote:
> >
> >>> +   mount_path = malloc(strlen(buf) + 1 + sizeof(gz_path);
> >>> +   if (mount_path != NULL))
> >>> +strlcpy(mount_path, ".gz", sizeof(mount_path));
> >>> +  }
> >>> +  snprintf(gz_path, sizeof(gz_path), "%s.gz", buf*)
> >>> +*/
> >> Sorry I am not reviewing these changes any more.
> > Sorry Chris, this is my fault. I was not clear enough to communicate
> that this
> > patch set should first go through an internal review before we send it
> to the
> > mailing list.
>
> All good. I wanted the record to show what happened to the patches.
>
> 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

[PATCH v5 5/7] doxygen: Move top-level group definitions

2020-09-16 Thread Sebastian Huber

Update #3959.
---
 cpukit/doxygen.h  | 18 -
 cpukit/doxygen/top-level-groups.h | 44 +++
 2 files changed, 44 insertions(+), 18 deletions(-)
 create mode 100644 cpukit/doxygen/top-level-groups.h

diff --git a/cpukit/doxygen.h b/cpukit/doxygen.h
index ba75c80349..c159b2082d 100644
--- a/cpukit/doxygen.h
+++ b/cpukit/doxygen.h
@@ -1,9 +1,3 @@
-/**
- * @defgroup RTEMSInternal Internal
- *
- * @brief RTEMS Implementation.
- */
-
 /**
  * @defgroup RTEMSInternalClassic Classic
  * 
@@ -12,12 +6,6 @@
  * @brief Classic
  */
 
-/**
- * @defgroup RTEMSAPI API
- *
- * @brief API
- */
-
 /**
  * @defgroup RTEMSAPIIO IO
  *
@@ -42,12 +30,6 @@
  * @brief Tracing
  */
 
-/**
- * @defgroup RTEMSDeviceDrivers Device Drivers
- *
- * @brief Device Drivers
- */
-
 /**
  * @defgroup RTEMSLegacyBenchmarkDrivers Legacy Benchmark Drivers
  *
diff --git a/cpukit/doxygen/top-level-groups.h 
b/cpukit/doxygen/top-level-groups.h
new file mode 100644
index 00..a177e8a715
--- /dev/null
+++ b/cpukit/doxygen/top-level-groups.h
@@ -0,0 +1,44 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2019, 2020 embedded brains GmbH 
(http://www.embedded-brains.de)
+ *
+ * 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.
+ */
+
+/**
+ * @defgroup RTEMSAPI API
+ *
+ * @brief API
+ */
+
+/**
+ * @defgroup RTEMSDeviceDrivers Device Drivers
+ *
+ * @brief Device Drivers
+ */
+
+/**
+ * @defgroup RTEMSInternal Internal
+ *
+ * @brief RTEMS Implementation.
+ */
-- 
2.26.2

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

[PATCH v5 6/7] validation: Add general purpose test suite

2020-09-16 Thread Sebastian Huber

Add a general purpose test suite for validation tests.

This is the first test suite generated from a specification item in the
rtems-central repository.

Update #3959.
---
 Doxyfile  |   2 +-
 cpukit/doxygen/top-level-groups.h |   6 +
 spec/build/testsuites/grp.yml |   4 +
 spec/build/testsuites/optvalidation.yml   |  15 ++
 spec/build/testsuites/validation/grp.yml  |  18 ++
 .../testsuites/validation/validation-0.yml|  19 ++
 testsuites/validation/ts-validation-0.c   | 222 ++
 7 files changed, 285 insertions(+), 1 deletion(-)
 create mode 100644 spec/build/testsuites/optvalidation.yml
 create mode 100644 spec/build/testsuites/validation/grp.yml
 create mode 100644 spec/build/testsuites/validation/validation-0.yml
 create mode 100644 testsuites/validation/ts-validation-0.c

diff --git a/Doxyfile b/Doxyfile
index c794938191..ffb87fe89d 100644
--- a/Doxyfile
+++ b/Doxyfile
@@ -812,7 +812,7 @@ WARN_LOGFILE   =
 # spaces. See also FILE_PATTERNS and EXTENSION_MAPPING
 # Note: If this tag is empty the current directory is searched.
 
-INPUT  = bsps cpukit
+INPUT  = bsps cpukit testsuites/validation
 
 # This tag can be used to specify the character encoding of the source files
 # that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses
diff --git a/cpukit/doxygen/top-level-groups.h 
b/cpukit/doxygen/top-level-groups.h
index a177e8a715..c1a91a3482 100644
--- a/cpukit/doxygen/top-level-groups.h
+++ b/cpukit/doxygen/top-level-groups.h
@@ -42,3 +42,9 @@
  *
  * @brief RTEMS Implementation.
  */
+
+/**
+ * @defgroup RTEMSTestSuites Test Suites
+ *
+ * @brief Collection of Test Suites
+ */
diff --git a/spec/build/testsuites/grp.yml b/spec/build/testsuites/grp.yml
index ec2b6c616b..5c6457f06d 100644
--- a/spec/build/testsuites/grp.yml
+++ b/spec/build/testsuites/grp.yml
@@ -34,6 +34,8 @@ links:
   uid: optsp
 - role: build-dependency
   uid: opttm
+- role: build-dependency
+  uid: optvalidation
 - role: build-dependency
   uid: ada/grp
 - role: build-dependency
@@ -58,6 +60,8 @@ links:
   uid: sptests/grp
 - role: build-dependency
   uid: tmtests/grp
+- role: build-dependency
+  uid: validation/grp
 type: build
 use-after:
 - rtemscpu
diff --git a/spec/build/testsuites/optvalidation.yml 
b/spec/build/testsuites/optvalidation.yml
new file mode 100644
index 00..81eb320d53
--- /dev/null
+++ b/spec/build/testsuites/optvalidation.yml
@@ -0,0 +1,15 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-boolean: null
+- env-enable: null
+build-type: option
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+default: false
+default-by-variant: []
+description: |
+  Build the validation test programs (may be also enabled by BUILD_TESTS)
+enabled-by: true
+links: []
+name: BUILD_VALIDATIONTESTS
+type: build
diff --git a/spec/build/testsuites/validation/grp.yml 
b/spec/build/testsuites/validation/grp.yml
new file mode 100644
index 00..390fb48803
--- /dev/null
+++ b/spec/build/testsuites/validation/grp.yml
@@ -0,0 +1,18 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: group
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+enabled-by:
+- BUILD_TESTS
+- BUILD_VALIDATIONTESTS
+includes:
+- ${BSP_INCLUDES}
+install: []
+ldflags: []
+links:
+- role: build-dependency
+  uid: validation-0
+type: build
+use-after:
+- rtemstest
+use-before: []
diff --git a/spec/build/testsuites/validation/validation-0.yml 
b/spec/build/testsuites/validation/validation-0.yml
new file mode 100644
index 00..d024efb96f
--- /dev/null
+++ b/spec/build/testsuites/validation/validation-0.yml
@@ -0,0 +1,19 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: test-program
+cflags: []
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+cppflags: []
+cxxflags: []
+enabled-by: true
+features: c cprogram
+includes: []
+ldflags: []
+links: []
+source:
+- testsuites/validation/ts-validation-0.c
+stlib: []
+target: testsuites/validation/ts-validation-0.exe
+type: build
+use-after: []
+use-before: []
diff --git a/testsuites/validation/ts-validation-0.c 
b/testsuites/validation/ts-validation-0.c
new file mode 100644
index 00..3e60fb6ab8
--- /dev/null
+++ b/testsuites/validation/ts-validation-0.c
@@ -0,0 +1,222 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSTestSuiteTestsuitesValidation0
+ */
+
+/*
+ * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+ *
+ * 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. Redistr

[PATCH v5 1/7] rtems: Add RTEMS_ALIGN_DOWN()

2020-09-16 Thread Sebastian Huber

Update #3959.
Update #4074.
---
 cpukit/include/rtems/score/basedefs.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/cpukit/include/rtems/score/basedefs.h 
b/cpukit/include/rtems/score/basedefs.h
index 5a7e4e4f31..4d16c88b49 100644
--- a/cpukit/include/rtems/score/basedefs.h
+++ b/cpukit/include/rtems/score/basedefs.h
@@ -219,6 +219,21 @@
   #define RTEMS_WEAK_ALIAS( _target )
 #endif
 
+/**
+ * @brief Returns the specified value aligned down to the specified alignment.
+ *
+ * @param _value is the value to align down.
+ *
+ * @param _alignment is the desired alignment in bytes.  The alignment shall be
+ *   a power of two, otherwise the returned value is undefined.  The alignment
+ *   parameter is evaluated twice.
+ *
+ * @return The specified value aligned down to the specified alignment is
+ *   returned.
+ */
+#define RTEMS_ALIGN_DOWN( _value, _alignment ) \
+  ( ( _value ) & ~( ( _alignment ) - 1 ) )
+
 /**
  * @brief Instructs the compiler to enforce the specified alignment.
  */
-- 
2.26.2

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

[PATCH v5 7/7] validation: rtems_task_construct() errors

2020-09-16 Thread Sebastian Huber

This is the first test case generated from a specification item in the
rtems-central repository.

Update #3959.
---
 .../testsuites/validation/validation-0.yml|1 +
 .../validation/tc-task-construct-errors.c | 2367 +
 2 files changed, 2368 insertions(+)
 create mode 100644 testsuites/validation/tc-task-construct-errors.c

diff --git a/spec/build/testsuites/validation/validation-0.yml 
b/spec/build/testsuites/validation/validation-0.yml
index d024efb96f..edc0b570ae 100644
--- a/spec/build/testsuites/validation/validation-0.yml
+++ b/spec/build/testsuites/validation/validation-0.yml
@@ -11,6 +11,7 @@ includes: []
 ldflags: []
 links: []
 source:
+- testsuites/validation/tc-task-construct-errors.c
 - testsuites/validation/ts-validation-0.c
 stlib: []
 target: testsuites/validation/ts-validation-0.exe
diff --git a/testsuites/validation/tc-task-construct-errors.c 
b/testsuites/validation/tc-task-construct-errors.c
new file mode 100644
index 00..615186e092
--- /dev/null
+++ b/testsuites/validation/tc-task-construct-errors.c
@@ -0,0 +1,2367 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSTestCaseRtemsTaskReqConstructErrors
+ */
+
+/*
+ * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+ *
+ * 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.
+ */
+
+/*
+ * This file was automatically generated.  Do not edit it manually.
+ * Please have a look at
+ *
+ * https://docs.rtems.org/branches/master/eng/req/howto.html
+ *
+ * for information how to maintain and re-generate this file.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/**
+ * @defgroup RTEMSTestCaseRtemsTaskReqConstructErrors \
+ *   spec:/rtems/task/req/construct-errors
+ *
+ * @ingroup RTEMSTestSuiteTestsuitesValidation0
+ *
+ * @{
+ */
+
+typedef enum {
+  RtemsTaskReqConstructErrors_Pre_Id_Id,
+  RtemsTaskReqConstructErrors_Pre_Id_Null,
+  RtemsTaskReqConstructErrors_Pre_Id_NA
+} RtemsTaskReqConstructErrors_Pre_Id;
+
+typedef enum {
+  RtemsTaskReqConstructErrors_Pre_Name_Valid,
+  RtemsTaskReqConstructErrors_Pre_Name_Inv,
+  RtemsTaskReqConstructErrors_Pre_Name_NA
+} RtemsTaskReqConstructErrors_Pre_Name;
+
+typedef enum {
+  RtemsTaskReqConstructErrors_Pre_Prio_Valid,
+  RtemsTaskReqConstructErrors_Pre_Prio_Zero,
+  RtemsTaskReqConstructErrors_Pre_Prio_Inv,
+  RtemsTaskReqConstructErrors_Pre_Prio_NA
+} RtemsTaskReqConstructErrors_Pre_Prio;
+
+typedef enum {
+  RtemsTaskReqConstructErrors_Pre_Tasks_Avail,
+  RtemsTaskReqConstructErrors_Pre_Tasks_None,
+  RtemsTaskReqConstructErrors_Pre_Tasks_NA
+} RtemsTaskReqConstructErrors_Pre_Tasks;
+
+typedef enum {
+  RtemsTaskReqConstructErrors_Pre_TLS_Enough,
+  RtemsTaskReqConstructErrors_Pre_TLS_Small,
+  RtemsTaskReqConstructErrors_Pre_TLS_NA
+} RtemsTaskReqConstructErrors_Pre_TLS;
+
+typedef enum {
+  RtemsTaskReqConstructErrors_Pre_Stack_Enough,
+  RtemsTaskReqConstructErrors_Pre_Stack_Small,
+  RtemsTaskReqConstructErrors_Pre_Stack_NA
+} RtemsTaskReqConstructErrors_Pre_Stack;
+
+typedef enum {
+  RtemsTaskReqConstructErrors_Pre_Ext_Ok,
+  RtemsTaskReqConstructErrors_Pre_Ext_Err,
+  RtemsTaskReqConstructErrors_Pre_Ext_NA
+} RtemsTaskReqConstructErrors_Pre_Ext;
+
+typedef enum {
+  RtemsTaskReqConstructErrors_Pre_Preempt_Yes,
+  RtemsTaskReqConstructErrors_Pre_Preempt_No,
+  RtemsTaskReqConstructErrors_Pre_Preempt_NA
+} RtemsTaskReqConstructErrors_Pre_Preempt;
+
+typedef enum {
+  RtemsTaskReqConstructErrors_Post_Status_Ok,
+  RtemsTaskReqConstructErrors_Post_Status_InvAddress,
+  RtemsTaskReqConstructErrors_Post_Status_InvName,
+  RtemsTaskReqConstructErrors_Post_Status_InvPrio,
+  RtemsTaskReqConstr

[PATCH v5 4/7] rtems: Add rtems_task_construct()

2020-09-16 Thread Sebastian Huber

In contrast to rtems_task_create() this function constructs a task with
a user-provided task storage area.  The new directive uses a
configuration structure instead of individual parameters.

Add RTEMS_TASK_STORAGE_SIZE() to calculate the recommended size of a
task storage area based on the task attributes and the size dedicated to
the task stack and thread-local storage.  This macro may allow future
extensions without breaking the API.

Add application configuration option
CONFIGURE_MINIMUM_TASKS_WITH_USER_PROVIDED_STORAGE to adjust RTEMS
Workspace size estimate.

Update #3959.
---
 cpukit/doxygen/appl-config.h|  22 ++
 cpukit/include/rtems/confdefs/threads.h |   8 +
 cpukit/include/rtems/confdefs/wkspace.h |   4 +-
 cpukit/include/rtems/rtems/tasks.h  | 184 +++
 cpukit/include/rtems/rtems/tasksimpl.h  |  11 +
 cpukit/rtems/src/taskconstruct.c| 300 
 cpukit/rtems/src/taskcreate.c   | 282 +-
 spec/build/cpukit/librtemscpu.yml   |   1 +
 testsuites/sptests/sp01/init.c  |  24 +-
 testsuites/sptests/sp01/sp01.doc|   1 +
 testsuites/sptests/sp01/system.h|   3 +-
 11 files changed, 604 insertions(+), 236 deletions(-)
 create mode 100644 cpukit/rtems/src/taskconstruct.c

diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index 9593d9848d..0efd69b964 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -902,6 +902,28 @@
  */
 #define CONFIGURE_MAXIMUM_USER_EXTENSIONS
 
+/**
+ * @brief This configuration option is an integer define.
+ *
+ * The value of this configuration option defines the minimum count of Classic
+ * API Tasks which are constructed by rtems_task_construct().
+ *
+ * @par Default Value
+ * The default value is 0.
+ *
+ * @par Value Constraints
+ * The value of this configuration option shall be greater than or equal to 0
+ * and less than or equal to #CONFIGURE_MAXIMUM_TASKS.
+ *
+ * @par Notes
+ * By default, the calculation for the required memory in the RTEMS Workspace
+ * for tasks assumes that all Classic API Tasks are created by
+ * rtems_task_create().  This configuration option can be used to reduce the
+ * required memory for the system-provided task storage areas since tasks
+ * constructed by rtems_task_construct() use a user-provided task storage area.
+ */
+#define CONFIGURE_MINIMUM_TASKS_WITH_USER_PROVIDED_STORAGE
+
 /** @} */
 
 /**
diff --git a/cpukit/include/rtems/confdefs/threads.h 
b/cpukit/include/rtems/confdefs/threads.h
index 9e34696e61..8f72407695 100644
--- a/cpukit/include/rtems/confdefs/threads.h
+++ b/cpukit/include/rtems/confdefs/threads.h
@@ -60,6 +60,14 @@
 
 #define _CONFIGURE_TASKS ( CONFIGURE_MAXIMUM_TASKS + _CONFIGURE_LIBBLOCK_TASKS 
)
 
+#ifndef CONFIGURE_MINIMUM_TASKS_WITH_USER_PROVIDED_STORAGE
+  #define CONFIGURE_MINIMUM_TASKS_WITH_USER_PROVIDED_STORAGE 0
+#endif
+
+#if CONFIGURE_MINIMUM_TASKS_WITH_USER_PROVIDED_STORAGE > 
CONFIGURE_MAXIMUM_TASKS
+  #error "CONFIGURE_MINIMUM_TASKS_WITH_USER_PROVIDED_STORAGE shall be less 
than or equal to CONFIGURE_MAXIMUM_TASKS"
+#endif
+
 #ifndef CONFIGURE_MAXIMUM_POSIX_THREADS
   #define CONFIGURE_MAXIMUM_POSIX_THREADS 0
 #endif
diff --git a/cpukit/include/rtems/confdefs/wkspace.h 
b/cpukit/include/rtems/confdefs/wkspace.h
index de476dbf82..3b464899dc 100644
--- a/cpukit/include/rtems/confdefs/wkspace.h
+++ b/cpukit/include/rtems/confdefs/wkspace.h
@@ -100,7 +100,9 @@
 + _CONFIGURE_POSIX_INIT_THREAD_STACK_EXTRA \
 + _CONFIGURE_LIBBLOCK_TASKS_STACK_EXTRA \
 + CONFIGURE_EXTRA_TASK_STACKS \
-+ rtems_resource_maximum_per_allocation( _CONFIGURE_TASKS ) \
++ rtems_resource_maximum_per_allocation( \
+_CONFIGURE_TASKS - CONFIGURE_MINIMUM_TASKS_WITH_USER_PROVIDED_STORAGE \
+  ) \
   * _Configure_From_stackspace( CONFIGURE_MINIMUM_TASK_STACK_SIZE ) \
 + rtems_resource_maximum_per_allocation( CONFIGURE_MAXIMUM_POSIX_THREADS ) 
\
   * _Configure_From_stackspace( CONFIGURE_MINIMUM_POSIX_THREAD_STACK_SIZE 
) \
diff --git a/cpukit/include/rtems/rtems/tasks.h 
b/cpukit/include/rtems/rtems/tasks.h
index e07db6cd2b..fac2e2c75c 100644
--- a/cpukit/include/rtems/rtems/tasks.h
+++ b/cpukit/include/rtems/rtems/tasks.h
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #ifdef __cplusplus
@@ -173,6 +174,189 @@ rtems_status_code rtems_task_create(
  */
 #define RTEMS_TASK_STORAGE_ALIGNMENT CPU_HEAP_ALIGNMENT
 
+/**
+ * @brief Returns the recommended task storage area size for the specified size
+ *   and task attributes.
+ *
+ * @param _size is the size dedicated to the task stack and thread-local
+ *   storage in bytes.
+ *
+ * @param _attributes is the attribute set of the task using the storage area.
+ *
+ * @return The recommended task storage area size calculated from the input
+ *   parameters is returned.
+ */
+#if CPU_ALL_TASKS_ARE_FP == TRUE
+  #define RTEMS_TASK_STORAGE_SIZE( _size, _attributes ) \
+( (

[PATCH v5 0/7] Add rtems_task_construct()

2020-09-16 Thread Sebastian Huber

v2:

Rename function from rtems_task_build() to
rtems_task_create_from_config().  Add RTEMS_TASK_STORAGE_ALIGNMENT and
RTEMS_TASK_STORAGE_SIZE().  Improve documentation.

v3:

Add CONFIGURE_TASKS_CREATED_FROM_CONFIG.  Fix RTEMS_TASK_STORAGE_SIZE() if
CPU_ALL_TASKS_ARE_FP == TRUE.

v4:

Add CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE to control the maximum size
reserved for thread-local storage.

Add maximum_thread_local_storage_size member to rtems_task_config to check that
the thread-local storage size in the task configuration is sufficient for the
actual thread-local storage size of the application.

Add a general purpose test suite for basic validation tests.  Add a validation
test case to check the rtems_task_create_from_config() error cases.  The code
is generated from specification items:

https://git.rtems.org/rtems-central/tree/spec/testsuites/validation-0.yml

https://git.rtems.org/rtems-central/tree/spec/req/rtems/tasks/create-from-config-errors.yml

The build system part of the new tests is not included in the patch set.  I
don't want to add a new test suite for the old build system.

v5:

Rename rtems_task_create_from_config() in rtems_task_construct().

Rename CONFIGURE_TASKS_CREATED_FROM_CONFIG in
CONFIGURE_MINIMUM_TASKS_WITH_USER_PROVIDED_STORAGE.

Add RTEMS_ALIGN_DOWN() and RTEMS_ALIGN_UP().

Change RTEMS_TASK_STORAGE_ALIGNMENT to be an integer instead of a
variable attribute.

The item used to generate the test case is this:

https://git.rtems.org/rtems-central/tree/spec/rtems/task/req/construct-errors.yml

Update documentation according to review comments.

Sebastian Huber (7):
  rtems: Add RTEMS_ALIGN_DOWN()
  rtems: Add RTEMS_ALIGN_UP()
  CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE
  rtems: Add rtems_task_construct()
  doxygen: Move top-level group definitions
  validation: Add general purpose test suite
  validation: rtems_task_construct() errors

 Doxyfile  |2 +-
 cpukit/doxygen.h  |   18 -
 cpukit/doxygen/appl-config.h  |   60 +
 cpukit/doxygen/top-level-groups.h |   50 +
 cpukit/include/rtems/confdefs/threads.h   |   15 +
 cpukit/include/rtems/confdefs/wkspace.h   |4 +-
 cpukit/include/rtems/rtems/tasks.h|  193 ++
 cpukit/include/rtems/rtems/tasksimpl.h|   11 +
 cpukit/include/rtems/score/basedefs.h |   30 +
 cpukit/include/rtems/score/interr.h   |3 +-
 cpukit/include/rtems/score/thread.h   |   10 +
 cpukit/rtems/src/taskconstruct.c  |  300 +++
 cpukit/rtems/src/taskcreate.c |  282 +-
 cpukit/sapi/src/interrtext.c  |5 +-
 cpukit/score/src/tlsallocsize.c   |   16 +-
 spec/build/cpukit/librtemscpu.yml |1 +
 spec/build/testsuites/grp.yml |4 +
 spec/build/testsuites/optvalidation.yml   |   15 +
 spec/build/testsuites/sptests/grp.yml |2 +
 spec/build/testsuites/sptests/spfatal33.yml   |   19 +
 spec/build/testsuites/validation/grp.yml  |   18 +
 .../testsuites/validation/validation-0.yml|   20 +
 testsuites/sptests/sp01/init.c|   24 +-
 testsuites/sptests/sp01/sp01.doc  |1 +
 testsuites/sptests/sp01/system.h  |3 +-
 testsuites/sptests/spfatal33/init.c   |   55 +
 testsuites/sptests/spfatal33/spfatal33.doc|   11 +
 testsuites/sptests/spfatal33/spfatal33.scn|   16 +
 testsuites/sptests/spinternalerror02/init.c   |4 +-
 .../validation/tc-task-construct-errors.c | 2367 +
 testsuites/validation/ts-validation-0.c   |  222 ++
 31 files changed, 3518 insertions(+), 263 deletions(-)
 create mode 100644 cpukit/doxygen/top-level-groups.h
 create mode 100644 cpukit/rtems/src/taskconstruct.c
 create mode 100644 spec/build/testsuites/optvalidation.yml
 create mode 100644 spec/build/testsuites/sptests/spfatal33.yml
 create mode 100644 spec/build/testsuites/validation/grp.yml
 create mode 100644 spec/build/testsuites/validation/validation-0.yml
 create mode 100644 testsuites/sptests/spfatal33/init.c
 create mode 100644 testsuites/sptests/spfatal33/spfatal33.doc
 create mode 100644 testsuites/sptests/spfatal33/spfatal33.scn
 create mode 100644 testsuites/validation/tc-task-construct-errors.c
 create mode 100644 testsuites/validation/ts-validation-0.c

-- 
2.26.2

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

[PATCH v5 3/7] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

2020-09-16 Thread Sebastian Huber

Add this application configuration option.  This configuration option can be
used to reserve space for the dynamic linking of modules with thread-local
storage objects.

Add RTEMS_TASK_STORAGE_ALIGNMENT to define the minium alignment of a
thread-local storage size.

Update #4074.
---
 cpukit/doxygen/appl-config.h| 38 ++
 cpukit/include/rtems/confdefs/threads.h |  7 +++
 cpukit/include/rtems/rtems/tasks.h  |  9 
 cpukit/include/rtems/score/interr.h |  3 +-
 cpukit/include/rtems/score/thread.h | 10 
 cpukit/sapi/src/interrtext.c|  5 +-
 cpukit/score/src/tlsallocsize.c | 16 --
 spec/build/testsuites/sptests/grp.yml   |  2 +
 spec/build/testsuites/sptests/spfatal33.yml | 19 +++
 testsuites/sptests/spfatal33/init.c | 55 +
 testsuites/sptests/spfatal33/spfatal33.doc  | 11 +
 testsuites/sptests/spfatal33/spfatal33.scn  | 16 ++
 testsuites/sptests/spinternalerror02/init.c |  4 +-
 13 files changed, 187 insertions(+), 8 deletions(-)
 create mode 100644 spec/build/testsuites/sptests/spfatal33.yml
 create mode 100644 testsuites/sptests/spfatal33/init.c
 create mode 100644 testsuites/sptests/spfatal33/spfatal33.doc
 create mode 100644 testsuites/sptests/spfatal33/spfatal33.scn

diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index cd4664f7c8..9593d9848d 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -801,6 +801,44 @@
  */
 #define CONFIGURE_MAXIMUM_TASKS
 
+/**
+ * @brief This configuration option is an integer define.
+ *
+ * If the value of this configuration option is greater than zero, then it
+ * defines the maximum thread-local storage size, otherwise the thread-local
+ * storage size is defined by the linker depending on the thread-local storage
+ * objects used by the application in the statically-linked executable.
+ *
+ * @par Default Value
+ * The default value is 0.
+ *
+ * @par Value Constraints
+ * The value of this configuration option shall be greater than or equal to 0
+ * and less than or equal to https://en.cppreference.com/w/c/types/limits";>SIZE_MAX.
+ *
+ * @par Notes
+ * @parblock
+ * This configuration option can be used to reserve space for the dynamic
+ * linking of modules with thread-local storage objects.
+ *
+ * If the thread-local storage size defined by the thread-local storage objects
+ * used by the application in the statically-linked executable is greater than
+ * a non-zero value of this configuration option, then a fatal error will occur
+ * during system initialization.
+ *
+ * Use RTEMS_ALIGN_UP() and #RTEMS_TASK_STORAGE_ALIGNMENT to adjust the size to
+ * meet the minimum alignment requirement of a thread-local storage area.
+ * @endparblock
+ *
+ * The actual thread-local storage size is determined when the application
+ * executable is linked.  The ``rtems-exeinfo`` command line tool included in
+ * the RTEMS Tools can be used to obtain the thread-local storage size and
+ * alignment of an application executable.
+ * @endparblock
+ */
+#define CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE
+
 /**
  * @brief This configuration option is an integer define.
  *
diff --git a/cpukit/include/rtems/confdefs/threads.h 
b/cpukit/include/rtems/confdefs/threads.h
index 33b8c5cee2..9e34696e61 100644
--- a/cpukit/include/rtems/confdefs/threads.h
+++ b/cpukit/include/rtems/confdefs/threads.h
@@ -84,6 +84,10 @@
   #define CONFIGURE_MAXIMUM_THREAD_NAME_SIZE THREAD_DEFAULT_MAXIMUM_NAME_SIZE
 #endif
 
+#ifndef CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE
+  #define CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE 0
+#endif
+
 #ifdef __cplusplus
 extern "C" {
 #endif
@@ -125,6 +129,9 @@ typedef union {
 
 const size_t _Thread_Maximum_name_size = CONFIGURE_MAXIMUM_THREAD_NAME_SIZE;
 
+const size_t _Thread_Maximum_TLS_size =
+  CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE;
+
 struct Thread_Configured_control {
   Thread_Control Control;
   #if CONFIGURE_MAXIMUM_USER_EXTENSIONS > 0
diff --git a/cpukit/include/rtems/rtems/tasks.h 
b/cpukit/include/rtems/rtems/tasks.h
index 12c323e60e..e07db6cd2b 100644
--- a/cpukit/include/rtems/rtems/tasks.h
+++ b/cpukit/include/rtems/rtems/tasks.h
@@ -164,6 +164,15 @@ rtems_status_code rtems_task_create(
   rtems_id*id
 );
 
+/**
+ * @brief This constant defines the recommended alignment of a task storage
+ *   area in bytes.
+ *
+ * Use it with RTEMS_ALIGNED() to define the alignment of a statically
+ * allocated task storage area.
+ */
+#define RTEMS_TASK_STORAGE_ALIGNMENT CPU_HEAP_ALIGNMENT
+
 /**
  * @brief RTEMS Task Name to Id
  *
diff --git a/cpukit/include/rtems/score/interr.h 
b/cpukit/include/rtems/score/interr.h
index 2f449deedb..1371e55653 100644
--- a/cpukit/include/rtems/score/interr.h
+++ b/cpukit/include/rtems/score/interr.h
@@ -203,7 +203,8 @@ typedef enum {
   INTERNAL_ERROR_LIBIO_STDERR_FD_OPEN_FAILED = 37,
   INTERNAL_ERROR_ILLEGAL_USE_OF_FLOATING

[PATCH v5 2/7] rtems: Add RTEMS_ALIGN_UP()

2020-09-16 Thread Sebastian Huber

Update #3959.
Update #4074.
---
 cpukit/include/rtems/score/basedefs.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/cpukit/include/rtems/score/basedefs.h 
b/cpukit/include/rtems/score/basedefs.h
index 4d16c88b49..c31b4ebef7 100644
--- a/cpukit/include/rtems/score/basedefs.h
+++ b/cpukit/include/rtems/score/basedefs.h
@@ -234,6 +234,21 @@
 #define RTEMS_ALIGN_DOWN( _value, _alignment ) \
   ( ( _value ) & ~( ( _alignment ) - 1 ) )
 
+/**
+ * @brief Returns the specified value aligned up to the specified alignment.
+ *
+ * @param _value is the value to align up.
+ *
+ * @param _alignment is the desired alignment in bytes.  The alignment shall be
+ *   a power of two, otherwise the returned value is undefined.  The alignment
+ *   parameter is evaluated twice.
+ *
+ * @return The specified value aligned up to the specified alignment is
+ *   returned.
+ */
+#define RTEMS_ALIGN_UP( _value, _alignment ) \
+  ( ( ( _value ) + ( _alignment ) - 1 ) & ~( ( _alignment ) - 1 ) )
+
 /**
  * @brief Instructs the compiler to enforce the specified alignment.
  */
-- 
2.26.2

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

Re: devel Digest, Vol 106, Issue 81

2020-09-16 Thread Utkarsh Rai

On Mon, Sep 14, 2020 at 5:30 PM  wrote:

> Send devel mailing list submissions to
> devel@rtems.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.rtems.org/mailman/listinfo/devel
> or, via email, send a message with subject or body 'help' to
> devel-requ...@rtems.org
>
> You can reach the person managing the list at
> devel-ow...@rtems.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of devel digest..."
>
>
> Today's Topics:
>
>1. New build system ready for testing (Sebastian Huber)
>
>
> --
>
> Message: 1
> Date: Mon, 14 Sep 2020 09:07:42 +0200
> From: Sebastian Huber 
> To: RTEMS 
> Subject: New build system ready for testing
> Message-ID: <7530cecd-e1b4-b1be-af12-7593fc456...@embedded-brains.de>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hello,
>
> I checked in the new build system today. Now is a good time to test your
> favourite BSP if it still works.


Hello Sebastian, I have tested the new build system for the realview and
the xilinx_zynq_qemu BSP during my GSoC project. The config.ini file had
the options generated from "./waf bsp_defaults". The legacy stack for both
the BSPs builds successfully, the RSB build is also successful. Although I
am not sure how to run all the tests?


> You find the user oriented
> documentation of build system here:


> https://docs.rtems.org/branches/master/user/bld/index.html
>
> The documentation for RTEMS maintainers is here:
>
> https://docs.rtems.org/branches/master/eng/build-system.html
>
> How to check the new build system for a particular BSP?
>
> 1. Build the BSP with all tests enabled.
>
> 2. Run the tests and compare the results with the old build system.
> Ideally use the RTEMS Tester to run the tests and report them to the
> RTEMS Project.
>
> 3. Check if all BSP options are available (./waf bsp_defaults). Check
> the type and values of the BSP options.
>
> 4. Check the linker command file.
>
> 5. Check the compiler machine flags.
>
> 6. Install the BSP and build your third-party libraries and applications
> with it.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG.
>
>
> --
>
> Subject: Digest Footer
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
> --
>
> End of devel Digest, Vol 106, Issue 81
> **
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Strong APA scheduler testing

2020-09-16 Thread Richi Dubey

Hi,

Sorry for the delay. My university tests were going on.

So, I reran the test only for smptestsuites, and I have attached the log.

The test says that smpfatal09 gives timeout, where when I ran the test with
qemu, I get the following output:

---
~/quick-start/rtems/5/bin$ ./qemu-system-arm -net none -nographic -M
realview-pbx-a9 -m 256M -kernel
~/quick-start/build/b3-realview/arm-rtems5/c/realview_pbx_a9_qemu/testsuites/smptests/smpfatal09.exe
-smp 4

*** BEGIN OF TEST SMPFATAL 9 ***
*** TEST VERSION: 6.0.0.cba933cb2260afc79c2a94d7c26bce1b58a7dbfd-modified
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP
*** TEST TOOLS: 7.5.0 20191114 (RTEMS 5, RSB 5 (0b7e87143b76), Newlib
fbaa096)

*** END OF TEST SMPFATAL 9 ***


*** FATAL ***
fatal source: 0 (INTERNAL_ERROR_CORE)
fatal code: 40 (INTERNAL_ERROR_NO_MEMORY_FOR_PER_CPU_DATA)
RTEMS version: 6.0.0.cba933cb2260afc79c2a94d7c26bce1b58a7dbfd-modified
RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (0b7e87143b76), Newlib fbaa096)
executing thread is NULL


*** BEGIN OF TEST SMPFATAL 9 ***
*** TEST VERSION: 6.0.0.cba933cb2260afc79c2a94d7c26bce1b58a7dbfd-modified
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP
*** TEST TOOLS: 7.5.0 20191114 (RTEMS 5, RSB 5 (0b7e87143b76), Newlib
fbaa096)

*** END OF TEST SMPFATAL 9 ***


*** FATAL ***

and so on ...

---

Also, I ran the qemu with gdb and I get the same result. Why does
rtems-test feel it is timeout? Is it because of the 200 s limit?

Please let me know.



On Sat, Sep 12, 2020 at 7:47 PM Richi Dubey  wrote:

> Understood. I'm on it. I'll try to debug the scheduler related tests first
> i.e SMP tests if there are errors in them.
>
> On Fri, Sep 11, 2020 at 3:30 AM Gedare Bloom  wrote:
>
>> Start at the end and work your way back.
>>
>> The clean version reports:
>> Passed:636
>> Failed:  1
>> User Input:  6
>> Expected Fail:   1
>> Indeterminate:   0
>> Benchmark:   3
>> Timeout: 3
>> Invalid: 5
>> Wrong Version:   1
>> Wrong Build: 0
>> Wrong Tools: 0
>> --
>> Total: 656
>>
>>
>> Your version reports:
>> Passed:600
>> Failed: 22
>> User Input:  6
>> Expected Fail:   1
>> Indeterminate:   0
>> Benchmark:   3
>> Timeout:16
>> Invalid: 6
>> Wrong Version:   0
>> Wrong Build: 0
>> Wrong Tools: 0
>> --
>> Total: 654
>>
>> You'll want to poke at those failures first and triage them. Fixing
>> one may cascade to other tests, so rerun the testsuite after you try a
>> fix.
>>
>> On Thu, Sep 10, 2020 at 12:59 PM Richi Dubey 
>> wrote:
>> >
>> > Hi,
>> >
>> > Please find attached the log of rtems-test with the "clean" version
>> (Commit: 61ccb9c05d (HEAD, tag: 5.1, origin/5) bsp/xilinx-zynq: Flush
>> TX-Buffer before initializing uar) vs my Strong APA changes (with name
>> log_leon3_sis_strong_apa).
>> >
>> > I haven't looked at the log in detail yet, but please let me know if
>> there's anything odd that sparks interest.
>> >
>> > Thanks,
>> > Richi.
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>>
>


log_leon3_sis_strong_apa_new
Description: Binary data
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v1 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

2020-09-16 Thread G S Niteesh Babu

RTEMS OFW is a FDT only implementation of the OpenFirmWare
interface. This API is created to be compatible with FreeBSD
OpenFirmWare interface. The main intention is to make
porting of FreeBSD drivers to RTEMS easier.

Most functions implemented have an direct one-one mapping
with the original OFW API and some extra auxiliary functions
were implemented to make working with device trees easier in
RTEMS.

Update #3784
---
 bsps/include/ofw/ofw.h| 548 +++
 bsps/include/ofw/ofw_compat.h |  74 
 bsps/shared/ofw/ofw.c | 682 ++
 spec/build/bsps/obj.yml   |   5 +
 4 files changed, 1309 insertions(+)
 create mode 100644 bsps/include/ofw/ofw.h
 create mode 100644 bsps/include/ofw/ofw_compat.h
 create mode 100644 bsps/shared/ofw/ofw.c

diff --git a/bsps/include/ofw/ofw.h b/bsps/include/ofw/ofw.h
new file mode 100644
index 00..411010be89
--- /dev/null
+++ b/bsps/include/ofw/ofw.h
@@ -0,0 +1,548 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup ofw
+ *
+ * RTEMS FDT implementation of OpenFirmWare Interface.
+ *
+ * RTEMS OFW is a FDT only implementation of the OpenFirmWare interface.
+ * This API is created to be compatible with FreeBSD OpenFirmWare interface.
+ * The main intention is to make porting of FreeBSD drivers to RTEMS easier.
+ */
+
+/*
+ * Copyright (C) 2020 Niteesh Babu G S 
+ *
+ * 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.
+ */
+
+#ifndef _OFW_H
+#define _OFW_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include 
+#include 
+#include 
+
+/**
+ * Represents a node in the device tree. The offset from fdtp to node is used
+ * instead of fdt offset to make sure this is compatible with OF interface in
+ * FreeBSD.
+ */
+typedef uint32_t  phandle_t;
+/**
+ * Represents the effective phandle of the node.
+ */
+typedef uint32_t  ihandle_t;
+/**
+ * Represents the data type of the buffer.
+ */
+typedef uint32_t  pcell_t;
+
+/**
+ * @struct rtems_ofw_memory_area
+ *
+ * This is used to represent elements(FDT properties) that define
+ * region of memory address.
+ */
+typedef struct {
+  /** The start address of the memory region. */
+  uint32_t start;
+  /** The size of the memory region. */
+  uint32_t size;
+} rtems_ofw_memory_area;
+
+/**
+ * @struct rtems_ofw_ranges
+ *
+ * This is used to represent the ranges property in the device tree.
+ */
+typedef struct {
+  /** The physical address within the child bus address space */
+  uint32_t child_bus;
+  /** The physical address within the parent bus address space */
+  uint32_t parent_bus;
+  /** The size of the range in the child’s address space */
+  uint32_t size;
+} rtems_ofw_ranges;
+
+/**
+ * @brief Gets the node that is next to @a node.
+ *
+ * @param[in] node Node offset
+ *
+ * @retval Peer node offset Successful operation.
+ * @retval 0 No peer node or invalid node handle
+ */
+phandle_t rtems_ofw_peer(
+  phandle_t   node
+);
+
+/**
+ * @brief Gets the node that is the child of @a node.
+ *
+ * @param[in] node Node offset
+ *
+ * @retval child node offset Successful operation.
+ * @retval 0 No child node or invalid node handle
+ */
+phandle_t rtems_ofw_child(
+  phandle_t   node
+);
+
+/**
+ * @brief Gets the node that is the parent of @a node.
+ *
+ * @param[in] node Node offset
+ *
+ * @retval child node offset Successful operation.
+ * @retval 0 No child node or invalid node handle
+ */
+phandle_t rtems_ofw_parent(
+  phandle_t   node
+);
+
+/**
+ * @brief Gets the length of the property mentioned in @a propname.
+ *
+ * @param[in] node Node offset
+ * @param[in] prop Property name
+ *
+ * @retval -1 Invalid node or property
+ * @retval  Length of property on successful operati

[PATCH v1 2/2] libtests/ofw01: Added a test for RTEMS OFW

2020-09-16 Thread G S Niteesh Babu

This commit adds a basic test that tests all the implemented
RTEMS OFW functions.
---
 spec/build/testsuites/libtests/grp.yml   |   2 +
 spec/build/testsuites/libtests/ofw01.yml |  21 +++
 testsuites/libtests/ofw01/init.c | 187 +++
 testsuites/libtests/ofw01/ofw01.doc  |  29 
 testsuites/libtests/ofw01/ofw01.scn  |   2 +
 testsuites/libtests/ofw01/some.c |  72 +
 testsuites/libtests/ofw01/some.dts   |  76 +
 testsuites/libtests/ofw01/some.h |  15 ++
 8 files changed, 404 insertions(+)
 create mode 100644 spec/build/testsuites/libtests/ofw01.yml
 create mode 100644 testsuites/libtests/ofw01/init.c
 create mode 100644 testsuites/libtests/ofw01/ofw01.doc
 create mode 100644 testsuites/libtests/ofw01/ofw01.scn
 create mode 100644 testsuites/libtests/ofw01/some.c
 create mode 100644 testsuites/libtests/ofw01/some.dts
 create mode 100644 testsuites/libtests/ofw01/some.h

diff --git a/spec/build/testsuites/libtests/grp.yml 
b/spec/build/testsuites/libtests/grp.yml
index aff46c9f8f..82c2288e2f 100644
--- a/spec/build/testsuites/libtests/grp.yml
+++ b/spec/build/testsuites/libtests/grp.yml
@@ -316,6 +316,8 @@ links:
   uid: write
 - role: build-dependency
   uid: writev
+- role: build-dependency
+  uid: ofw01
 type: build
 use-after:
 - rtemstest
diff --git a/spec/build/testsuites/libtests/ofw01.yml 
b/spec/build/testsuites/libtests/ofw01.yml
new file mode 100644
index 00..8517c58bad
--- /dev/null
+++ b/spec/build/testsuites/libtests/ofw01.yml
@@ -0,0 +1,21 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: test-program
+cflags: []
+copyrights:
+- Copyright (C) 2020 Niteesh G S
+cppflags: []
+cxxflags: []
+enabled-by: true
+features: c cprogram
+includes: []
+ldflags:
+- -Wl,--wrap=bsp_fdt_get
+links: []
+source:
+- testsuites/libtests/ofw01/init.c
+- testsuites/libtests/ofw01/some.c
+stlib: []
+target: testsuites/libtests/ofw01.exe
+type: build
+use-after: []
+use-before: []
diff --git a/testsuites/libtests/ofw01/init.c b/testsuites/libtests/ofw01/init.c
new file mode 100644
index 00..82ee5eb11f
--- /dev/null
+++ b/testsuites/libtests/ofw01/init.c
@@ -0,0 +1,187 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) <2020> Niteesh G S 
+ *
+ * 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.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "some.h"
+
+#define BUF_SIZE 100
+
+const char rtems_test_name[] = "OFW 01";
+
+const void *__wrap_bsp_fdt_get(void);
+const void *__real_bsp_fdt_get(void);
+
+const void *__wrap_bsp_fdt_get(void)
+{
+  if (some_bin != NULL) {
+return &some_bin[0];
+  }
+
+  return __real_bsp_fdt_get();
+}
+
+static void Init(rtems_task_argument arg)
+{
+  int rv;
+  phandle_t d;
+  phandle_t l;
+  phandle_t t;
+  phandle_t c;
+  phandle_t a;
+  phandle_t b;
+  phandle_t q;
+  phandle_t root;
+  phandle_t temp;
+  uint32_t *arr;
+  char buf[BUF_SIZE];
+  char *bufp;
+  ssize_t buf_len;
+  rtems_ofw_memory_area reg;
+  rtems_ofw_memory_area regs[2];
+  rtems_vector_number intr;
+  rtems_vector_number intrs[2];
+  TEST_BEGIN();
+  buf_len = sizeof(buf);
+  /*
+   * Cannot use fdt_path_offset to compare because
+   * the OF interface uses the offset from the ftdp
+   * to the node as phandle.
+   */
+  root = rtems_ofw_find_device("/");
+  rtems_test_assert(root == 56);
+
+  root = rtems_ofw_peer(0);
+  rtems_test_assert(root == 56);
+
+  d = rtems_ofw_child(root);
+  temp = rtems_ofw_find_device("/d");
+  rtems_test_assert(d == temp);
+
+  temp = rtems_ofw_parent(d);
+  rtems_test_assert(root == temp);
+
+  rv = rtems_ofw_get

Re: [PATCH v1 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

2020-09-16 Thread Niteesh G. S.

Hello,

Sorry for the delay, I was a bit occupied with my university work.
Now since the new build system is merged I would like to get my
GSoC work merged too.

The goal of this series patches is to implement the OFW API into RTEMS
and modify libBSD to use this RTEMS API instead of its own.

Thanks,
Niteesh.

On Wed, Sep 16, 2020 at 10:33 PM G S Niteesh Babu 
wrote:

> RTEMS OFW is a FDT only implementation of the OpenFirmWare
> interface. This API is created to be compatible with FreeBSD
> OpenFirmWare interface. The main intention is to make
> porting of FreeBSD drivers to RTEMS easier.
>
> Most functions implemented have an direct one-one mapping
> with the original OFW API and some extra auxiliary functions
> were implemented to make working with device trees easier in
> RTEMS.
>
> Update #3784
> ---
>  bsps/include/ofw/ofw.h| 548 +++
>  bsps/include/ofw/ofw_compat.h |  74 
>  bsps/shared/ofw/ofw.c | 682 ++
>  spec/build/bsps/obj.yml   |   5 +
>  4 files changed, 1309 insertions(+)
>  create mode 100644 bsps/include/ofw/ofw.h
>  create mode 100644 bsps/include/ofw/ofw_compat.h
>  create mode 100644 bsps/shared/ofw/ofw.c
>
> diff --git a/bsps/include/ofw/ofw.h b/bsps/include/ofw/ofw.h
> new file mode 100644
> index 00..411010be89
> --- /dev/null
> +++ b/bsps/include/ofw/ofw.h
> @@ -0,0 +1,548 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup ofw
> + *
> + * RTEMS FDT implementation of OpenFirmWare Interface.
> + *
> + * RTEMS OFW is a FDT only implementation of the OpenFirmWare interface.
> + * This API is created to be compatible with FreeBSD OpenFirmWare
> interface.
> + * The main intention is to make porting of FreeBSD drivers to RTEMS
> easier.
> + */
> +
> +/*
> + * Copyright (C) 2020 Niteesh Babu G S 
> + *
> + * 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.
> + */
> +
> +#ifndef _OFW_H
> +#define _OFW_H
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * Represents a node in the device tree. The offset from fdtp to node is
> used
> + * instead of fdt offset to make sure this is compatible with OF
> interface in
> + * FreeBSD.
> + */
> +typedef uint32_t  phandle_t;
> +/**
> + * Represents the effective phandle of the node.
> + */
> +typedef uint32_t  ihandle_t;
> +/**
> + * Represents the data type of the buffer.
> + */
> +typedef uint32_t  pcell_t;
> +
> +/**
> + * @struct rtems_ofw_memory_area
> + *
> + * This is used to represent elements(FDT properties) that define
> + * region of memory address.
> + */
> +typedef struct {
> +  /** The start address of the memory region. */
> +  uint32_t start;
> +  /** The size of the memory region. */
> +  uint32_t size;
> +} rtems_ofw_memory_area;
> +
> +/**
> + * @struct rtems_ofw_ranges
> + *
> + * This is used to represent the ranges property in the device tree.
> + */
> +typedef struct {
> +  /** The physical address within the child bus address space */
> +  uint32_t child_bus;
> +  /** The physical address within the parent bus address space */
> +  uint32_t parent_bus;
> +  /** The size of the range in the child’s address space */
> +  uint32_t size;
> +} rtems_ofw_ranges;
> +
> +/**
> + * @brief Gets the node that is next to @a node.
> + *
> + * @param[in] node Node offset
> + *
> + * @retval Peer node offset Successful operation.
> + * @retval 0 No peer node or invalid node handle
> + */
> +phandle_t rtems_ofw_peer(
> +  phandle_t   node
> +);
> +
> +/**
> + * @brief Gets the node that is the child of @a node.
> + *
> + * @param[in] node Node offset
> + *
> + * @

[RTEMS-libBSD OFW v1] dev/ofw: Use RTEMS OFW FDT implementation

2020-09-16 Thread G S Niteesh Babu

This commit modifies the OFW interface to the RTEMS FDT
implementation instead of the default FreeBSD.
---
 freebsd/sys/dev/ofw/openfirm.c|  2 ++
 freebsd/sys/dev/ofw/openfirm.h|  9 
 .../machine/rtems-bsd-kernel-namespace.h  | 22 ---
 3 files changed, 11 insertions(+), 22 deletions(-)

diff --git a/freebsd/sys/dev/ofw/openfirm.c b/freebsd/sys/dev/ofw/openfirm.c
index 9cc7dbdc..30513ab2 100644
--- a/freebsd/sys/dev/ofw/openfirm.c
+++ b/freebsd/sys/dev/ofw/openfirm.c
@@ -333,6 +333,7 @@ OF_interpret(const char *cmd, int nreturns, ...)
  * Device tree functions
  */
 
+#ifndef __rtems__
 /* Return the next sibling of this node or 0. */
 phandle_t
 OF_peer(phandle_t node)
@@ -672,6 +673,7 @@ OF_xref_from_node(phandle_t node)
return (node);
return (xref);
 }
+#endif /* __rtems__ */
 
 device_t
 OF_device_from_xref(phandle_t xref)
diff --git a/freebsd/sys/dev/ofw/openfirm.h b/freebsd/sys/dev/ofw/openfirm.h
index f043197a..5df07258 100644
--- a/freebsd/sys/dev/ofw/openfirm.h
+++ b/freebsd/sys/dev/ofw/openfirm.h
@@ -64,7 +64,11 @@
 
 #include 
 #include 
+#ifdef __rtems__
+#include 
+#endif /* __rtems__ */
 
+#ifndef __rtems__
 /*
  * Prototypes for Open Firmware Interface Routines
  */
@@ -72,6 +76,7 @@
 typedef uint32_t   ihandle_t;
 typedef uint32_t   phandle_t;
 typedef uint32_t   pcell_t;
+#endif /* __rtems__ */
 
 #ifdef _KERNEL
 #include 
@@ -102,6 +107,7 @@ int OF_test(const char *name);
 void   OF_printf(const char *fmt, ...);
 
 /* Device tree functions */
+#ifndef __rtems__
 phandle_t  OF_peer(phandle_t node);
 phandle_t  OF_child(phandle_t node);
 phandle_t  OF_parent(phandle_t node);
@@ -140,6 +146,7 @@ ssize_t OF_package_to_path(phandle_t node, char 
*buf, size_t len);
  */
 phandle_t  OF_node_from_xref(phandle_t xref);
 phandle_t  OF_xref_from_node(phandle_t node);
+#endif /* __rtems__ */
 
 /*
  * When properties contain references to other nodes using xref handles it is
@@ -159,8 +166,10 @@ ssize_tOF_read(ihandle_t instance, void *buf, 
size_t len);
 ssize_tOF_write(ihandle_t instance, const void *buf, size_t 
len);
 intOF_seek(ihandle_t instance, uint64_t where);
 
+#ifndef __rtems__
 phandle_t  OF_instance_to_package(ihandle_t instance);
 ssize_tOF_instance_to_path(ihandle_t instance, char *buf, 
size_t len);
+#endif /* __rtems__ */
 intOF_call_method(const char *method, ihandle_t instance,
int nargs, int nreturns, ...);
 
diff --git a/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h 
b/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
index 75b744a4..53944393 100644
--- a/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
+++ b/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
@@ -3044,42 +3044,20 @@
 #definenull_filtops _bsd_null_filtops
 #definenullop _bsd_nullop
 #defineOF_call_method _bsd_OF_call_method
-#defineOF_canon _bsd_OF_canon
-#defineOF_child _bsd_OF_child
 #defineOF_claim _bsd_OF_claim
 #defineOF_close _bsd_OF_close
 #defineOF_device_from_xref _bsd_OF_device_from_xref
 #defineOF_device_register_xref _bsd_OF_device_register_xref
 #defineOF_enter _bsd_OF_enter
 #defineOF_exit _bsd_OF_exit
-#defineOF_finddevice _bsd_OF_finddevice
-#defineOF_getencprop _bsd_OF_getencprop
-#defineOF_getencprop_alloc _bsd_OF_getencprop_alloc
-#defineOF_getencprop_alloc_multi _bsd_OF_getencprop_alloc_multi
-#defineOF_getprop _bsd_OF_getprop
-#defineOF_getprop_alloc _bsd_OF_getprop_alloc
-#defineOF_getprop_alloc_multi _bsd_OF_getprop_alloc_multi
-#defineOF_getproplen _bsd_OF_getproplen
-#defineOF_hasprop _bsd_OF_hasprop
 #defineOF_init _bsd_OF_init
 #defineOF_install _bsd_OF_install
-#defineOF_instance_to_package _bsd_OF_instance_to_package
-#defineOF_instance_to_path _bsd_OF_instance_to_path
 #defineOF_interpret _bsd_OF_interpret
-#defineOF_nextprop _bsd_OF_nextprop
-#defineOF_node_from_xref _bsd_OF_node_from_xref
 #defineOF_open _bsd_OF_open
-#defineOF_package_to_path _bsd_OF_package_to_path
-#defineOF_parent _bsd_OF_parent
-#defineOF_peer _bsd_OF_peer
 #defineOF_printf _bsd_OF_printf
-#defineOF_prop_free _bsd_OF_prop_free
 #defineOF_read _bsd_OF_read
 #defineOF_release _bsd_OF_release
-#defineOF_searchencprop _bsd_OF_searchencprop
-#defineOF_searchprop _bsd_OF_searchprop
 #defineOF_seek _bsd_OF_seek
-#defineOF_setprop _bsd_OF_setprop
 #defineOF_test _bsd_OF_test
 #defineofw_bus_assigned_addresses_to_rl 
_bsd_ofw_bus_assigned_addresses_to_rl
 #defineofwbus_driver _bsd_ofwbus_driver
-- 
2.17.1

_

RTEMS BSP Builder and New/Old Build System

2020-09-16 Thread Joel Sherrill

Hi

Just noting that it would be nice to have a transition period where RTEMS
BSP Builder supported both build systems for comparison purposes.

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

Re: RTEMS BSP Builder and New/Old Build System

2020-09-16 Thread Chris Johns

On 17/9/20 8:12 am, Joel Sherrill wrote:
> Just noting that it would be nice to have a transition period where RTEMS BSP
> Builder supported both build systems for comparison purposes.

I prefer this be as short as possible. What about 1st Nov 2020?

It is not clear what the criteria is to trigger removal of the old build system.
We do not want a set of rules that are difficult to meet stalling the removal.

If you would like to meet some criteria please documented it on this page:

https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist

The columns in the table are the checklists but there are no rules on what needs
to be completed. It was intended to be a status.

The new build system is way better to work with and if a user reports an issue
we should be able to sort it out. The 5.1 release is the old build system base
line once it is removed from master.

Chris

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

Re: [PATCH v5 0/7] Add rtems_task_construct()

2020-09-16 Thread Chris Johns

Looks good.

Thanks for your patience as we worked through this change. I think the outcome
is solid and reflects the efforts made.

Chris

On 17/9/20 12:49 am, Sebastian Huber wrote:
> v2:
> 
> Rename function from rtems_task_build() to
> rtems_task_create_from_config().  Add RTEMS_TASK_STORAGE_ALIGNMENT and
> RTEMS_TASK_STORAGE_SIZE().  Improve documentation.
> 
> v3:
> 
> Add CONFIGURE_TASKS_CREATED_FROM_CONFIG.  Fix RTEMS_TASK_STORAGE_SIZE() if
> CPU_ALL_TASKS_ARE_FP == TRUE.
> 
> v4:
> 
> Add CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE to control the maximum size
> reserved for thread-local storage.
> 
> Add maximum_thread_local_storage_size member to rtems_task_config to check 
> that
> the thread-local storage size in the task configuration is sufficient for the
> actual thread-local storage size of the application.
> 
> Add a general purpose test suite for basic validation tests.  Add a validation
> test case to check the rtems_task_create_from_config() error cases.  The code
> is generated from specification items:
> 
> https://git.rtems.org/rtems-central/tree/spec/testsuites/validation-0.yml
> 
> https://git.rtems.org/rtems-central/tree/spec/req/rtems/tasks/create-from-config-errors.yml
> 
> The build system part of the new tests is not included in the patch set.  I
> don't want to add a new test suite for the old build system.
> 
> v5:
> 
> Rename rtems_task_create_from_config() in rtems_task_construct().
> 
> Rename CONFIGURE_TASKS_CREATED_FROM_CONFIG in
> CONFIGURE_MINIMUM_TASKS_WITH_USER_PROVIDED_STORAGE.
> 
> Add RTEMS_ALIGN_DOWN() and RTEMS_ALIGN_UP().
> 
> Change RTEMS_TASK_STORAGE_ALIGNMENT to be an integer instead of a
> variable attribute.
> 
> The item used to generate the test case is this:
> 
> https://git.rtems.org/rtems-central/tree/spec/rtems/task/req/construct-errors.yml
> 
> Update documentation according to review comments.
> 
> Sebastian Huber (7):
>   rtems: Add RTEMS_ALIGN_DOWN()
>   rtems: Add RTEMS_ALIGN_UP()
>   CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE
>   rtems: Add rtems_task_construct()
>   doxygen: Move top-level group definitions
>   validation: Add general purpose test suite
>   validation: rtems_task_construct() errors
> 
>  Doxyfile  |2 +-
>  cpukit/doxygen.h  |   18 -
>  cpukit/doxygen/appl-config.h  |   60 +
>  cpukit/doxygen/top-level-groups.h |   50 +
>  cpukit/include/rtems/confdefs/threads.h   |   15 +
>  cpukit/include/rtems/confdefs/wkspace.h   |4 +-
>  cpukit/include/rtems/rtems/tasks.h|  193 ++
>  cpukit/include/rtems/rtems/tasksimpl.h|   11 +
>  cpukit/include/rtems/score/basedefs.h |   30 +
>  cpukit/include/rtems/score/interr.h   |3 +-
>  cpukit/include/rtems/score/thread.h   |   10 +
>  cpukit/rtems/src/taskconstruct.c  |  300 +++
>  cpukit/rtems/src/taskcreate.c |  282 +-
>  cpukit/sapi/src/interrtext.c  |5 +-
>  cpukit/score/src/tlsallocsize.c   |   16 +-
>  spec/build/cpukit/librtemscpu.yml |1 +
>  spec/build/testsuites/grp.yml |4 +
>  spec/build/testsuites/optvalidation.yml   |   15 +
>  spec/build/testsuites/sptests/grp.yml |2 +
>  spec/build/testsuites/sptests/spfatal33.yml   |   19 +
>  spec/build/testsuites/validation/grp.yml  |   18 +
>  .../testsuites/validation/validation-0.yml|   20 +
>  testsuites/sptests/sp01/init.c|   24 +-
>  testsuites/sptests/sp01/sp01.doc  |1 +
>  testsuites/sptests/sp01/system.h  |3 +-
>  testsuites/sptests/spfatal33/init.c   |   55 +
>  testsuites/sptests/spfatal33/spfatal33.doc|   11 +
>  testsuites/sptests/spfatal33/spfatal33.scn|   16 +
>  testsuites/sptests/spinternalerror02/init.c   |4 +-
>  .../validation/tc-task-construct-errors.c | 2367 +
>  testsuites/validation/ts-validation-0.c   |  222 ++
>  31 files changed, 3518 insertions(+), 263 deletions(-)
>  create mode 100644 cpukit/doxygen/top-level-groups.h
>  create mode 100644 cpukit/rtems/src/taskconstruct.c
>  create mode 100644 spec/build/testsuites/optvalidation.yml
>  create mode 100644 spec/build/testsuites/sptests/spfatal33.yml
>  create mode 100644 spec/build/testsuites/validation/grp.yml
>  create mode 100644 spec/build/testsuites/validation/validation-0.yml
>  create mode 100644 testsuites/sptests/spfatal33/init.c
>  create mode 100644 testsuites/sptests/spfatal33/spfatal33.doc
>  create mode 100644 testsuites/sptests/spfatal33/spfatal33.scn
>  create mode 100644 testsuites/validation/tc-task-construct-errors.c
>  create mode 100644 testsuites/validation/ts-validation-0.c
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning

2020-09-16 Thread Chris Johns

On 16/9/20 11:42 pm, Joel Sherrill wrote:
> snprintf() is a safe method and I strongly disagree with the blanket 
> replacement
> of many safe methods with memcpy().
> 
> Based on what POSIX profiles snprintf() is included in and the safety and
> security requirements those profiles are designed to meet, snprintf() is
> supported by RTOSes that can meet DO-178 Level A.
> 
> If the POSIX method being reviewed is in the FACE Safety Base or Safety 
> Extended
> profile, then it is OK to use and has been used in flight qualified
> applications. And that is a general statement meaning running on any of a
> variety of RTOSes. If the usage is incorrect, let's fix it but blanket 
> changing
> them is wrong.

This is really good information, thank you.

I see EPICS is reporting similar issues at the moment and looking to work around
them.

Is there a history of why this has been added to compilers as a warning?

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

Re: [PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning

2020-09-16 Thread Joel Sherrill

On Wed, Sep 16, 2020, 6:43 PM Chris Johns  wrote:

> On 16/9/20 11:42 pm, Joel Sherrill wrote:
> > snprintf() is a safe method and I strongly disagree with the blanket
> replacement
> > of many safe methods with memcpy().
> >
> > Based on what POSIX profiles snprintf() is included in and the safety and
> > security requirements those profiles are designed to meet, snprintf() is
> > supported by RTOSes that can meet DO-178 Level A.
> >
> > If the POSIX method being reviewed is in the FACE Safety Base or Safety
> Extended
> > profile, then it is OK to use and has been used in flight qualified
> > applications. And that is a general statement meaning running on any of a
> > variety of RTOSes. If the usage is incorrect, let's fix it but blanket
> changing
> > them is wrong.
>
> This is really good information, thank you.
>

No problem. That doesn't mean you can't do something stupid with it but
sprintf() would be discouraged and isn't in those profiles as I recall.

>
> I see EPICS is reporting similar issues at the moment and looking to work
> around
> them.
>

And no one is questioning why? What's the risk?

>
> Is there a history of why this has been added to compilers as a warning?
>

I have no idea..snprintf has a length and avoids overwrites.

I would suggest that we find a safety or security coding standard that
warns about whatever methods this catches.

Personally replacing snprintf and strong operations with memmove is
semantically wrong.

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

Re: [PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning

Re: [PATCH v1 2/6] waf: Add path-mappings feature

[PATCH] build: Fix dependencies for start and asm files

Re: [PATCH] build: Fix dependencies for start and asm files

Re: [PATCH] build: Fix dependencies for start and asm files

Re: [PATCH] build: Fix dependencies for start and asm files

Re: [PATCH] build: Fix dependencies for start and asm files

Re: [PATCH] build: Fix dependencies for start and asm files

Re: [PATCH] build: Fix dependencies for start and asm files

Re: New build system ready for testing

RE: [PATCH v1 7/9] bsps/pc386: Separate smp API functions. Makes smpfatal08 link

RE: [PATCH v1 2/6] waf: Add path-mappings feature

Re: [PATCH v1 7/9] bsps/pc386: Separate smp API functions. Makes smpfatal08 link

RE: [PATCH v1 7/9] bsps/pc386: Separate smp API functions. Makes smpfatal08 link

RE: legacy stack or libbsd

Re: [PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning

[PATCH v5 5/7] doxygen: Move top-level group definitions

[PATCH v5 6/7] validation: Add general purpose test suite

[PATCH v5 1/7] rtems: Add RTEMS_ALIGN_DOWN()

[PATCH v5 7/7] validation: rtems_task_construct() errors

[PATCH v5 4/7] rtems: Add rtems_task_construct()

[PATCH v5 0/7] Add rtems_task_construct()

[PATCH v5 3/7] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

[PATCH v5 2/7] rtems: Add RTEMS_ALIGN_UP()

Re: devel Digest, Vol 106, Issue 81

Re: Strong APA scheduler testing

[PATCH v1 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

[PATCH v1 2/2] libtests/ofw01: Added a test for RTEMS OFW

Re: [PATCH v1 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

[RTEMS-libBSD OFW v1] dev/ofw: Use RTEMS OFW FDT implementation

RTEMS BSP Builder and New/Old Build System

Re: RTEMS BSP Builder and New/Old Build System

Re: [PATCH v5 0/7] Add rtems_task_construct()

Re: [PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning

Re: [PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning

35 matches

Site Navigation

Mail list logo

Footer information