Re: RTEMS BSP Builder and New/Old Build System

[Sebastian Huber]

On 17/09/2020 01:34, Chris Johns wrote:


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?


I added a ticket for this:

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


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.


It is critical to run the tests generated by the new build system. To 
run the build alone is not enough. For example, the i386 BSPs were 
completely broken since they used some special stuff in the *.cfg files.


A known issue is the -fdata-sections and -ffunction-sections handling in 
libbsd.


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

[PATCH rtems-libbsd 2/3] builder.py: Add case for plain text files.

[Christian Mauderer]

Update #4082
---
 builder.py | 8 
 1 file changed, 8 insertions(+)

diff --git a/builder.py b/builder.py
index f5fe2afc..0eda461f 100755
--- a/builder.py
+++ b/builder.py
@@ -202,6 +202,9 @@ def revertFixLocalIncludes(data):
 data = re.sub('#include ]*)>', '#include "\\1"', data)
 return data
 
+def assertNothing(path):
+pass
+
 def assertHeaderFile(path):
 if path[-2] != '.' or path[-1] != 'h':
 print("*** " + path + " does not end in .h")
@@ -690,6 +693,11 @@ class Module(object):
reverseConverter, buildSystemComposer)]
 return files
 
+def addPlainTextFile(self, files):
+self.files += self.addFiles(files,
+FreeBSDPathComposer(), Converter(),
+Converter(), assertNothing)
+
 def addKernelSpaceHeaderFiles(self, files):
 self.files += self.addFiles(files,
 FreeBSDPathComposer(), 
FromFreeBSDToRTEMSHeaderConverter(),
-- 
2.26.2

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

[PATCH rtems-libbsd 3/3] Import FreeBSD license files.

[Christian Mauderer]

Fix #4082
---
 freebsd/COPYRIGHT | 126 ++
 freebsd/contrib/expat/COPYING |  21 +
 freebsd/contrib/libpcap/LICENSE   |  19 
 freebsd/contrib/libxo/LICENSE |  23 +
 freebsd/contrib/tcpdump/LICENSE   |  19 
 freebsd/contrib/wpa/COPYING   |  22 +
 freebsd/crypto/openssl/LICENSE| 125 +
 freebsd/sys/contrib/libsodium/LICENSE |  18 
 freebsd/sys/dev/e1000/LICENSE |  31 +++
 libbsd.py |  45 +
 10 files changed, 449 insertions(+)
 create mode 100644 freebsd/COPYRIGHT
 create mode 100644 freebsd/contrib/expat/COPYING
 create mode 100644 freebsd/contrib/libpcap/LICENSE
 create mode 100644 freebsd/contrib/libxo/LICENSE
 create mode 100644 freebsd/contrib/tcpdump/LICENSE
 create mode 100644 freebsd/contrib/wpa/COPYING
 create mode 100644 freebsd/crypto/openssl/LICENSE
 create mode 100644 freebsd/sys/contrib/libsodium/LICENSE
 create mode 100644 freebsd/sys/dev/e1000/LICENSE

diff --git a/freebsd/COPYRIGHT b/freebsd/COPYRIGHT
new file mode 100644
index ..4a40a9f3
--- /dev/null
+++ b/freebsd/COPYRIGHT
@@ -0,0 +1,126 @@
+# $FreeBSD$
+#  @(#)COPYRIGHT   8.2 (Berkeley) 3/21/94
+
+The compilation of software known as FreeBSD is distributed under the
+following terms:
+
+Copyright (c) 1992-2020 The FreeBSD Project.
+
+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 AUTHOR 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 AUTHOR OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGE.
+
+The 4.4BSD and 4.4BSD-Lite software is distributed under the following
+terms:
+
+All of the documentation and software included in the 4.4BSD and 4.4BSD-Lite
+Releases is copyrighted by The Regents of the University of California.
+
+Copyright 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
+   The Regents of the University of California.  All rights reserved.
+
+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.
+3. All advertising materials mentioning features or use of this software
+   must display the following acknowledgement:
+This product includes software developed by the University of
+California, Berkeley and its contributors.
+4. Neither the name of the University nor the names of its contributors
+   may be used to endorse or promote products derived from this software
+   without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE REGENTS 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 REGENTS OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGE.
+
+The Institute of Electrical and Electronics Engineers and the American
+National Standards Committee X3, on Information Processing Systems have
+given us permission to reprint portions of their documentation.
+
+In the following statement, the phrase ``this text'' refers to portions
+of 

License files missing on 5-freebsd-12 branch

[Christian Mauderer]

Hello,

Chris pinged me that I missed to add these patches to the 5-freebsd-12
branch. It would be good if we would add the license files to the
release branch too. This will allow users to easily find the correct
licenses.

Best regards

Christian


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

Re: [PATCH rtems-libbsd 1/3] Add helper script to find licenses.

[Joel Sherrill]

I think I'm ok on all three of these patches but some
comments on the shell script. I can see where this is a
tedious but important check. And it can be improved easily.

Since this smells like something Chris would poke me f
or and call a "Joel script" :)

On Thu, Sep 17, 2020 at 4:33 AM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> Update #4082
> ---
>  find_licenses_and_unused.sh | 121 
>  1 file changed, 121 insertions(+)
>  create mode 100755 find_licenses_and_unused.sh
>
> diff --git a/find_licenses_and_unused.sh b/find_licenses_and_unused.sh
> new file mode 100755
> index ..ee15f652
> --- /dev/null
> +++ b/find_licenses_and_unused.sh
> @@ -0,0 +1,121 @@
> +#!/bin/bash
> +
> +#
> +# Copyright (c) 2018 embedded brains GmbH.  All rights reserved.
> +#
> +#  embedded brains GmbH
> +#  Dornierstr. 4
> +#  82178 Puchheim
> +#  Germany
> +#  
> +#
> +# 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 AUTHOR 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 AUTHOR 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.
> +#
> +
> +# exit on wrong command and undefined variable
> +set -e
> +set -u
> +set -o pipefail
> +
> +SCRIPTNAME=$0
> +TARGET="freebsd/"
> +SOURCE="freebsd-org/"
> +LIST="libbsd.py"
> +FORCE=0
> +
> +printhelp () {
> +   echo ""
> +   echo "Call:   ${SCRIPTNAME} "
> +   echo "1. Find LICENSE files for each file in \"${TARGET}\" if the"
> +   echo "   license file is not in ${LIST}."
> +   echo "2. Find all files in \"${TARGET}\" that are not in
> \"${LIST}\"."
> +   echo "   Note: This function currently prints a lot of generated
> files too."
>

If they are generated, isn't there a source to generated file pattern that
can be
taken advantage of to eliminate them from the output ahead of the dirname in
checkfile.  Get the basename, switch on a set of known generated output
names, verify there is the correct input file, and then continue so it does
not
show up in the output.

Reducing the noisy output seems important and straightforward. You know
how to do it by hand so there should be a few patterns.


> +   echo "Reccomended usage:"
>

Spelling.


> +   echo "./${SCRIPTNAME} | sort | uniq"
>

Just add this to the find line that drives everything. And why not sort -u?

If you want it to be an option, just put those in a second function and
pipe through that.

maybe_sort()
{
  if [ ${do_sort} = "yes" ] l then
   sort -u
  else
cat
 fi
}

+   echo ""
> +   echo "The following parameters are optional:"
> +   echo "  -h  Print this help and exit the script."
> +   echo "  -f  Force printing all license files."
> +   echo "  -v  Be more verbose. Can be used multiple times."
> +   exit 0
> +}
> +
> +while getopts "hfv" OPTION
> +do
> +   case ${OPTION} in
> +   h)  printhelp ;;
> +   f)  FORCE=1 ;;
> +   \?) echo "Unknown option \"-${OPTARG}\"."
> +   exit 1 ;;
> +   :)  echo "Option \"-${OPTARG}\" needs an argument."; exit
> 1 ;;
> +   esac
> +done
> +shift $((${OPTIND} - 1))
> +
> +checkfile () {
> +   local FILE="$1"
> +   local FILE_WITHOUT_PATH=${FILE#"$TARGET"}
> +   local LICENSE=""
> +
> +   grep "${FILE_WITHOUT_PATH}" "${LIST}" > /dev/null || \
> +   echo "File not in ${LIST}: ${FILE_WITHOUT_PATH}"
> +
> +   local DIR="${SOURCE}`dirname ${FILE_WITHOUT_PATH}`"
> +   while [ "$DIR" != "." ]
> +   do
> +   local MAYBELICENSE="${DIR}/LICENSE*"
> +   if [ -e ${MAYBELICENSE} ]
> +   then
> +   LICENSE=`ls ${MAYBELICENSE}`
> +   break
> +   fi
> +   local MAYBELICENSE="${DIR}/COPY*"
> +   

Re: License files missing on 5-freebsd-12 branch

[Joel Sherrill]

On Thu, Sep 17, 2020 at 4:33 AM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> Hello,
>
> Chris pinged me that I missed to add these patches to the 5-freebsd-12
> branch. It would be good if we would add the license files to the
> release branch too. This will allow users to easily find the correct
> licenses.
>

+1

>
> Best regards
>
> Christian
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS BSP Builder and New/Old Build System

[Joel Sherrill]

On Thu, Sep 17, 2020 at 3:54 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 17/09/2020 01:34, Chris Johns wrote:
>
> > 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?
>

I don't want it to go on forever ever but that is only 6 weeks from today.

But OTOH, I know that rapidly will turn into the end of the calendar year.


> I added a ticket for this:
>
> https://devel.rtems.org/ticket/4081


Thank you.


>
> >
> > 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.
>

Chris and I chatted briefly about this but are there any automated ways to
compare
the executables or objects themselves -- contents so timestamps and paths
won't
matter.

If not, we are only going to be able to do what we have traditionally done
which
is build everything in multiple configurations to ensure no build
breakages.
Test what we can and be willing to go back to the 5 release branch for
comparison
when something is reported broken in the future.

No matter what we do, I think it is safe to assume something will break
somewhere
and someone will not discover it until well after we close the review
period. We
might as well plan for that.


> >
> > 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.
>
> It is critical to run the tests generated by the new build system. To
> run the build alone is not enough. For example, the i386 BSPs were
> completely broken since they used some special stuff in the *.cfg files.
>

My build sweep runs tests for every BSP that has a simulator. There
is only one PC various in rtems-tester. If we need more to account for
variations, that's an issue.

And thinking about it, I only test one PC BSP variant. I should probably
add all of them just to be safer for this transition.

Also, the RISC-V BSPs didn't build unless the dl issue has been resolved
since my last run.


>
> A known issue is the -fdata-sections and -ffunction-sections handling in
> libbsd.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?

[Sebastian Huber]

Hello,

On 15/09/2020 12:58, small...@aliyun.com wrote:
I am developing applications in rtems 5.1. As we know, my application 
and rtems kernel are both in the same address space.
So if my application access an invalid address or encounter other 
fatal errors, I want the kernel not just being hunging, but create a 
core dump file.
This file contains the whole contents of memory and I could use a 
debuger to analyse the file to handle the bug.

The question arise because I do not want always debug rtems in the bsp.


in addition to dumping the current state of the application, you can use 
the event recording to get a bit of the dynamic behaviour before the crash:


https://docs.rtems.org/branches/master/user/tracing/eventrecording.html

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

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

[Sebastian Huber]

Hello Chris and Joel,

On 17/09/2020 01:39, Chris Johns wrote:

Looks good.

Thanks for your patience as we worked through this change. I think the outcome
is solid and reflects the efforts made.
thanks for your detailed review. I think it was worth the trouble. The 
API is now much better compared to the v1 version.

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

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

[Gedare Bloom]

On Thu, Sep 17, 2020 at 10:32 AM Sebastian Huber
 wrote:
>
> Hello Chris and Joel,
>
> On 17/09/2020 01:39, Chris Johns wrote:
> > Looks good.
> >
> > Thanks for your patience as we worked through this change. I think the 
> > outcome
> > is solid and reflects the efforts made.
> thanks for your detailed review. I think it was worth the trouble. The
> API is now much better compared to the v1 version.

Yes great work everyone.

> ___
> 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: [PATCH] gitignore: ignore top-level ini files

[Gedare Bloom]

ping: decision needed--should we git-ignore .ini everywhere, .ini in
top-level, or just the default config.ini in top-level?

On Mon, Sep 14, 2020 at 6:51 PM Chris Johns  wrote:
>
> On 15/9/20 9:52 am, Gedare Bloom wrote:
> > hah, yes. In rtems.git with the new build system it seems the workflow
> > is to create a .ini file in your top-level source directory to control
> > the build. We should not include those ini files in version control I
> > think?
>
> The INI files do not need to be in the top directory, any valid path should 
> do.
>
> I will let Sebastian decide.
>
> > I meant to start a discussion, then I went for a bicycle ride and forgot.
>
> A ride is more important.
>
> Chris
>
> > -Gedare
> >
> > On Mon, Sep 14, 2020 at 3:47 PM Chris Johns  wrote:
> >>
> >> Hi Gedare,
> >>
> >> Which repo is this for? I suspect rtems.git but I thought it best to ask.
> >>
> >> Chris
> >>
> >> On 15/9/20 3:43 am, Gedare Bloom wrote:
> >>> ---
> >>>  .gitignore | 1 +
> >>>  1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/.gitignore b/.gitignore
> >>> index d7ca74b338..8b28b186e1 100644
> >>> --- a/.gitignore
> >>> +++ b/.gitignore
> >>> @@ -4,6 +4,7 @@ autom4te.cache
> >>>  config.h.in
> >>>  configure
> >>>  doc
> >>> +/*.ini
> >>>  .lock*
> >>>  Makefile.in
> >>>  *.pyc
> >>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Gedare Bloom]

On Wed, Sep 16, 2020 at 7:15 PM Chris Johns  wrote:
>
> 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.
>

Nice. *printf also suffer from other security-relevant vulnerabilities
such as the format-string attack:
https://owasp.org/www-community/attacks/Format_string_attack

This means replacing their use with alternatives can be generally more secure.

> 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

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

[Gedare Bloom]

On Thu, Sep 17, 2020 at 1:07 PM Gedare Bloom  wrote:
>
> On Wed, Sep 16, 2020 at 7:15 PM Chris Johns  wrote:
> >
> > 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.
> >
>
> Nice. *printf also suffer from other security-relevant vulnerabilities
> such as the format-string attack:
> https://owasp.org/www-community/attacks/Format_string_attack
>
> This means replacing their use with alternatives can be generally more secure.
>

Also, if the format string is unnecessary, then using *printf is
adding a lot of overhead vs a mem*() call.

> > 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

Re: [PATCH rtems-libbsd 1/3] Add helper script to find licenses.

[Chris Johns]

On 17/9/20 10:51 pm, Joel Sherrill wrote:
> I think I'm ok on all three of these patches but some 
> comments on the shell script. I can see where this is a
> tedious but important check. And it can be improved easily.
> 
> Since this smells like something Chris would poke me f
> or and call a "Joel script" :)

Haha ...

This patch is only for the 5-freesd-12 branch and a script is fine. The script
has made think for the master and 6-freebsd-12 branches libbsd.py should be
taught to handle licenses so these are copied across as part of the import.

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

Re: License files missing on 5-freebsd-12 branch

[Chris Johns]

On 17/9/20 10:57 pm, Joel Sherrill wrote:
> On Thu, Sep 17, 2020 at 4:33 AM Christian Mauderer
>  > wrote:
> 
> Hello,
> 
> Chris pinged me that I missed to add these patches to the 5-freebsd-12
> branch. It would be good if we would add the license files to the
> release branch too. This will allow users to easily find the correct
> licenses.
> 
> 
> +1  

OK to push.

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

Re: RTEMS BSP Builder and New/Old Build System

[Gedare Bloom]

On Thu, Sep 17, 2020 at 7:09 AM Joel Sherrill  wrote:
>
>
>
> On Thu, Sep 17, 2020 at 3:54 AM Sebastian Huber 
>  wrote:
>>
>> On 17/09/2020 01:34, Chris Johns wrote:
>>
>> > 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?
>
>
> I don't want it to go on forever ever but that is only 6 weeks from today.
>
> But OTOH, I know that rapidly will turn into the end of the calendar year.
>
>>
>> I added a ticket for this:
>>
>> https://devel.rtems.org/ticket/4081
>
>
> Thank you.
>
>>
>>
>> >
>> > 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.
>
>
> Chris and I chatted briefly about this but are there any automated ways to 
> compare
> the executables or objects themselves -- contents so timestamps and paths 
> won't
> matter.
>
I think the link order has changed. I used 'size' and saw that .text
differs, and then nm and see some symbols are put in different
locations between the two builds. This leads to some differences due
to padding etc. So it will be hard to make this comparison.


> If not, we are only going to be able to do what we have traditionally done 
> which
> is build everything in multiple configurations to ensure no build breakages.
> Test what we can and be willing to go back to the 5 release branch for 
> comparison
> when something is reported broken in the future.
>
> No matter what we do, I think it is safe to assume something will break 
> somewhere
> and someone will not discover it until well after we close the review period. 
> We
> might as well plan for that.
>
>>
>> >
>> > 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.
>>
>> It is critical to run the tests generated by the new build system. To
>> run the build alone is not enough. For example, the i386 BSPs were
>> completely broken since they used some special stuff in the *.cfg files.
>
>
> My build sweep runs tests for every BSP that has a simulator. There
> is only one PC various in rtems-tester. If we need more to account for
> variations, that's an issue.
>
> And thinking about it, I only test one PC BSP variant. I should probably
> add all of them just to be safer for this transition.
>
> Also, the RISC-V BSPs didn't build unless the dl issue has been resolved
> since my last run.
>
>>
>>
>> A known issue is the -fdata-sections and -ffunction-sections handling in
>> libbsd.
>>
> ___
> 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: Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?

[small...@aliyun.com]

It is a good starting place to handle the crash problem. Especially the records 
could be packed to send to a host computer using TCP/IP.
One of the question for us is there is no network interface. But we have a 
flash disk. So we should modify the send flow using file system instead of 
network.
Moreover, we need expand the recorded data to get more information of the crash.



small...@aliyun.com
 
From: Sebastian Huber
Date: 2020-09-18 00:00
To: small...@aliyun.com; devel
Subject: Re: does rtems 5.1 support create a core dump file when accessing a 
invalid address or other fatal errors?
Hello,
 
On 15/09/2020 12:58, small...@aliyun.com wrote:
> I am developing applications in rtems 5.1. As we know, my application 
> and rtems kernel are both in the same address space.
> So if my application access an invalid address or encounter other 
> fatal errors, I want the kernel not just being hunging, but create a 
> core dump file.
> This file contains the whole contents of memory and I could use a 
> debuger to analyse the file to handle the bug.
> The question arise because I do not want always debug rtems in the bsp.
 
in addition to dumping the current state of the application, you can use 
the event recording to get a bit of the dynamic behaviour before the crash:
 
https://docs.rtems.org/branches/master/user/tracing/eventrecording.html
 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?

[Sebastian Huber]

On 18/09/2020 03:24, small...@aliyun.com wrote:

It is a good starting place to handle the crash problem. Especially 
the records could be packed to send to a host computer using TCP/IP.
One of the question for us is there is no network interface. But we 
have a flash disk. So we should modify the send flow using file system 
instead of network.
Moreover, we need expand the recorded data to get more information of 
the crash.
Saving crash data to a flash disk is normally a bit too complex and 
involves interrupts and DMA. I would save the crash data to a volatile 
memory area which survives a soft reset. After the soft reset, check if 
crash data is available and save it to the disk.

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

Re: [PATCH] gitignore: ignore top-level ini files

[Sebastian Huber]

On 17/09/2020 20:55, Gedare Bloom wrote:


ping: decision needed--should we git-ignore .ini everywhere, .ini in
top-level, or just the default config.ini in top-level?

I tend to ignore the top-level *.ini files.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] score: Improve Scheduler Handler documentation

[Sebastian Huber]

---
 cpukit/include/rtems/score/scheduler.h | 23 -
 cpukit/include/rtems/score/schedulerimpl.h | 29 +-
 2 files changed, 38 insertions(+), 14 deletions(-)

diff --git a/cpukit/include/rtems/score/scheduler.h 
b/cpukit/include/rtems/score/scheduler.h
index 9a6515ba1e..4b9936d756 100644
--- a/cpukit/include/rtems/score/scheduler.h
+++ b/cpukit/include/rtems/score/scheduler.h
@@ -30,12 +30,7 @@ extern "C" {
 struct Per_CPU_Control;
 
 /**
- * @defgroup RTEMSScoreScheduler Scheduler Handler
- *
- * @ingroup RTEMSScore
- *
- * This handler encapsulates functionality related to managing sets of threads
- * that are ready for execution.
+ * @addtogroup RTEMSScoreScheduler
  *
  * @{
  */
@@ -300,22 +295,24 @@ struct _Scheduler_Control {
 };
 
 /**
- * @brief Registered schedulers.
+ * @brief This table contains the configured schedulers.
  *
- * Application provided via .
+ * The table is defined by  through the
+ * #CONFIGURE_SCHEDULER_TABLE_ENTRIES application configuration option.
  *
  * @see _Scheduler_Count.
  */
 extern const Scheduler_Control _Scheduler_Table[];
 
 /**
- * @brief Count of registered schedulers.
+ * @brief This constant contains the count of configured schedulers.
  *
- * Application provided via  on SMP configurations.
+ * In SMP configurations, the constant is defined by  through
+ * the count of entries of the #CONFIGURE_SCHEDULER_TABLE_ENTRIES application
+ * configuration option.
  *
- * It is very important that this is a compile-time constant on uni-processor
- * configurations (in this case RTEMS_SMP is not defined) so that the compiler
- * can optimize the some loops away
+ * In uniprocessor configurations, this is a compile time constant set to one.
+ * This is important so that the compiler can optimize the some loops away
  *
  * @see _Scheduler_Table.
  */
diff --git a/cpukit/include/rtems/score/schedulerimpl.h 
b/cpukit/include/rtems/score/schedulerimpl.h
index e7fbb8b166..f37d9ecdc8 100644
--- a/cpukit/include/rtems/score/schedulerimpl.h
+++ b/cpukit/include/rtems/score/schedulerimpl.h
@@ -34,7 +34,34 @@ extern "C" {
 #endif
 
 /**
- * @addtogroup RTEMSScoreScheduler
+ * @defgroup RTEMSScoreScheduler Scheduler Handler
+ *
+ * @ingroup RTEMSScore
+ *
+ * @brief This handler encapsulates functionality related to managing sets of
+ *   threads that are ready for execution.
+ *
+ * Schedulers are used by the system to manage sets of threads that are ready
+ * for execution.  A scheduler consists of
+ *
+ * * a scheduler algorithm implementation,
+ *
+ * * a scheduler index and an associated name, and
+ *
+ * * a set of processors own by the scheduler (may be empty, but never overlaps
+ *   with a set owned by another scheduler).
+ *
+ * Each thread uses exactly one scheduler as its home scheduler.  Threads may
+ * temporarily use also other scheduler due to actions of locking protocols.
+ *
+ * All properties of a scheduler can be configured and controlled by the user.
+ * Some properties are fixed at link time (defined by application configuration
+ * options), other properties can be changed at runtime through directive
+ * calls.
+ *
+ * The scheduler index, name, and initial processor set are defined for a
+ * particular application by the application configuration.  The schedulers are
+ * registered in the ::_Scheduler_Table which has ::_Scheduler_Count entries.
  *
  * @{
  */
-- 
2.26.2

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

Re: [PATCH rtems-libbsd 1/3] Add helper script to find licenses.

[Christian Mauderer]

On 17/09/2020 23:35, Chris Johns wrote:
> On 17/9/20 10:51 pm, Joel Sherrill wrote:
>> I think I'm ok on all three of these patches but some 
>> comments on the shell script. I can see where this is a
>> tedious but important check. And it can be improved easily.
>>
>> Since this smells like something Chris would poke me f
>> or and call a "Joel script" :)
> 
> Haha ...
> 
> This patch is only for the 5-freesd-12 branch and a script is fine. The script
> has made think for the master and 6-freebsd-12 branches libbsd.py should be
> taught to handle licenses so these are copied across as part of the import.
> 
> Chris
> 

Hello Chris and Joel,

I agree that this script is an ugly one. It has been hacked together
when I needed to import the license files and I didn't wanted to throw
it out of the window because I thought it might could be useful to find
some more missing license files in the future.

Please note that this script is already on master since quite a long
time and that I only cherry-picked the commits for the 5-freebsd-12
branch (and adapted the import patch to import the right version). So
thanks for the suggestions Joel but shouldn't these changes then be an
extra patch? Chris: You mentioned that libbsd.py should be taught to
handle licenses. Do you plan anything into that direction? In that case
touching the script wouldn't be really useful.

Best regards

Christian
-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel