Re: [PATCH v2] Add steps to test Newlib patch.

[Vaibhav Gupta]

Is it okay to push it??

--Vaibhav Gupta

On Fri, Aug 16, 2019 at 8:14 PM Vaibhav Gupta 
wrote:

> Update the checksum to be used for the Newlib patches.
> Earlier it was msd5, but it is depreciated for security
> reasons. Now RSB accepts sha512.
> ---
>  user/rsb/project-sets.rst | 41 +--
>  1 file changed, 35 insertions(+), 6 deletions(-)
>
> diff --git a/user/rsb/project-sets.rst b/user/rsb/project-sets.rst
> index 5ffce26..b01857e 100644
> --- a/user/rsb/project-sets.rst
> +++ b/user/rsb/project-sets.rst
> @@ -261,17 +261,46 @@ in the ``source-builder/config`` template
> configuration files.
>  To test a patch simply copy it to your local ``patches`` directory. The
> RSB
>  will see the patch is present and will not attempt to download it. Once
> you are
>  happy with the patch submit it to the project and a core developer will
> review
> -it and add it to the RTEMS Tools git repository.  For example, to test a
> local
> -patch for newlib, add the following two lines to the .cfg file in
> -``rtems/config/tools/`` that is included by the bset you use:
> +it and add it to the RTEMS Tools git repository.
> +
> +Testing a Newlib Patch
> +~~
> +
> +To test a local patch for newlib, you need to add the following
> +two lines to the ``.cfg`` file in ``rsb/rtems/config/tools/`` that is
> included
> +by the bset you use:
> +
> +.. topic:: Steps:
> +
> +  1. Create patches for the changes you want to test. (Note: For RSB,
> before
> + creating Newlib patch, you must run ``autoreconf -fvi`` in the
> required
> + directory after you make changes to the code. This is not required
> when
> + you create patch to send to ``newlib-devel``. But if you want RSB to
> + address your changes, your patch should also include regenerated
> files.)
> +
> +  2. Calculate ``sha512`` of your patch.
> +
> +  3. Place the patches in ``rsb/rtems/patches`` directory.
> +
> +  4. Open the ``.bset`` file used by your BSP in ``rsb/rtems/config``.
> + For example, for ``rtems5``, ``SPARC``, the file will be
> + ``rsb/rtems/config/5/rtems-sparc.bset``.
> +
> +  5. Inside it you will find the name of ``.cfg`` file for Newlib, used by
> + your BSP.
> + For example, I found ``tools/rtems-gcc-7.4.0-newlib-1d35a003f``.
> +
> +  6. Edit your ``.cfg`` file. In my case it will be,
> + ``rsb/rtems/config/tools/rtems-gcc-7.4.0-newlib-1d35a003f.cfg``. And
> + add the information about your patch as mentioned below.
>
>  .. code-block:: spec
>
> -%patch add newlib file://0001-this-is-a-newlib-patch.patch   <1>
> -%hash md5 0001-this-is-a-newlib-patch.diff
> 77d070878112783292461bd6e7db17fb <2>
> +%patch add newlib -p1 file://0001-Port-ndbm.patch <1>
> +%hash sha512 0001-Port-ndbm.patch
> 7d999ceeea4f3dc82e8e0aadc09d983a7a68b44470da8a3d61ab6fc558fdba6f2c2de3acc2f32c0b0b97fcc9ab799c27e87afe046544a69519881f947e7881d1
> <2>
>
>  .. topic:: Items:
>
>1. The diff file prepended with ``file://`` to tell RSB this is a local
> file.
>
> -  2. The output from md5sum on the diff file.
> +  2. The output from sha512sum on the patch file.
>
> --
> 2.21.0
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2] Add JSON log generation

[Kinsey Moore]

Add log formatter hooks and JSON log formatter to the test infrastructure
for consumption by automated processes or report generators.
---
 tester/rt/test.py | 84 +++
 1 file changed, 84 insertions(+)

diff --git a/tester/rt/test.py b/tester/rt/test.py
index da0a11e..0ed799a 100644
--- a/tester/rt/test.py
+++ b/tester/rt/test.py
@@ -38,6 +38,7 @@ import re
 import sys
 import threading
 import time
+import json
 
 from rtemstoolkit import configuration
 from rtemstoolkit import error
@@ -217,6 +218,69 @@ def killall(tests):
 for test in tests:
 test.kill()
 
+def generate_json_report(args, reports, start_time, end_time, total, 
json_file):
+import sys
+json_log = {}
+json_log['Command Line'] = " ".join(args)
+json_log['Python'] = sys.version.replace('\n', '')
+json_log['test_groups'] = []
+json_log['Host'] = host.label(mode = 'all')
+json_log['summary'] = {}
+json_log['summary']['passed_count'] = reports.passed
+json_log['summary']['failed_count'] = reports.failed
+json_log['summary']['user-input_count'] = reports.user_input
+json_log['summary']['expected-fail_count'] = reports.expected_fail
+json_log['summary']['indeterminate_count'] = reports.indeterminate
+json_log['summary']['benchmark_count'] = reports.benchmark
+json_log['summary']['timeout_count'] = reports.timeouts
+json_log['summary']['invalid_count'] = reports.invalids
+json_log['summary']['wrong-version_count'] = reports.wrong_version
+json_log['summary']['wrong-build_count'] = reports.wrong_build
+json_log['summary']['wrong-tools_count'] = reports.wrong_tools
+json_log['summary']['total_count'] = reports.total
+json_log['summary']['average_test_time'] = str((end_time - start_time) / 
total)
+json_log['summary']['testing_time'] = str(end_time - start_time)
+
+result_types = ['failed', 'user-input', 'expected-fail', 'indeterminate', 
'benchmark', 'timeout', 'invalid', 'wrong-version', 'wrong-build', 
'wrong-tools']
+json_results = {}
+for result_type in result_types:
+json_log['summary'][result_type] = []
+
+# collate results for JSON log
+for name in reports.results:
+result_type = reports.results[name]['result']
+test_parts = name.split("/")
+test_category = test_parts[-2]
+test_name = test_parts[-1]
+if result_type != 'passed':
+json_log['summary'][result_type].append(test_name)
+if test_category not in json_results:
+json_results[test_category] = []
+json_result = {}
+# remove the file extension
+json_result["name"] = test_name.split('.')[0]
+json_result["result"] = result_type
+if result_type == "failed" or result_type == "timeout":
+json_result["output"] = reports.results[name]["output"]
+json_results[test_category].append(json_result)
+
+# convert results to a better format for report generation
+sorted_keys = sorted(json_results.keys())
+for i in range(len(sorted_keys)):
+results_log = {}
+results_log["index"] = i + 1
+results_log["name"] = sorted_keys[i]
+results_log["results"] = json_results[sorted_keys[i]]
+json_log["test_groups"].append(results_log)
+
+# write out JSON log
+with open(json_file, 'w') as outfile:
+json.dump(json_log, outfile, sort_keys=True, indent=4)
+
+report_formatters = {
+'json': generate_json_report
+}
+
 def run(args, command_path = None):
 import sys
 tests = []
@@ -227,6 +291,8 @@ def run(args, command_path = None):
 optargs = { '--rtems-tools':'The path to the RTEMS tools',
 '--rtems-bsp':  'The RTEMS BSP to run the test on',
 '--user-config':'Path to your local user configuration 
INI file',
+'--report-format':  'Formats in which to report test 
results in addition to txt: json',
+'--log':'Log output location',
 '--report-mode':'Reporting modes, failures 
(default),all,none',
 '--list-bsps':  'List the supported BSPs',
 '--debug-trace':'Debug trace based on specific flags 
(console,gdb,output,cov)',
@@ -251,6 +317,20 @@ def run(args, command_path = None):
 else:
 to_addr = 'bu...@rtems.org'
 output = log_capture()
+log_location = opts.find_arg('--log')
+if log_location is not None:
+log_location = log_location[1]
+
+report_formats = opts.find_arg('--report-format')
+if report_formats is not None:
+if len(report_formats) != 2:
+raise error.general('invalid RTEMS report formats option')
+if log_location is None:
+raise error.general('log location not provided for alternate 
output format(s)')
+rep

Re: RTEMS Muilti-I/O lib is missing

[Christian Mauderer]

On 19/08/2019 00:35, Chris Johns wrote:
> On 18/8/19 3:53 am, Joel Sherrill wrote:
>>
>>
>> On Fri, Aug 16, 2019, 8:43 PM Chris Johns > > wrote:
>>
>> On 17/8/19 7:02 am, Joel Sherrill wrote:
>> > FWIW the repo is git clone git://git.rtems.org/multiio.git
>> 
>> >
>> > More below
>> >
>> > On Fri, Aug 16, 2019 at 3:20 PM Wendell Silva > > wrote:
>> >>
>> >> Well, I'm a non-OAR user with at least one customer 100% satisfied 
>> with
>> multi-io lib.
>> >>
>> >> Suppose I'm going to championize it, how do I do to get started?
>> >
>> > I'm glad you are happy with it. I was happy with it on the robotic 
>> project
>> > I did with it.
>>
>> This repo could be added to the RSB as a package. It has been converted 
>> to
>> rtems_waf however it would be good to have the support changed from the 
>> files
>> being in the multiio repo to a submodule referring to the rtems_waf repo.
>>
>> Can the package be built for all BSPs?
>>
>> It would need to be documented. I was considering adding a Packages 
>> chapter to
>> the User Manual and it could be a section under that chapter.
>>
>>
>> Personally, I think there are only two things of long-term value in it. A few
>> shell commands and an interface to access discretes and analogs. 
>>
>> If the interface is just considered a shim layer that an application can
>> implement, then it is independent of any bsp. A system with multiple IO 
>> cards is
>> abstracted through this by the system integrator.
>>
>> Is it worth being independent then?
>>
>> The two drivers in there now are PC-104 so only available to pc386 and 
>> possibly
>> not even compatible with anything you can buy now. One was based on a single
>> chip solution so may be available in later incarnations and for other buses. 
>> No
>> idea though.
>>
>> I don't mind treating it as a small package either. If we want to show how 
>> one
>> should be done, this is small enough to be an example.
> 
> I do not know which is better, a common packages repo or separate repos for 
> each
> package. I am tending to lean to a packages repo where we can collect fragment
> of code like this.
> 
> Chris

Hello Chris,

I had some bad experience with collection repos in the past (private and
at work). They tend to become big and contain a lot of unrelated stuff.
Even if you only want a small part, you always have to clone everything.
And some packages might grow with time and then it's hard to split the
repo up.

I assume the main problem with lot's of repos is that it's slightly
confusing to find anything? If that's the only reason maybe it would be
better to add a prefix or put packages into a sub-folder. Something like
'rtems-packages/multiio' in this case.

What would be the advantages of one collection repo?

PS: Maybe we should have created the maintainer playgrounds more as
'user/', 'user-' or 'private/' or similar.

Best regards

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

[RSB PATCH] Added qemu 4.1.0 as bare target

[Jiri Gaisler]

This patch will add QEMU-4.1.0 as RSB target devel/qemu4. The current 
devel/qemu target will be preserved. Builds and installs fine on ubuntu 18.04 
x86_64. Build scripts might need tweaks for other platforms. A few patches are 
still pulled in, currently hosted on gaisler.org but could be moved to Trac ..? 
Tested with sparc/leon3 bsp, about 10 unexpected fails/timeouts out of 530 
tests.

Passed:    409
Failed:  2
User Input:  6
Expected Fail:   0
Indeterminate:   0
Benchmark:   3
Timeout: 9
Invalid: 2
Wrong Version:  99
Wrong Build: 0
Wrong Tools: 0
--
Total: 530
Average test time: 0:00:00.539311
Testing time : 0:04:45.834903

From 690cbb8023a42d57fea352ff45458dd87ec93bb3 Mon Sep 17 00:00:00 2001
From: Jiri Gaisler 
Date: Mon, 19 Aug 2019 22:12:26 +0200
Subject: [PATCH] Added qemu 4.1.0 as bare target

	* target name is devel/qemu4, old qemu preserved as devel/qemu
---
 bare/config/devel/glib-2.46.2-1.cfg |  26 ++
 bare/config/devel/qemu4-git-1.cfg   |  58 
 bare/config/devel/qemu4.bset|  25 ++
 source-builder/config/qemu-4-1.cfg  | 135 
 4 files changed, 244 insertions(+)
 create mode 100644 bare/config/devel/glib-2.46.2-1.cfg
 create mode 100644 bare/config/devel/qemu4-git-1.cfg
 create mode 100644 bare/config/devel/qemu4.bset
 create mode 100644 source-builder/config/qemu-4-1.cfg

diff --git a/bare/config/devel/glib-2.46.2-1.cfg b/bare/config/devel/glib-2.46.2-1.cfg
new file mode 100644
index 000..cd006f2
--- /dev/null
+++ b/bare/config/devel/glib-2.46.2-1.cfg
@@ -0,0 +1,26 @@
+#
+# GLib
+#
+
+%if %{release} == %{nil}
+%define release 1
+%endif
+
+%include %{_configdir}/base.cfg
+
+%define glib_version_major 2.46
+%define glib_version_minor 2
+%define glib_version   %{glib_version_major}.%{glib_version_minor}
+
+%hash sha256 glib-%{glib_version}.tar.xz 5031722e37036719c1a09163cc6cf7c326e4c4f1f1e074b433c156862bd733db
+
+%patch add glib https://gaisler.org/qemu/glib-2.46.2-werror.patch
+%hash sha256 glib-2.46.2-werror.patch 389c00993f2890edaff6774d0dcfc7fcc99e92795ba913443fb9ec522f44a443
+
+
+#
+# The GLib build instructions. We use 2.x.x Release 1.
+#
+%ifn %{pkgconfig check glib-2.0}
+ %include %{_configdir}/glib-2-1.cfg
+%endif
diff --git a/bare/config/devel/qemu4-git-1.cfg b/bare/config/devel/qemu4-git-1.cfg
new file mode 100644
index 000..ece5d14
--- /dev/null
+++ b/bare/config/devel/qemu4-git-1.cfg
@@ -0,0 +1,58 @@
+#
+# Qemu from git
+#
+
+%if %{release} == %{nil}
+ %define release 1
+%endif
+
+%include %{_configdir}/base.cfg
+
+%include %{_configdir}/bare-config.cfg
+
+#
+# Stable version. Qemu is fast moving.
+#
+%define qemu_version v4.1.0
+
+#
+# Qemu is from GIT unless the RSB has been released.
+#
+# We need to handle the release process
+#
+%if %{rsb_released} && %{!defined without_release_url}
+ %source set qemu %{rtems_release_url}/%{rtems_version}/sources/qemu-git-42d58e7.tar.xz
+%else
+ %source set qemu git://git.qemu-project.org/qemu.git?pull?checkout=%{qemu_version}?submodule=dtc
+%endif
+
+#
+# Patches from Qemu's patchworks site.
+#
+%patch add qemu pw://patchwork.ozlabs.org/patch/406903/raw/Provide-the-missing-LIBUSB_LOG_LEVEL_-for-older-libusb-or-FreeBSD.-Providing-just-the-needed-value-as-a-defined..patch
+%hash sha256 Provide-the-missing-LIBUSB_LOG_LEVEL_-for-older-libusb-or-FreeBSD.-Providing-just-the-needed-value-as-a-defined..patch 40399fcedb44b2c1bfa1a95af482f7f335f42d713967ed2f34980a7a940c3740
+
+#
+# These patches are broken.
+#
+#%patch add qemu pw://patchwork.ozlabs.org/patch/347503/raw/CAN-bus-simple-SJA1000-PCI-card-emulation-for-QEMU.patch
+#%hash md5 CAN-bus-simple-SJA1000-PCI-card-emulation-for-QEMU.patch fbbe8f02867b8b8ee7c23c83cf1e1efa
+#%patch add qemu pw://patchwork.ozlabs.org/patch/347502/raw/CAN-bus-Kvaser-PCI-CAN-S-single-SJA1000-channel-emulation-added.patch
+#%hash md5 CAN-bus-Kvaser-PCI-CAN-S-single-SJA1000-channel-emulation-added.patch 7bd24fa8b55116c9a1301afd7dfa69d3
+
+#
+# Patches to build qemu-4.1.0-sparc with Leon3 support
+#
+%patch add qemu https://gaisler.org/qemu/qemu-4.1.0-leon3.patch
+%hash sha256 qemu-4.1.0-leon3.patch d62ff3418903f1c5eb7f6d727af0400caeb250e23cc120111930601c9ecce02a
+
+#
+# Patch to send halt signal to qemu-system-or32 process when RTEMS terminates
+#
+#%patch add qemu %{rtems_http_git}/rtems-tools/plain/tools/qemu/0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch
+#%hash sha256 0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch 88cd5c9e6e2a6bab23bf049a6f4212ff00083b002b73dbe63b2fe9832717f19e
+
+#
+# The Qemu build instructions. We use 4.x.x Release 1.
+#
+%include %{_configdir}/qemu-4-1.cfg
diff --git a/bare/config/devel/qemu4.bset b/bare/config/devel/qemu4.bset
new file mode 100644
index 000..6badab2
--- /dev/null
+++ b/bare/config/devel/qemu4.bset
@@ -0,0 +1,25 @@
+#
+# Build set for QEMU
+#
+
+%define release 1
+
+#
+# Name of the package.
+#
+package:

[PATCH rtems-tools] leon3-qemu.ini for rtems-test needs custom parameters to work

[Jiri Gaisler]

The standard parameters for leon3-qemu bsp for rtems-test do not work - custom 
ones are needed.

From fb2d18063958d26c016bed2a4880507c9d688d87 Mon Sep 17 00:00:00 2001
From: Jiri Gaisler 
Date: Mon, 19 Aug 2019 22:45:04 +0200
Subject: [PATCH] leon3-qemu.ini for rtems-test needs custom parameters to
 work.

---
 tester/rtems/testing/bsps/leon3-qemu.ini | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tester/rtems/testing/bsps/leon3-qemu.ini b/tester/rtems/testing/bsps/leon3-qemu.ini
index 9e8854c..8760949 100644
--- a/tester/rtems/testing/bsps/leon3-qemu.ini
+++ b/tester/rtems/testing/bsps/leon3-qemu.ini
@@ -35,4 +35,4 @@
 bsp   = leon3-qemu
 arch  = sparc
 tester= %{_rtscripts}/qemu.cfg
-bsp_qemu_opts = %{qemu_opts_base} -M leon3_generic
+bsp_qemu_opts = -no-reboot -nographic -m 64M -M leon3_generic
-- 
2.17.1

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

Re: RTEMS Muilti-I/O lib is missing

[Chris Johns]

On 20/8/19 5:12 am, Christian Mauderer wrote:
> On 19/08/2019 00:35, Chris Johns wrote:
>> On 18/8/19 3:53 am, Joel Sherrill wrote:
>>>
>>>
>>> On Fri, Aug 16, 2019, 8:43 PM Chris Johns >> > wrote:
>>>
>>> On 17/8/19 7:02 am, Joel Sherrill wrote:
>>> > FWIW the repo is git clone git://git.rtems.org/multiio.git
>>> 
>>> >
>>> > More below
>>> >
>>> > On Fri, Aug 16, 2019 at 3:20 PM Wendell Silva >> > wrote:
>>> >>
>>> >> Well, I'm a non-OAR user with at least one customer 100% satisfied 
>>> with
>>> multi-io lib.
>>> >>
>>> >> Suppose I'm going to championize it, how do I do to get started?
>>> >
>>> > I'm glad you are happy with it. I was happy with it on the robotic 
>>> project
>>> > I did with it.
>>>
>>> This repo could be added to the RSB as a package. It has been converted 
>>> to
>>> rtems_waf however it would be good to have the support changed from the 
>>> files
>>> being in the multiio repo to a submodule referring to the rtems_waf 
>>> repo.
>>>
>>> Can the package be built for all BSPs?
>>>
>>> It would need to be documented. I was considering adding a Packages 
>>> chapter to
>>> the User Manual and it could be a section under that chapter.
>>>
>>>
>>> Personally, I think there are only two things of long-term value in it. A 
>>> few
>>> shell commands and an interface to access discretes and analogs. 
>>>
>>> If the interface is just considered a shim layer that an application can
>>> implement, then it is independent of any bsp. A system with multiple IO 
>>> cards is
>>> abstracted through this by the system integrator.
>>>
>>> Is it worth being independent then?
>>>
>>> The two drivers in there now are PC-104 so only available to pc386 and 
>>> possibly
>>> not even compatible with anything you can buy now. One was based on a single
>>> chip solution so may be available in later incarnations and for other 
>>> buses. No
>>> idea though.
>>>
>>> I don't mind treating it as a small package either. If we want to show how 
>>> one
>>> should be done, this is small enough to be an example.
>>
>> I do not know which is better, a common packages repo or separate repos for 
>> each
>> package. I am tending to lean to a packages repo where we can collect 
>> fragment
>> of code like this.
>>
>> Chris
> 
> Hello Chris,
> 
> I had some bad experience with collection repos in the past (private and
> at work). They tend to become big and contain a lot of unrelated stuff.
> Even if you only want a small part, you always have to clone everything.
> And some packages might grow with time and then it's hard to split the
> repo up.

This makes sense and I am concerned this could happen.

> I assume the main problem with lot's of repos is that it's slightly
> confusing to find anything? 

It can but I hope no matter which path is taken we have some documentation that
helps a user.

My main concerns are:

1. Creating a repo, build system and test set up for small pieces of code can be
an obstacle to the code being placed in the open.

2. We need to have a way to test each repo, building and even running tests. The
RSB's 3rd party packages support is a good start and when combined into a
package set for a BSP it should be easy to build with a single command.

3. Testing?

4. The release should capture the repos.

5. Cluttering the cgit repo interface where our main focus repos get lost is a
sea of other repos.

> If that's the only reason maybe it would be
> better to add a prefix or put packages into a sub-folder. Something like
> 'rtems-packages/multiio' in this case.

This could work. I see cgit has a `project-list` option but I would need to
check in detail if it fits doing this.

> What would be the advantages of one collection repo?

Simpler management and shared overheads, ie build system, testing, releasing 
etc.

> PS: Maybe we should have created the maintainer playgrounds more as
> 'user/', 'user-' or 'private/' or similar.

Anyone with commit access has a personal playground now.

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

Re: [PATCH v2] Add JSON log generation

[Chris Johns]

On 20/8/19 2:13 am, Kinsey Moore wrote:
> Add log formatter hooks and JSON log formatter to the test infrastructure
> for consumption by automated processes or report generators.
> ---
>  tester/rt/test.py | 84 
> +++
>  1 file changed, 84 insertions(+)
> 
> diff --git a/tester/rt/test.py b/tester/rt/test.py
> index da0a11e..0ed799a 100644
> --- a/tester/rt/test.py
> +++ b/tester/rt/test.py
> @@ -38,6 +38,7 @@ import re
>  import sys
>  import threading
>  import time
> +import json

The import list is sorted :)

>  from rtemstoolkit import configuration
>  from rtemstoolkit import error
> @@ -217,6 +218,69 @@ def killall(tests):
>  for test in tests:
>  test.kill()
>  
> +def generate_json_report(args, reports, start_time, end_time, total, 
> json_file):
> +import sys
> +json_log = {}
> +json_log['Command Line'] = " ".join(args)
> +json_log['Python'] = sys.version.replace('\n', '')
> +json_log['test_groups'] = []
> +json_log['Host'] = host.label(mode = 'all')
> +json_log['summary'] = {}
> +json_log['summary']['passed_count'] = reports.passed
> +json_log['summary']['failed_count'] = reports.failed
> +json_log['summary']['user-input_count'] = reports.user_input
> +json_log['summary']['expected-fail_count'] = reports.expected_fail
> +json_log['summary']['indeterminate_count'] = reports.indeterminate
> +json_log['summary']['benchmark_count'] = reports.benchmark
> +json_log['summary']['timeout_count'] = reports.timeouts
> +json_log['summary']['invalid_count'] = reports.invalids
> +json_log['summary']['wrong-version_count'] = reports.wrong_version
> +json_log['summary']['wrong-build_count'] = reports.wrong_build
> +json_log['summary']['wrong-tools_count'] = reports.wrong_tools
> +json_log['summary']['total_count'] = reports.total
> +json_log['summary']['average_test_time'] = str((end_time - start_time) / 
> total)
> +json_log['summary']['testing_time'] = str(end_time - start_time)
> +
> +result_types = ['failed', 'user-input', 'expected-fail', 
> 'indeterminate', 'benchmark', 'timeout', 'invalid', 'wrong-version', 
> 'wrong-build', 'wrong-tools']

There is a soft'ish limit that attempts to use 80 columns in the python code.
This one is too long.

> +json_results = {}
> +for result_type in result_types:
> +json_log['summary'][result_type] = []
> +
> +# collate results for JSON log
> +for name in reports.results:
> +result_type = reports.results[name]['result']
> +test_parts = name.split("/")
> +test_category = test_parts[-2]
> +test_name = test_parts[-1]
> +if result_type != 'passed':
> +json_log['summary'][result_type].append(test_name)
> +if test_category not in json_results:
> +json_results[test_category] = []
> +json_result = {}
> +# remove the file extension
> +json_result["name"] = test_name.split('.')[0]
> +json_result["result"] = result_type
> +if result_type == "failed" or result_type == "timeout":
> +json_result["output"] = reports.results[name]["output"]
> +json_results[test_category].append(json_result)
> +
> +# convert results to a better format for report generation
> +sorted_keys = sorted(json_results.keys())
> +for i in range(len(sorted_keys)):
> +results_log = {}
> +results_log["index"] = i + 1
> +results_log["name"] = sorted_keys[i]
> +results_log["results"] = json_results[sorted_keys[i]]
> +json_log["test_groups"].append(results_log)
> +
> +# write out JSON log
> +with open(json_file, 'w') as outfile:
> +json.dump(json_log, outfile, sort_keys=True, indent=4)
> +
> +report_formatters = {
> +'json': generate_json_report
> +}
> +
>  def run(args, command_path = None):
>  import sys
>  tests = []
> @@ -227,6 +291,8 @@ def run(args, command_path = None):
>  optargs = { '--rtems-tools':'The path to the RTEMS tools',
>  '--rtems-bsp':  'The RTEMS BSP to run the test on',
>  '--user-config':'Path to your local user 
> configuration INI file',
> +'--report-format':  'Formats in which to report test 
> results in addition to txt: json',
> +'--log':'Log output location',

Is this option already taken by the options.py module which imports the
rtemstoolkit's options? Would --report work?

>  '--report-mode':'Reporting modes, failures 
> (default),all,none',

I wonder if this is now looking a bit confusing?


Chris

>  '--list-bsps':  'List the supported BSPs',
>  '--debug-trace':'Debug trace based on specific flags 
> (console,gdb,output,cov)',
> @@ -251,6 +317,20 @@ def run(args, command_path = None):
>  else:
>

Re: [RSB PATCH] Added qemu 4.1.0 as bare target

[Chris Johns]

On 20/8/19 6:53 am, Jiri Gaisler wrote:
> This patch will add QEMU-4.1.0 as RSB target devel/qemu4.

Looks good.

> The current devel/qemu target will be preserved. 

Should devel/qemu just point to qemu4? I am OK with this happening.

> Builds and installs fine on ubuntu 18.04 x86_64. Build scripts might need 
> tweaks for other platforms. 

It can be a lot of work depending on how building the support libraries goes. I
think we have reached a point where a newer qemu on platforms that can build it
is more important and the problem hosts such as MinGW and MacOS can be cleaned
up after.

> A few patches are still pulled in, currently hosted on gaisler.org but could 
> be moved to Trac ..? Tested with sparc/leon3 bsp, about 10 unexpected 
> fails/timeouts out of 530 tests.

Does setting a longer timeout change this? I cannot find a suitable way to
adjust the timeout depending on the load.

Chris

> 
> Passed:    409
> Failed:  2
> User Input:  6
> Expected Fail:   0
> Indeterminate:   0
> Benchmark:   3
> Timeout: 9
> Invalid: 2
> Wrong Version:  99
> Wrong Build: 0
> Wrong Tools: 0
> --
> Total: 530
> Average test time: 0:00:00.539311
> Testing time : 0:04:45.834903
> 
> 
> ___
> 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 Muilti-I/O lib is missing

[Christian Mauderer]

On 20/08/2019 00:32, Chris Johns wrote:
> On 20/8/19 5:12 am, Christian Mauderer wrote:
>> On 19/08/2019 00:35, Chris Johns wrote:
>>> On 18/8/19 3:53 am, Joel Sherrill wrote:


 On Fri, Aug 16, 2019, 8:43 PM Chris Johns >>> > wrote:

 On 17/8/19 7:02 am, Joel Sherrill wrote:
 > FWIW the repo is git clone git://git.rtems.org/multiio.git
 
 >
 > More below
 >
 > On Fri, Aug 16, 2019 at 3:20 PM Wendell Silva >>> > wrote:
 >>
 >> Well, I'm a non-OAR user with at least one customer 100% satisfied 
 with
 multi-io lib.
 >>
 >> Suppose I'm going to championize it, how do I do to get started?
 >
 > I'm glad you are happy with it. I was happy with it on the robotic 
 project
 > I did with it.

 This repo could be added to the RSB as a package. It has been 
 converted to
 rtems_waf however it would be good to have the support changed from 
 the files
 being in the multiio repo to a submodule referring to the rtems_waf 
 repo.

 Can the package be built for all BSPs?

 It would need to be documented. I was considering adding a Packages 
 chapter to
 the User Manual and it could be a section under that chapter.


 Personally, I think there are only two things of long-term value in it. A 
 few
 shell commands and an interface to access discretes and analogs. 

 If the interface is just considered a shim layer that an application can
 implement, then it is independent of any bsp. A system with multiple IO 
 cards is
 abstracted through this by the system integrator.

 Is it worth being independent then?

 The two drivers in there now are PC-104 so only available to pc386 and 
 possibly
 not even compatible with anything you can buy now. One was based on a 
 single
 chip solution so may be available in later incarnations and for other 
 buses. No
 idea though.

 I don't mind treating it as a small package either. If we want to show how 
 one
 should be done, this is small enough to be an example.
>>>
>>> I do not know which is better, a common packages repo or separate repos for 
>>> each
>>> package. I am tending to lean to a packages repo where we can collect 
>>> fragment
>>> of code like this.
>>>
>>> Chris
>>
>> Hello Chris,
>>
>> I had some bad experience with collection repos in the past (private and
>> at work). They tend to become big and contain a lot of unrelated stuff.
>> Even if you only want a small part, you always have to clone everything.
>> And some packages might grow with time and then it's hard to split the
>> repo up.
> 
> This makes sense and I am concerned this could happen.
> 
>> I assume the main problem with lot's of repos is that it's slightly
>> confusing to find anything? 
> 
> It can but I hope no matter which path is taken we have some documentation 
> that
> helps a user.
> 
> My main concerns are:
> 
> 1. Creating a repo, build system and test set up for small pieces of code can 
> be
> an obstacle to the code being placed in the open.

Your rtems_waf is a great starting point for reducing that effort (at
least for the build system). But you are right that this can be a big
hurdle.

> 
> 2. We need to have a way to test each repo, building and even running tests. 
> The
> RSB's 3rd party packages support is a good start and when combined into a
> package set for a BSP it should be easy to build with a single command.
> 
> 3. Testing?
> 

2 and 3 are both mainly about testing. I agree that this is really
relevant. But is that really simpler with one repo than with multiple
ones? If one repo contains multiple libraries, they need a way to build
and test too.

> 4. The release should capture the repos.

As long as we don't have scripts to do releases it's right that this is
a huge extra effort for each repo. Good point.

> 
> 5. Cluttering the cgit repo interface where our main focus repos get lost is a
> sea of other repos.

That's why I suggested a prefix or sub-folder.

> 
>> If that's the only reason maybe it would be
>> better to add a prefix or put packages into a sub-folder. Something like
>> 'rtems-packages/multiio' in this case.
> 
> This could work. I see cgit has a `project-list` option but I would need to
> check in detail if it fits doing this.

Wouldn't it just work exactly like the sub-folders for everyone with
commit access?

> 
>> What would be the advantages of one collection repo?
> 
> Simpler management and shared overheads, ie build system, testing, releasing 
> etc.

OK. All valid and good points. Some of them are definitively more
relevant than my point of "the repo could get cluttered". But if one
repo is created, we should be careful to have a look at new stuff and
ma

Re: [RSB PATCH] Added qemu 4.1.0 as bare target

[Jiri Gaisler]

On 8/20/19 12:44 AM, Chris Johns wrote:
> On 20/8/19 6:53 am, Jiri Gaisler wrote:
>> This patch will add QEMU-4.1.0 as RSB target devel/qemu4.
> Looks good.
>
>> The current devel/qemu target will be preserved. 
> Should devel/qemu just point to qemu4? I am OK with this happening.
If preserving the current qemu is not necessary, then I can just update 
devel/qemu to version 4.1.0 and not add devel/qemu4. This probably makes more 
sense  ...
>
>> Builds and installs fine on ubuntu 18.04 x86_64. Build scripts might need 
>> tweaks for other platforms. 
> It can be a lot of work depending on how building the support libraries goes. 
> I
> think we have reached a point where a newer qemu on platforms that can build 
> it
> is more important and the problem hosts such as MinGW and MacOS can be cleaned
> up after.
Agree. On ubuntu, the supporting libraries are not needed at all as they can be 
installed through the standard package manager. But building them inside RSB 
makes it easier for the end-user who does not need to figure out what to 
install (or read the manual .. :-)
>> A few patches are still pulled in, currently hosted on gaisler.org but could 
>> be moved to Trac ..? Tested with sparc/leon3 bsp, about 10 unexpected 
>> fails/timeouts out of 530 tests.
> Does setting a longer timeout change this? I cannot find a suitable way to
> adjust the timeout depending on the load.

Not really, the tests are dead-locked somehow. This is probably because of qemu 
timing behavior. Here is the list of failures:

Failures:
 dl09.exe
 psx12.exe

Timeouts:
 spintrcritical06.exe
 spintrcritical07.exe
 spintrcritical12.exe
 spintrcritical11.exe
 spintrcritical13.exe
 spintrcritical14.exe
 spintrcritical15.exe
 spintrcritical18.exe
 spintrcritical24.exe

It would be great if rtems-test could (optionally) take a timeout value from 
the bsp file, as some targets need a bit longer delay. (e.g. crypt01.exe fails 
on sis/RISC-V due to this).

Jiri.

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