Re: [PATCH 0/3] libbsd: Create some basic buildsets.

[Christian Mauderer]

Am 27.04.2018 um 04:00 schrieb Joel Sherrill:
> 
> 
> On Thu, Apr 26, 2018, 8:29 PM Chris Johns  > wrote:
> 
> On 26/04/2018 19:50, Christian Mauderer wrote:
> >
> > But it would be great if I could already get some first
> > feedback for these patches.
> >
> 
> OK to push.
> 
> 
> +1
> 

Hello Joel and Chris,

thanks for the feedback. Like I said in my initial mail, I'll still need
to remove INET6 from some places for the minimal version. I already
found some places where I missed it. So I'll wait till I have posted
that v2 before I push the patches.

> 
> These are really great changes, it is starting to be a nice solid base.
> 
> Thank you for this work.
> 
> 
> Agreed. 
> 
> Should packet filtering be included in minimal? I doubt many will use that. 

Yes. I described my intention for the minimal version in the comment at
the top of the buildset file:

   #
   # This configuration has the target to provide the smallest possible
libbsd
   # during link time. It should disable everything that can be disabled
without
   # loosing basic functionality. As a target, it should once only
provide the
   # following functions:
   #
   # - basic IPv4 only networking
   # - basic USB support
   # - all device drivers that don't increase the application size
without being
   #   explicitly linked in
   #
   # ATTENTION: This configuration will loose functionality in the
future as soon
   # as it is possible to disable the functionality.
   #

Basically I think that the target version of this minimal buildset will
have about the features of the legacy stack - maybe a little less. But
it will need time to remove more features. So removing PF will have to
wait for another patch.

Best regards

Christian

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

-- 

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

Re: [PATCH 1/2] covoar: Add symbol set reader and ELF data parser to covoar.

[Cillian O'Donnell]

On Fri, 27 Apr 2018, 04:48 Chris Johns,  wrote:

> On 27/04/2018 08:51, Joel Sherrill wrote:
> >
> >// Create the set of desired symbols.
> >SymbolsToAnalyze = new Coverage::DesiredSymbols();
> > -  SymbolsToAnalyze->load( symbolsFile );
> >
> >
> > I am having trouble seeing what happened to the DesiredSymbols class. Is
> > it no longer needed?


It's still being used as before, the decision has just been split from did
you provided the symbols file or are you using symbol_set.cfg file.
DesiredSymbols is definitely still being used. I'm looking on my phone  so
maybe missing something that would be clearer not on a phone.

Just to update, I didn't get time to look at the rsb build yesterday so
it'll have to be tonight. Sorry for the delay, my new job keeps me very
busy during the week, long commutes too.

Did

we change the class from which SymbolsToAnalyze
> > is derived but provide all the same needed interfaces?
> >
> > I'm having trouble seeing how the new class fits in. Help me.
>
> I am adding support to determine the build top from the executable path(s)
> and
> to verify the build path, arch prefix and BSP match for all executables
> passed
> in and then I will load the symbols from the libraries listed in the
> config file
> directly into the desired symbols class. It looks me like these extra
> classes
> are not needed.
>
> 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 0/3] libbsd: Create some basic buildsets.

[Chris Johns]

On 27/04/2018 17:01, Christian Mauderer wrote:
> Basically I think that the target version of this minimal buildset will
> have about the features of the legacy stack - maybe a little less.

This is a really good point and a nice thing to have because it provides a
simplified environment for users switching from the legacy stack.

What happens if we can drive minimal smaller, I am sure some would welcome that?

Is minimal the best name for that entry level functionality?

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

Re: [PATCH 2/2] rtems-tools/../testing: Add configuration files for coverage analysis.

[Cillian O'Donnell]

Yeah the config files are definitely a bit of a pick-a-mix. I only really
made changes in the .ini and symbolset.cfg. The rest is mostly yours I
guess Joel. You probably have the best idea of what to do with it. I think
Chris wants to squash it together, add his changes and make new patches.

On Thu, 26 Apr 2018, 23:55 Joel Sherrill,  wrote:

> This looks like a mixed bag of stuff. The qemu cfg file could be by itself.
>
> Two files (Jiri's email and details on writing an Explanations.txt) could
> go
> in a (currently non-existent) document on running coverage.
>
> The .css file is a support file for the output.
>
> Not sure where the else fall but these seems like a handful of small
> patches
> rather than one larger patch.
>
> --joel
>
> On Wed, Apr 25, 2018 at 3:33 PM, Cillian O'Donnell 
> wrote:
>
>> Co-author: Krzysztof Miesowicz 
>> Co-author: Vijay Kumar Banerjee 
>> ---
>>  tester/rtems/testing/bsps/leon3_qemu.ini   |  52 ++
>>  tester/rtems/testing/coverage.ini  |  49 +
>>  tester/rtems/testing/coverage/Categories.txt   |  19 ++
>>  tester/rtems/testing/coverage/Explanations.txt |  35 
>>  .../coverage/SPARC-Annul-Slot-Explanation.txt  |  56 ++
>>  tester/rtems/testing/coverage/style.css| 197
>> +
>>  tester/rtems/testing/coverage/symbol_sets.cfg  |   3 +
>>  tester/rtems/testing/qemu.cfg  |  14 +-
>>  8 files changed, 424 insertions(+), 1 deletion(-)
>>  create mode 100644 tester/rtems/testing/bsps/leon3_qemu.ini
>>  create mode 100644 tester/rtems/testing/coverage.ini
>>  create mode 100644 tester/rtems/testing/coverage/Categories.txt
>>  create mode 100644 tester/rtems/testing/coverage/Explanations.txt
>>  create mode 100644
>> tester/rtems/testing/coverage/SPARC-Annul-Slot-Explanation.txt
>>  create mode 100644 tester/rtems/testing/coverage/style.css
>>  create mode 100644 tester/rtems/testing/coverage/symbol_sets.cfg
>>
>> diff --git a/tester/rtems/testing/bsps/leon3_qemu.ini
>> b/tester/rtems/testing/bsps/leon3_qemu.ini
>> new file mode 100644
>> index 000..9888008
>> --- /dev/null
>> +++ b/tester/rtems/testing/bsps/leon3_qemu.ini
>> @@ -0,0 +1,52 @@
>> +#
>> +# RTEMS Tools Project (http://www.rtems.org/)
>> +# Copyright 2010-2014 Chris Johns (chr...@rtems.org)
>> +# All rights reserved.
>> +#
>> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>> +#
>> +# Redistribution and use in source and binary forms, with or without
>> +# modification, are permitted provided that the following conditions are
>> met:
>> +#
>> +# 1. Redistributions of source code must retain the above copyright
>> notice,
>> +# this list of conditions and the following disclaimer.
>> +#
>> +# 2. Redistributions in binary form must reproduce the above copyright
>> notice,
>> +# this list of conditions and the following disclaimer in the
>> documentation
>> +# and/or other materials provided with the distribution.
>> +#
>> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> "AS IS"
>> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
>> THE
>> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>> PURPOSE
>> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS
>> BE
>> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
>> +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
>> BUSINESS
>> +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
>> +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
>> +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
>> THE
>> +# POSSIBILITY OF SUCH DAMAGE.
>> +#
>> +
>> +#
>> +# The Leon 3 QEMU BSP
>> +#
>> +[global]
>> +coverage_supported   = 1
>> +bsp  = leon3_qemu
>> +[leon3_qemu]
>> +bsp   = leon3_qemu
>> +arch  = sparc
>> +tester= %{_rtscripts}/qemu.cfg
>> +bsp_qemu_opts = %{qemu_opts_base} -M leon3_generic
>> +
>> +
>> +[coverage]
>> +format   = QEMU
>> +target   = sparc-rtems5
>> +explanations = %{_rtscripts}/coverage/Explanations.txt
>> +coverage_extension   = .cov
>> +gcnos_file   = %{_rtscripts}/coverage/rtems.gcnos
>> +executable_extension = exe
>> +project_name = RTEMS-5
>> +report_format= html
>> diff --git a/tester/rtems/testing/coverage.ini
>> b/tester/rtems/testing/coverage.ini
>> new file mode 100644
>> index 000..c1eef2e
>> --- /dev/null
>> +++ b/tester/rtems/testing/coverage.ini
>> @@ -0,0 +1,49 @@
>> +#
>> +# RTEMS Tools Project (http://www.rtems.org/)
>> +# Copyright 2010-2014 Chris Johns (chr...@rtems.org)
>> +# All rights reserved.
>> +#
>> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>> +#
>> +# Redistribution and use in source and binary forms, with or without
>> +#

Re: [PATCH 1/2] covoar: Add symbol set reader and ELF data parser to covoar.

[Chris Johns]

On 27/04/2018 17:21, Cillian O'Donnell wrote:
> On Fri, 27 Apr 2018, 04:48 Chris Johns,  > wrote:
> 
> On 27/04/2018 08:51, Joel Sherrill wrote:
> >
> >        // Create the set of desired symbols.
> >        SymbolsToAnalyze = new Coverage::DesiredSymbols();
> >     -  SymbolsToAnalyze->load( symbolsFile );
> >
> >
> > I am having trouble seeing what happened to the DesiredSymbols class. Is
> > it no longer needed?
> 
> 
> It's still being used as before, the decision has just been split from did you
> provided the symbols file or are you using symbol_set.cfg file. DesiredSymbols
> is definitely still being used. I'm looking on my phone  so maybe missing
> something that would be clearer not on a phone.

I have renamed a few files, for example ..

 tester/rtems/testing/coverage/symbol_sets.cfg ->
tester/rtems/testing/coverage/score-symbols.ini

and that file now contains:

[symbol-sets]
sets = score

[score]
libraries=@BUILD-PREFIX@/c/@BSP@/cpukit/score/libscore.a

I have added code to get the build path, BUILD-PREFIX and BSP from the
executable's path and check each executable is from the same build tree.

I may check these against the RLD's automatically detected values after loading
the libraries.

I have add the code to load the libraries and the required symbols.

This means some of the code to read the sets and then load the libraries and
create a symbol file can be removed.

I have not attempted to build to the code and will do this over the weekend or
next week.

> Just to update, I didn't get time to look at the rsb build yesterday so it'll
> have to be tonight. Sorry for the delay, my new job keeps me very busy during
> the week, long commutes too.

No problem, when you can.

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

Re: [PATCH 2/2] rtems-tools/../testing: Add configuration files for coverage analysis.

[Chris Johns]

On 27/04/2018 17:28, Cillian O'Donnell wrote:
> Yeah the config files are definitely a bit of a pick-a-mix. I only really made
> changes in the .ini and symbolset.cfg. The rest is mostly yours I guess Joel.
> You probably have the best idea of what to do with it. I think Chris wants to
> squash it together, add his changes and make new patches.

I have resolved those issues and the coverage config logic.

Once I have these changes done I will generate a single patch to post for
review. It will be different in parts so I hope that is OK.

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

Re: [PATCH 0/3] libbsd: Create some basic buildsets.

[Christian Mauderer]

Am 27.04.2018 um 09:24 schrieb Chris Johns:
> On 27/04/2018 17:01, Christian Mauderer wrote:
>> Basically I think that the target version of this minimal buildset will
>> have about the features of the legacy stack - maybe a little less.
> 
> This is a really good point and a nice thing to have because it provides a
> simplified environment for users switching from the legacy stack.
> 
> What happens if we can drive minimal smaller, I am sure some would welcome 
> that?
> 
> Is minimal the best name for that entry level functionality?
> 
> Chris
> 

Hello Chris,

basically I thought that we should have two versions with the purpose to
try whether everything can be compiled with or without as much features
as possible. That "minimal" provides the smallest footprint that is
possible is more or less a side effect. The third version ("default")
should be the one that matches most use cases.

If we find out in the future that there are a lot of use cases that need
some other configuration (for example something between "minimal" and
"default") we just add a forth version to the officially supported ones.
But I wanted to start with only few versions. It's the same as for the
BSPs: Each additional one adds extra testing effort.

I'm not sure whether the names are the best ones. They are only the ones
that I first came up with. Please feel free to suggest better ones.

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

Re: [PATCH 1/2] covoar: Add symbol set reader and ELF data parser to covoar.

[Cillian O'Donnell]

On Fri, 27 Apr 2018, 08:32 Chris Johns,  wrote:

> On 27/04/2018 17:21, Cillian O'Donnell wrote:
> > On Fri, 27 Apr 2018, 04:48 Chris Johns,  > > wrote:
> >
> > On 27/04/2018 08:51, Joel Sherrill wrote:
> > >
> > >// Create the set of desired symbols.
> > >SymbolsToAnalyze = new Coverage::DesiredSymbols();
> > > -  SymbolsToAnalyze->load( symbolsFile );
> > >
> > >
> > > I am having trouble seeing what happened to the DesiredSymbols
> class. Is
> > > it no longer needed?
> >
> >
> > It's still being used as before, the decision has just been split from
> did you
> > provided the symbols file or are you using symbol_set.cfg file.
> DesiredSymbols
> > is definitely still being used. I'm looking on my phone  so maybe missing
> > something that would be clearer not on a phone.
>
> I have renamed a few files, for example ..
>
>  tester/rtems/testing/coverage/symbol_sets.cfg ->
> tester/rtems/testing/coverage/score-symbols.ini
>
> and that file now contains:
>
> [symbol-sets]
> sets = score
>
> [score]
> libraries=@BUILD-PREFIX@/c/@BSP@/cpukit/score/libscore.a
>

Fantastic, that solves the build path problem. Thanks.

>
> I have added code to get the build path, BUILD-PREFIX and BSP from the
> executable's path and check each executable is from the same build tree.
>
> I may check these against the RLD's automatically detected values after
> loading
> the libraries.
>
> I have add the code to load the libraries and the required symbols.
>
> This means some of the code to read the sets and then load the libraries
> and
> create a symbol file can be removed.
>

Ah ok, yes I see.

>
> I have not attempted to build to the code and will do this over the
> weekend or
> next week.
>
> > Just to update, I didn't get time to look at the rsb build yesterday so
> it'll
> > have to be tonight. Sorry for the delay, my new job keeps me very busy
> during
> > the week, long commutes too.
>
> No problem, when you can.
>
> Thank you.
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2 1/4] waf: Fix usage of build-include from config.

[Christian Mauderer]

---
 waf_libbsd.py | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/waf_libbsd.py b/waf_libbsd.py
index 54a60a78..589d21a2 100644
--- a/waf_libbsd.py
+++ b/waf_libbsd.py
@@ -185,6 +185,7 @@ class Builder(builder.ModuleManager):
 # Include paths
 #
 includes = []
+buildinclude = 'build-include'
 if 'cpu-include-paths' in config:
 cpu = bld.get_env()['RTEMS_ARCH']
 if cpu == "i386":
@@ -194,7 +195,10 @@ class Builder(builder.ModuleManager):
 if 'include-paths' in config:
 includes += config['include-paths']
 if 'build-include-path' in config:
-includes += config['build-include-path']
+buildinclude = config['build-include-path']
+if not isinstance(buildinclude, basestring):
+buildinclude = buildinclude[0]
+includes += [buildinclude]
 
 #
 # Collect the libbsd uses
@@ -242,7 +246,7 @@ class Builder(builder.ModuleManager):
 hp for hp in config['header-paths'] if hp[2] != '' and not 
hp[0].endswith(hp[2])
 ]
 for headers in header_build_copy_paths:
-target = os.path.join("build-include", headers[2])
+target = os.path.join(buildinclude, headers[2])
 start_dir = bld.path.find_dir(headers[0])
 for header in start_dir.ant_glob(headers[1]):
 relsourcepath = header.path_from(start_dir)
-- 
2.13.6

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

[PATCH v2 3/4] tcpdump: Remove unused file.

[Christian Mauderer]

---
 freebsd/contrib/tcpdump/print-sunrpc.c | 182 -
 1 file changed, 182 deletions(-)
 delete mode 100644 freebsd/contrib/tcpdump/print-sunrpc.c

diff --git a/freebsd/contrib/tcpdump/print-sunrpc.c 
b/freebsd/contrib/tcpdump/print-sunrpc.c
deleted file mode 100644
index 85b1461a..
--- a/freebsd/contrib/tcpdump/print-sunrpc.c
+++ /dev/null
@@ -1,182 +0,0 @@
-#include 
-#ifdef __rtems__
-#include 
-#include "rtems-bsd-tcpdump-namespace.h"
-#endif /* __rtems__ */
-/*
- * Copyright (c) 1992, 1993, 1994, 1995, 1996
- * 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: (1) source code distributions
- * retain the above copyright notice and this paragraph in its entirety, (2)
- * distributions including binary code include the above copyright notice and
- * this paragraph in its entirety in the documentation or other materials
- * provided with the distribution, and (3) all advertising materials mentioning
- * features or use of this software display the following acknowledgement:
- * ``This product includes software developed by the University of California,
- * Lawrence Berkeley Laboratory and its contributors.'' 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 ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
- * WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
- *
- * $FreeBSD$
- */
-
-#ifndef lint
-static const char rcsid[] _U_ =
-"@(#) $Header: /tcpdump/master/tcpdump/print-sunrpc.c,v 1.47 2005-04-27 
21:43:48 guy Exp $ (LBL)";
-#endif
-
-#ifdef HAVE_CONFIG_H
-#include "config.h"
-#endif
-
-/*
- * At least on HP-UX:
- *
- * 1) getrpcbynumber() is declared in , not any of the RPC
- *header files
- *
- * and
- *
- * 2) if _XOPEN_SOURCE_EXTENDED is defined,  doesn't declare
- *it
- *
- * so we undefine it.
- */
-#undef _XOPEN_SOURCE_EXTENDED
-
-#include 
-
-#if defined(HAVE_GETRPCBYNUMBER) && defined(HAVE_RPC_RPC_H)
-#include 
-#ifdef HAVE_RPC_RPCENT_H
-#include 
-#endif /* HAVE_RPC_RPCENT_H */
-#endif /* defined(HAVE_GETRPCBYNUMBER) && defined(HAVE_RPC_RPC_H) */
-
-#include 
-#include 
-
-#include "interface.h"
-#include "addrtoname.h"
-#include "extract.h"
-
-#include "ip.h"
-#ifdef INET6
-#include "ip6.h"
-#endif
-
-#include "rpc_auth.h"
-#include "rpc_msg.h"
-#include "pmap_prot.h"
-
-static struct tok proc2str[] = {
-   { SUNRPC_PMAPPROC_NULL, "null" },
-   { SUNRPC_PMAPPROC_SET,  "set" },
-   { SUNRPC_PMAPPROC_UNSET,"unset" },
-   { SUNRPC_PMAPPROC_GETPORT,  "getport" },
-   { SUNRPC_PMAPPROC_DUMP, "dump" },
-   { SUNRPC_PMAPPROC_CALLIT,   "call" },
-   { 0,NULL }
-};
-
-/* Forwards */
-static char *progstr(u_int32_t);
-
-void
-sunrpcrequest_print(register const u_char *bp, register u_int length,
-   register const u_char *bp2)
-{
-   register const struct sunrpc_msg *rp;
-   register const struct ip *ip;
-#ifdef INET6
-   register const struct ip6_hdr *ip6;
-#endif
-   u_int32_t x;
-   char srcid[20], dstid[20];  /*fits 32bit*/
-
-   rp = (struct sunrpc_msg *)bp;
-
-   if (!nflag) {
-   snprintf(srcid, sizeof(srcid), "0x%x",
-   EXTRACT_32BITS(&rp->rm_xid));
-   strlcpy(dstid, "sunrpc", sizeof(dstid));
-   } else {
-   snprintf(srcid, sizeof(srcid), "0x%x",
-   EXTRACT_32BITS(&rp->rm_xid));
-   snprintf(dstid, sizeof(dstid), "0x%x", SUNRPC_PMAPPORT);
-   }
-
-   switch (IP_V((struct ip *)bp2)) {
-   case 4:
-   ip = (struct ip *)bp2;
-   printf("%s.%s > %s.%s: %d",
-   ipaddr_string(&ip->ip_src), srcid,
-   ipaddr_string(&ip->ip_dst), dstid, length);
-   break;
-#ifdef INET6
-   case 6:
-   ip6 = (struct ip6_hdr *)bp2;
-   printf("%s.%s > %s.%s: %d",
-   ip6addr_string(&ip6->ip6_src), srcid,
-   ip6addr_string(&ip6->ip6_dst), dstid, length);
-   break;
-#endif
-   default:
-   printf("%s.%s > %s.%s: %d", "?", srcid, "?", dstid, length);
-   break;
-   }
-
-   printf(" %s", tok2str(proc2str, " proc #%u",
-   EXTRACT_32BITS(&rp->rm_call.cb_proc)));
-   x = EXTRACT_32BITS(&rp->rm_call.cb_rpcvers);
-   if (x != 2)
-   printf(" [rpcver %u]", x);
-
-   switch (EXTRACT_32BITS(&rp->rm_call.cb_proc)) {
-
-   case SUNRPC_PMAPPROC_SET:
-   case SUNRPC_PMAPPROC_UNSET:
-   case SUNRPC_PMAPPROC_GETPORT:
-   case

[PATCH v2 0/4] libbsd: Create some basic buildsets.

[Christian Mauderer]

An updated patch set for this toppic: The last patch should now cleanly
disable all INET6 in the minimal configuration. That reduced the code
size of the media01 test in the minimal configuration for another 60k:

   > arm-rtems5-size build/arm-rtems5-atsamv-*/media01.exe
   textdata bss dec hex filename
   2430820  211448 30922152335644202002704 
build/arm-rtems5-atsamv-default/media01.exe
   3068860  211816 3028375233564428200270c 
build/arm-rtems5-atsamv-everything/media01.exe
   2225180  199324 311398803356438420026e0 
build/arm-rtems5-atsamv-minimal/media01.exe

If no one objects, I would like to push these patches somewhere arround
Wednesday next week and close ticket #3351 (as soon as I found out how
to change the title so that it reflects that the compiler flags are now
not based on the build sets).

Best regards

Christian

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

[PATCH v2 2/4] waf: Generate a rtems/bsd/modules.h

[Christian Mauderer]

The generated file defines a RTEMS_BSD_MODULE_xxx for each enabled
module. That is usefull for conditional compilation depending on whether
a module is build not.

Update #3351.
---
 waf_libbsd.py | 32 
 1 file changed, 32 insertions(+)

diff --git a/waf_libbsd.py b/waf_libbsd.py
index 589d21a2..e19e10e3 100644
--- a/waf_libbsd.py
+++ b/waf_libbsd.py
@@ -37,6 +37,7 @@ from __future__ import print_function
 import os
 import sys
 import tempfile
+import re
 
 import builder
 
@@ -155,6 +156,8 @@ class Builder(builder.ModuleManager):
 # Localize the config.
 #
 config = self.getConfiguration()
+module_header_path = "rtems/bsd"
+module_header_name = "modules.h"
 
 #
 #
@@ -257,6 +260,30 @@ class Builder(builder.ModuleManager):
 is_copy = True)
 
 #
+# Generate a header that contains information about enabled modules
+#
+def rtems_libbsd_modules_h_gen(self):
+output = ""
+output += '/*\n'
+output += ' * This file contains a list of modules that have 
been\n'
+output += ' * enabled during libbsd build. It is a generated 
file\n'
+output += ' * DO NOT EDIT MANUALLY.\n'
+output += ' */'
+output += '\n'
+output += '#ifndef RTEMS_BSD_MODULES_H\n'
+for mod in config['modules-enabled']:
+modname = re.sub("[^A-Za-z0-9]", "_", mod.upper())
+output += '#define RTEMS_BSD_MODULE_{} 1\n'.format(modname)
+output += '#endif /* RTEMS_BSD_MODULES_H */\n'
+self.outputs[0].write(output)
+modules_h_file_with_path = os.path.join(buildinclude,
+module_header_path,
+module_header_name)
+bld(rule = rtems_libbsd_modules_h_gen,
+target = modules_h_file_with_path,
+before = ['c', 'cxx'])
+
+#
 # Add the specific rule based builders
 #
 
@@ -457,6 +484,11 @@ class Builder(builder.ModuleManager):
   cwd = start_dir,
   relative_trick = True)
 
+bld.install_files(os.path.join("${PREFIX}", arch_inc_path,
+   module_header_path),
+  modules_h_file_with_path,
+  cwd = bld.path)
+
 #
 # Tests
 #
-- 
2.13.6

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

[PATCH v2 4/4] buildset: Add minimal and everything config.

[Christian Mauderer]

This adds two new buildset configurations: One that leaves out as much
features as possible and one that enables all features. For the default
configuration WiFi support is now disabled.

To disable IPv6 for the minimal configuration, all -DINET6 are
eliminated in libbsd.py. They are now replaced by a #ifdef that checks
for RTEMS_BSD_MODULE_NETINET6 instead.

Update #3351.
---
 buildset/default.ini   | 16 ++--
 buildset/everything.ini| 15 +++
 buildset/minimal.ini   | 22 ++
 buildset/sample.ini| 10 --
 dhcpcd/config.h|  1 +
 dhcpcd/dhcp6.c |  5 +
 dhcpcd/ipv6.c  |  5 +
 dhcpcd/ipv6.h  |  3 +++
 dhcpcd/ipv6nd.c|  5 +
 dhcpcd/platform.h  |  3 +++
 freebsd/contrib/libpcap/config.h   |  4 
 freebsd/lib/libc/net/getaddrinfo.c |  3 +++
 freebsd/lib/libc/net/getnameinfo.c |  3 +++
 freebsd/lib/libc/net/name6.c   |  3 +++
 freebsd/lib/libc/net/rcmd.c|  3 +++
 freebsd/lib/libc/rpc/bindresvport.c|  3 +++
 freebsd/lib/libc/rpc/clnt_bcast.c  |  3 +++
 freebsd/lib/libc/rpc/rpc_generic.c |  3 +++
 freebsd/lib/libc/rpc/rpcb_clnt.c   |  4 +++-
 freebsd/sbin/ifconfig/ifconfig.c   |  5 +
 freebsd/sbin/pfctl/pf_print_state.c|  1 +
 freebsd/sbin/ping6/ping6.c |  5 +
 freebsd/sbin/route/route.c |  3 +++
 freebsd/usr.bin/netstat/if.c   |  3 +++
 freebsd/usr.bin/netstat/inet.c |  3 +++
 freebsd/usr.bin/netstat/inet6.c|  3 +++
 freebsd/usr.bin/netstat/mroute6.c  |  3 +++
 freebsd/usr.bin/netstat/netstat.h  |  3 +++
 freebsd/usr.sbin/tcpdump/tcpdump/config.h  |  7 +++
 libbsd.py  | 11 +--
 libbsd.txt | 17 ++---
 rtemsbsd/include/rtems/bsd/local/opt_inet6.h   |  5 -
 testsuite/commands01/test_main.c   | 15 +++
 .../include/rtems/bsd/test/default-network-init.h  | 19 ---
 testsuite/media01/test_main.c  | 13 ++---
 35 files changed, 197 insertions(+), 33 deletions(-)
 create mode 100644 buildset/everything.ini
 create mode 100644 buildset/minimal.ini
 delete mode 100644 buildset/sample.ini
 create mode 100644 freebsd/contrib/libpcap/config.h

diff --git a/buildset/default.ini b/buildset/default.ini
index e58ea99f..a5cbdf9c 100644
--- a/buildset/default.ini
+++ b/buildset/default.ini
@@ -1,5 +1,9 @@
 #
-# Default configuration.
+# Default configuration. Contains most features except for some big or slow 
ones
+# like WiFi or IPSec.
+#
+# At all developers: Please allways add all modules to this file and mark them
+# as explicitly "off" if they are not used.
 #
 
 [general]
@@ -30,8 +34,8 @@ dev_usb_net = on
 dev_usb_quirk = on
 dev_usb_serial = on
 dev_usb_storage = on
-dev_usb_wlan = on
-dev_wlan_rtwn = on
+dev_usb_wlan = off
+dev_wlan_rtwn = off
 dhcpcd = on
 dpaa = on
 evdev = on
@@ -43,7 +47,7 @@ mghttpd = on
 mmc = on
 mmc_ti = on
 net = on
-net80211 = on
+net80211 = off
 netinet = on
 netinet6 = on
 opencrypto = on
@@ -53,6 +57,6 @@ rtems = on
 tests = on
 tty = on
 user_space = on
-user_space_wlanstats = on
+user_space_wlanstats = off
 usr_sbin_tcpdump = on
-usr_sbin_wpa_supplicant = on
+usr_sbin_wpa_supplicant = off
diff --git a/buildset/everything.ini b/buildset/everything.ini
new file mode 100644
index ..0d9cc5fb
--- /dev/null
+++ b/buildset/everything.ini
@@ -0,0 +1,15 @@
+#
+# This configuration has the target to provide all features of libbsd even the
+# big and slow ones.
+#
+
+[general]
+name = everything
+extends = default.ini
+
+[modules]
+dev_usb_wlan = on
+dev_wlan_rtwn = on
+net80211 = on
+user_space_wlanstats = on
+usr_sbin_wpa_supplicant = on
diff --git a/buildset/minimal.ini b/buildset/minimal.ini
new file mode 100644
index ..c5ad8214
--- /dev/null
+++ b/buildset/minimal.ini
@@ -0,0 +1,22 @@
+#
+# This configuration has the target to provide the smallest possible libbsd
+# during link time. It should disable everything that can be disabled without
+# loosing basic functionality. As a target, it should once only provide the
+# following functions:
+#
+# - basic IPv4 only networking
+# - basic USB support
+# - all device drivers that don't increase the application size without being
+#   explicitly linked in
+#
+# ATTENTION: This configuration will loose functionality in the future as soon
+#

Re: odd waf error from examples-v2

[Joel Sherrill]

OK .. the waf in my git clone is OK but the copy of waf-2.0.7 I downloaded
and dropped in the top directory doesn't work:

[joel@rtbf64c examples-v2]$ ./waf distclean
Traceback (most recent call last):
  File "./waf", line 164, in 
from waflib import Scripting
ImportError: No module named waflib
[joel@rtbf64c examples-v2]$ ~/waf/waf/waf distclean
'distclean' finished successfully (0.001s)

Any thoughts?

On Thu, Apr 26, 2018 at 8:57 PM, Joel Sherrill  wrote:

>
>
> On Thu, Apr 26, 2018, 8:23 PM Chris Johns  wrote:
>
>> On 26/04/2018 23:42, Joel Sherrill wrote:
>> > Hi
>> >
>> > I am getting this on rtbf64c which is running this version of CentOS:
>> >
>> > CentOS Linux release 7.4.1708 (Core)
>> >
>> > It doesn't occur on my VM which has the same version:
>> >
>> > $ cat /etc/redhat-release
>> > CentOS Linux release 7.4.1708 (Core)
>> >
>> > Any ideas?
>>
>> Please try the latest version of waf.
>>
>
> I tried the latest release from waf.io and it worked for me on a single
> BSP. I left a build of all going overnight and will review results as soon
> as I can.
>
>>
>> If successful please update the version in the repo.
>>
>
> Ok. Will push in the morning.
>
> I have typo fixes for incorrect BSP names in the tester. I will push them
> if ok. That will leave epiphany network issue.
>
>>
>> Thank you.
>> Chris
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/2] *** Covoar Outstanding Changes ***

[Cillian O'Donnell]

On 26 April 2018 at 08:50, Chris Johns  wrote:

> On 26/04/2018 16:11, Cillian O'Donnell wrote:
> > On Thu, 26 Apr 2018, 03:27 Chris Johns,  > > wrote:
> >
> >> Also, are there any RSB changes outstanding to build a suitable QEMU?
> >
> > Oh yes, I still have that build. I'll take a look at it tonight, see if
> it's
> > still ok.
> >
>
> Thank you. I can then look at testing those changes as well.
>

Just ran the rsb build there, it finishes with no error messages and
appears to be successful but no tools end up in the prefix location.
Nothing obviously wrong in the log. Have you seen that before? Same thing
with the qemu that's currently in the rsb. Has anyone tried to build qemu
with the rsb recently?

...
installing:
couverture-qemu-e9299f7591c8ecf3389922f4e7672b6bc5deae71-x86_64-linux-gnu-1
-> /home/cpod/development/5
cleaning: gettext-0.18.3.1-x86_64-linux-gnu-1
cleaning: libffi-3.0.13-x86_64-linux-gnu-1
cleaning: pixman-0.32.4-x86_64-linux-gnu-1
cleaning: glib-2.39.3-x86_64-linux-gnu-1
cleaning: dtc-1.4.1-x86_64-linux-gnu-1
cleaning:
couverture-qemu-e9299f7591c8ecf3389922f4e7672b6bc5deae71-x86_64-linux-gnu-1
Build Set: Time 0:06:57.495306


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

Re: [PATCH 0/2] *** Covoar Outstanding Changes ***

[Chris Johns]

On 28/4/18 7:41 am, Cillian O'Donnell wrote:
> 
> 
> On 26 April 2018 at 08:50, Chris Johns  > wrote:
> 
> On 26/04/2018 16:11, Cillian O'Donnell wrote:
> > On Thu, 26 Apr 2018, 03:27 Chris Johns,  
> > >> wrote:
> > 
> >> Also, are there any RSB changes outstanding to build a suitable QEMU?
> > 
> > Oh yes, I still have that build. I'll take a look at it tonight, see if 
> it's
> > still ok.
> > 
> 
> Thank you. I can then look at testing those changes as well.
> 
> Just ran the rsb build there, it finishes with no error messages and appears 
> to
> be successful but no tools end up in the prefix location. Nothing obviously
> wrong in the log. Have you seen that before? Same thing with the qemu that's
> currently in the rsb. Has anyone tried to build qemu with the rsb recently? 

Yes, I happened to build it yesterday on FreeBSD:

$ ../source-builder/sb-set-builder --prefix=/opt/work/rtems/qemu \
--log=qemu.txt devel/qemu
$ ls /opt/work/rtems/qemu/bin
autopoint   qemu-system-i386
envsubstqemu-system-lm32
gettext qemu-system-m68k
gettext.sh  qemu-system-microblaze
gettextize  qemu-system-microblazeel
msgattrib   qemu-system-mips
msgcat  qemu-system-mips64
msgcmp  qemu-system-mips64el
msgcomm qemu-system-mipsel
msgconv qemu-system-moxie
msgen   qemu-system-or32
msgexec qemu-system-ppc
msgfilter   qemu-system-ppc64
msgfmt  qemu-system-ppcemb
msggrep qemu-system-s390x
msginit qemu-system-sh4
msgmergeqemu-system-sh4eb
msgunfmtqemu-system-sparc
msguniq qemu-system-sparc64
ngettextqemu-system-tricore
qemu-ga qemu-system-unicore32
qemu-i386   qemu-system-x86_64
qemu-sparc  qemu-system-xtensa
qemu-sparc64qemu-system-xtensaeb
qemu-system-aarch64 qemu-x86_64
qemu-system-alpha   recode-sr-latin
qemu-system-arm xgettext
qemu-system-cris

Is there a patch I download and test?

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

Re: odd waf error from examples-v2

[Chris Johns]

On 27/4/18 11:36 pm, Joel Sherrill wrote:
> OK .. the waf in my git clone is OK

Clone of which repo?

> but the copy of waf-2.0.7 I downloaded
> and dropped in the top directory

Such as:

 cp ~/Downloads/waf-2.0.7 waf

?

Did you have to chmod the copied file?

> doesn't work:
> 
> [joel@rtbf64c examples-v2]$ ./waf distclean
> Traceback (most recent call last):
>   File "./waf", line 164, in 
>     from waflib import Scripting
> ImportError: No module named waflib
> [joel@rtbf64c examples-v2]$ ~/waf/waf/waf distclean
> 'distclean' finished successfully (0.001s)
> 
> Any thoughts?
> 

I think there is something wrong in your setup. I have no idea what this is from
this information.

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