Re: [PATCH 4/6] testsuite: Add expected-fail to psim

[Gedare Bloom]

On Wed, May 6, 2020 at 5:27 PM Joel Sherrill  wrote:
>
>
>
> On Wed, May 6, 2020 at 6:12 AM Chris Johns  wrote:
>>
>>
>> > On 6 May 2020, at 8:15 pm, Sebastian Huber 
>> >  wrote:
>> >
>> > On 06/05/2020 12:00, Chris Johns wrote:
>> >
>> >>> On 6/5/20 7:35 pm, Sebastian Huber wrote:
>>  On 06/05/2020 10:41, chr...@rtems.org wrote:
>> >>>
>>  From: Chris Johns
>> 
>>  Updates #2962
>>  ---
>>    bsps/powerpc/psim/config/psim-testsuite.tcfg | 22 
>>    1 file changed, 22 insertions(+)
>>    create mode 100644 bsps/powerpc/psim/config/psim-testsuite.tcfg
>> 
>>  diff --git a/bsps/powerpc/psim/config/psim-testsuite.tcfg 
>>  b/bsps/powerpc/psim/config/psim-testsuite.tcfg
>>  new file mode 100644
>>  index 00..b0d2a05086
>>  --- /dev/null
>>  +++ b/bsps/powerpc/psim/config/psim-testsuite.tcfg
>>  @@ -0,0 +1,22 @@
>>  +#
>>  +# PSIM RTEMS Test Database.
>>  +#
>>  +# Format is one line per test that is_NOT_  built.
>>  +#
>>  +
>>  +expected-fail: fsimfsgeneric01
>>  +expected-fail: block11
>>  +expected-fail: rbheap01
>>  +expected-fail: termios01
>>  +expected-fail: ttest01
>>  +expected-fail: psx12
>>  +expected-fail: psxchroot01
>>  +expected-fail: psxfenv01
>>  +expected-fail: psximfs02
>>  +expected-fail: psxpipe01
>>  +expected-fail: spextensions01
>>  +expected-fail: spfatal31
>>  +expected-fail: spfifo02
>>  +expected-fail: spmountmgr01
>>  +expected-fail: spprivenv01
>>  +expected-fail: spstdthreads01
>> >>>
>> >>> I don't think these tests are expected to fail. If they fail, then there 
>> >>> is a bug somewhere.
>> >>
>> >> Yes we hope no tests fail but they can and do. Excluding tests because 
>> >> they fail would be incorrect. In the 5.1 release these bugs are present 
>> >> so we expect, or maybe it should say, we know the test will fail. With 
>> >> this change any thing that appears in the failure column is "unexpected" 
>> >> and that means the user build of the release does not match the state we 
>> >> "expect" and it is worth investigation by the user.
>> >>
>> >> Without these tests being tagged this way the user would have no idea 
>> >> where the stand after a build and test run and that would mean we would 
>> >> have to make sure a release has no failures. I consider that as not 
>> >> practical or realistic.
>> > Maybe we need another state, e.g. something-is-broken-please-fix-it.
>>
>> I do not think so, it is implicit in the failure or the test is broken. The 
>> only change is to add unexpected-pass, that will be on master after the 5 
>> branch.
>
>
> This would be a good ticket to file as a "small tasks" one. Explain how to 
> find all of the expected failures and investigate if one can be fixed or 
> explained.
>

That's perhaps the root of my complaint. By combining all "expected
failures" under one label, we need to go back and fix up these when we
fix a bug that makes it an "unexpected pass"  I guess I understand
this idea of "unexpected pass" now. I guess it doesn't really matter
if we split the expected failures, but I think there is a difference
that may be worth conveying to users.

> For example, fenv support is missing for many architectures so those could 
> have a comment above them. But the jmr3904 has a different memory map from 
> most BSPs and I know one of the fatal error tests has the simulator catch the 
> invalid memory access before the RTEMS exception handler. That is really an 
> expected fail but deserves (and has I think) a comment above it in the tcfg 
> file.
>
> --joel
>
>>
>> Chris
>>
>> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 4/6] testsuite: Add expected-fail to psim

[Gedare Bloom]

On Wed, May 6, 2020 at 5:12 AM Chris Johns  wrote:
>
>
> > On 6 May 2020, at 8:15 pm, Sebastian Huber 
> >  wrote:
> >
> > On 06/05/2020 12:00, Chris Johns wrote:
> >
> >>> On 6/5/20 7:35 pm, Sebastian Huber wrote:
>  On 06/05/2020 10:41, chr...@rtems.org wrote:
> >>>
>  From: Chris Johns
> 
>  Updates #2962
>  ---
>    bsps/powerpc/psim/config/psim-testsuite.tcfg | 22 
>    1 file changed, 22 insertions(+)
>    create mode 100644 bsps/powerpc/psim/config/psim-testsuite.tcfg
> 
>  diff --git a/bsps/powerpc/psim/config/psim-testsuite.tcfg 
>  b/bsps/powerpc/psim/config/psim-testsuite.tcfg
>  new file mode 100644
>  index 00..b0d2a05086
>  --- /dev/null
>  +++ b/bsps/powerpc/psim/config/psim-testsuite.tcfg
>  @@ -0,0 +1,22 @@
>  +#
>  +# PSIM RTEMS Test Database.
>  +#
>  +# Format is one line per test that is_NOT_  built.
>  +#
>  +
>  +expected-fail: fsimfsgeneric01
>  +expected-fail: block11
>  +expected-fail: rbheap01
>  +expected-fail: termios01
>  +expected-fail: ttest01
>  +expected-fail: psx12
>  +expected-fail: psxchroot01
>  +expected-fail: psxfenv01
>  +expected-fail: psximfs02
>  +expected-fail: psxpipe01
>  +expected-fail: spextensions01
>  +expected-fail: spfatal31
>  +expected-fail: spfifo02
>  +expected-fail: spmountmgr01
>  +expected-fail: spprivenv01
>  +expected-fail: spstdthreads01
> >>>
> >>> I don't think these tests are expected to fail. If they fail, then there 
> >>> is a bug somewhere.
> >>
> >> Yes we hope no tests fail but they can and do. Excluding tests because 
> >> they fail would be incorrect. In the 5.1 release these bugs are present so 
> >> we expect, or maybe it should say, we know the test will fail. With this 
> >> change any thing that appears in the failure column is "unexpected" and 
> >> that means the user build of the release does not match the state we 
> >> "expect" and it is worth investigation by the user.
> >>
> >> Without these tests being tagged this way the user would have no idea 
> >> where the stand after a build and test run and that would mean we would 
> >> have to make sure a release has no failures. I consider that as not 
> >> practical or realistic.
> > Maybe we need another state, e.g. something-is-broken-please-fix-it.
>
> I do not think so, it is implicit in the failure or the test is broken. The 
> only change is to add unexpected-pass, that will be on master after the 5 
> branch.
>

I disagree with this in principle, and it should be reverted after we
branch 5. It's fine for now to get the release state sync'd, but we
should find a long-term solution that distinguishes the cases:
1. we don't expect this test to pass on this bsp
2. we expect this test to pass, but know it doesn't currently

They are two very different things, and I don't like conflating them
into one "expected-fail" case

> Chris
>
> 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: Odd Behavior on Cygwin

[Chris Johns]

On 8/5/20 11:14 pm, Joel Sherrill wrote:
On Wed, May 6, 2020 at 12:49 AM Chris Johns > wrote:


On 6/5/20 3:46 am, Joel Sherrill wrote:
 > I have a test sweep going on Cygwin and there are a couple of
oddities I
 > would like some advice on:
 >
 > 1. It appears that the same command I used on Linux and FreeBSD
is not
 > managing to get mail to the build@ list. Any ideas?

What is the detailed error reported in the log or output? What does the
mail server think is happening?

 > ../source-builder/sb-set-builder --mail --mail-to=bu...@rtems.org

 > >
--mail-from=j...@rtems.org 
 > > --keep-going
--log=l-aarch64-5.txt
 > --prefix=/home/jrs007/rtems-cron-5.0.0-m2005-1/tools/5
5/rtems-aarch64

It is a python only SMTP client and should be portable.


Hmm... this is interesting. If this was a Windows firewall issue, I 
assume my

Virtualbox Linux wouldn't be able to send these reports.


Windows like to block outgoing to port 25. Maybe the VM is under the 
Windows firewall. I have no idea.



Mailing report: bu...@rtems.org 
Mail Send Failure: error: sending mail: [Errno 111] Connection refused
Build Set: Time 1:34:28.269299

Any idea what host/port I should telnet to to test this?


I do not know, it depends on your system set up and what ever else 
Python does on Windows.



I think I will message Amar for an idea as well.


Are you sending directly to RTEMS's mail server?

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

Re: Adding fenv support for ARM

[Joel Sherrill]

On Thu, May 7, 2020 at 1:33 PM Eshan Dhawan  wrote:

> Hello everyone,
> This the tread to discuss adding fenv support for ARM architecture in
> newlib.
>
> Link to previous thread:
> https://lists.rtems.org/pipermail/devel/2020-March/058473.html
>
> ---FreeBSD Source
> # https://github.com/freebsd/freebsd/tree/master/lib/msun/arm
> # https://github.com/freebsd/freebsd/blob/master/sys/arm/include/ieeefp.h
> ---NetBSD Source
> # https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/arm
>
> --- Musl has no implementation for fenv support for ARM  in it
>
> After going through the implementations both FreeBSD and NetBSD have a
> stub implementation.
> But then FreeBSD implementation seems to be more portable compared to that
> in NetBSD.
>
> Should I start porting it from FreeBSD?
> And which ARM BSP should I use for testing the changes?
> Currently, I have xilinx_zynq_a9_qemu build
>

I think the FreeBSD implementation is the one to use. It looks to support
hard and soft floating point implementations.

I think the fenv.h file there will have to be worked on so some of the
contents go into sys or machine/fenv.h. There is a portable fenv.h.


>
> There would also be a requirement to discuss where to place the files in
> Newlib.
>

Not much to discuss. It should go into
newlib-cygwin/newlib/libm/machine/arm.

>
> Thanks
> -Eshan
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: Implementation of OFW functions

[Gedare Bloom]

On Fri, May 8, 2020 at 9:34 AM Christian Mauderer  wrote:
>
>
> On 08/05/2020 17:26, Niteesh G. S. wrote:
> > On Fri, May 8, 2020 at 11:43 AM Christian Mauderer
> >  > > wrote:
> >
> >
> > On 07/05/2020 17:19, Niteesh G. S. wrote:
> > > On Thu, May 7, 2020 at 4:07 PM Sebastian Huber
> > >  > 
> > >  > >> wrote:
> > >
> > > On 07/05/2020 12:28, Niteesh G. S. wrote:
> > >
> > > > On Thu, May 7, 2020 at 1:21 PM Sebastian Huber
> > > >  > 
> > >  > >
> > > >  > 
> > >  >  > > >
> > > > On 07/05/2020 09:35, Niteesh G. S. wrote:
> > > >
> > > > > This is what I was trying to convey in one of the previous
> > > mails.
> > > > >
> > https://lists.rtems.org/pipermail/devel/2020-May/059717.html
> > > > > But in that mail, I was planning to replace KOBJLOOKUP.
> > > > > Should I start working on it? From the top of my mind, the
> > > > following has
> > > > > to be done.
> > > > > 1) Import openfirm.c openfirm.h, ofw_fdt.c
> > > > > 2) Add ofw_fdt.h since all the functions in ofw_fdt
> > are static.
> > > > > Should we also import ofw_if.h? Because that is where
> > OFW_*
> > > > functions
> > > > > are defined or just add a ofw_rtems_map.h which
> > redefines them,
> > > > instead
> > > > > of importing ofw_if.h?
> > > >
> > > > The KOBJ stuff in the OFW support enables FreeBSD to
> > have three
> > > > different implementations of the OFW API which can be
> > selected at
> > > > runtime:
> > > >
> > > > sys/powerpc/ofw/ofw_real.c
> > > > sys/dev/ofw/ofw_standard.c
> > > > sys/dev/ofw/ofw_fdt.c
> > > >
> > > > In libbsd this is already short cut to the FDT
> > implementation:
> > > >
> > > > #ifndef __rtems__
> > > > static ofw_def_t*ofw_def_impl = NULL;
> > > > #else /* __rtems__ */
> > > > #defineofw_def_impl (_fdt)
> > > > #endif /* __rtems__ */
> > > >
> > > > To me this looks like the KOBJ stuff was just used to
> > enable some
> > > > sort
> > > > of object oriented programming. Do we need this
> > flexibility at
> > > > runtime
> > > > in RTEMS? I would say no. I would hard wire this to the FDT
> > > > implementation. If someone has a problem with it in the
> > > future, this
> > > > decision can be readdressed.
> > > >
> > > >
> > > > Ok. But what is the neatest way to hardwire this to the FDT
> > > > implementation?
> > > > One way as Christian mentioned would be to redefine OFW_*
> > functions to
> > > > call the functions in ofw_fdt.c directly. Is there any other
> > way?
> > >
> > > I would try to replace the function declarations in openfirm.h
> > with
> > > inline functions which call the ofw_fdt.c functions.
> > >
> > >
> > > Should I proceed with the above method? or should I wait for others
> > > to comment?
> > > If I can proceed, the following is what I will be doing.
> > > 1) import openfirm.h and ofw_fdt.c into RTEMS.
> > > 2) Add ofw_fdt.h with functions declarations for functions in
> > ofw_fdt.c
> > > 3) Add necessary compile-time guards. This would include using
> > __rtems__
> > > preprocessor directive to avoid FreeBSD stuff and change the function
> > > definitions in ofw_fdt.c from static to non-static.
> > > Am I missing something? or is there any other way to do this?
> >
> > Maybe wait one or two more days for others to comment. For me the
> > direction sounds OK.
> >
> > You maybe can start thinking about where you want to import the
> > files to.
> >
> >
> > Since this has scope for future development. I think we should put it in a
> > separate directory under cpukit/include/ofw for header files and cpukit/ofw
> > for the source files. What do you think?
> >
> >
>
> If you plan to prepare a FreeBSD sync (regardless whether you implement
> it or someone else) another possibility could be to create a similar
> directory structure like in libbsd.
>
> Another 

Re: GSoC 2020: Implementation of OFW functions

[Christian Mauderer]

On 08/05/2020 17:26, Niteesh G. S. wrote:
> On Fri, May 8, 2020 at 11:43 AM Christian Mauderer
>  > wrote:
> 
> 
> On 07/05/2020 17:19, Niteesh G. S. wrote:
> > On Thu, May 7, 2020 at 4:07 PM Sebastian Huber
> >  
> >  >> wrote:
> >
> >     On 07/05/2020 12:28, Niteesh G. S. wrote:
> >
> >     > On Thu, May 7, 2020 at 1:21 PM Sebastian Huber
> >     >  
> >      >
> >     >  
> >       >     >
> >     >     On 07/05/2020 09:35, Niteesh G. S. wrote:
> >     >
> >     >     > This is what I was trying to convey in one of the previous
> >     mails.
> >     >     >
> https://lists.rtems.org/pipermail/devel/2020-May/059717.html
> >     >     > But in that mail, I was planning to replace KOBJLOOKUP.
> >     >     > Should I start working on it? From the top of my mind, the
> >     >     following has
> >     >     > to be done.
> >     >     > 1) Import openfirm.c openfirm.h, ofw_fdt.c
> >     >     > 2) Add ofw_fdt.h since all the functions in ofw_fdt
> are static.
> >     >     > Should we also import ofw_if.h? Because that is where
> OFW_*
> >     >     functions
> >     >     > are defined or just add a ofw_rtems_map.h which
> redefines them,
> >     >     instead
> >     >     > of importing ofw_if.h?
> >     >
> >     >     The KOBJ stuff in the OFW support enables FreeBSD to
> have three
> >     >     different implementations of the OFW API which can be
> selected at
> >     >     runtime:
> >     >
> >     >     sys/powerpc/ofw/ofw_real.c
> >     >     sys/dev/ofw/ofw_standard.c
> >     >     sys/dev/ofw/ofw_fdt.c
> >     >
> >     >     In libbsd this is already short cut to the FDT
> implementation:
> >     >
> >     >     #ifndef __rtems__
> >     >     static ofw_def_t    *ofw_def_impl = NULL;
> >     >     #else /* __rtems__ */
> >     >     #define    ofw_def_impl (_fdt)
> >     >     #endif /* __rtems__ */
> >     >
> >     >     To me this looks like the KOBJ stuff was just used to
> enable some
> >     >     sort
> >     >     of object oriented programming. Do we need this
> flexibility at
> >     >     runtime
> >     >     in RTEMS? I would say no. I would hard wire this to the FDT
> >     >     implementation. If someone has a problem with it in the
> >     future, this
> >     >     decision can be readdressed.
> >     >
> >     >
> >     > Ok. But what is the neatest way to hardwire this to the FDT
> >     > implementation?
> >     > One way as Christian mentioned would be to redefine OFW_*
> functions to
> >     > call the functions in ofw_fdt.c directly. Is there any other
> way?
> >
> >     I would try to replace the function declarations in openfirm.h
> with
> >     inline functions which call the ofw_fdt.c functions.
> >
> >
> > Should I proceed with the above method? or should I wait for others
> > to comment?
> > If I can proceed, the following is what I will be doing.
> > 1) import openfirm.h and ofw_fdt.c into RTEMS.
> > 2) Add ofw_fdt.h with functions declarations for functions in
> ofw_fdt.c
> > 3) Add necessary compile-time guards. This would include using
> __rtems__
> > preprocessor directive to avoid FreeBSD stuff and change the function
> > definitions in ofw_fdt.c from static to non-static.
> > Am I missing something? or is there any other way to do this?
> 
> Maybe wait one or two more days for others to comment. For me the
> direction sounds OK.
> 
> You maybe can start thinking about where you want to import the
> files to.
> 
> 
> Since this has scope for future development. I think we should put it in a 
> separate directory under cpukit/include/ofw for header files and cpukit/ofw
> for the source files. What do you think?
> 
> 

If you plan to prepare a FreeBSD sync (regardless whether you implement
it or someone else) another possibility could be to create a similar
directory structure like in libbsd.

Another directory could be ./cpukit/libmisc/rtems-fdt.

But your suggestion is also possible.

Maybe wait for some further input.

Best regards

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

Re: GSoC 2020: Implementation of OFW functions

[Niteesh G. S.]

On Fri, May 8, 2020 at 11:43 AM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

>
> On 07/05/2020 17:19, Niteesh G. S. wrote:
> > On Thu, May 7, 2020 at 4:07 PM Sebastian Huber
> >  > > wrote:
> >
> > On 07/05/2020 12:28, Niteesh G. S. wrote:
> >
> > > On Thu, May 7, 2020 at 1:21 PM Sebastian Huber
> > >  > 
> > >  > >> wrote:
> > >
> > > On 07/05/2020 09:35, Niteesh G. S. wrote:
> > >
> > > > This is what I was trying to convey in one of the previous
> > mails.
> > > > https://lists.rtems.org/pipermail/devel/2020-May/059717.html
> > > > But in that mail, I was planning to replace KOBJLOOKUP.
> > > > Should I start working on it? From the top of my mind, the
> > > following has
> > > > to be done.
> > > > 1) Import openfirm.c openfirm.h, ofw_fdt.c
> > > > 2) Add ofw_fdt.h since all the functions in ofw_fdt are
> static.
> > > > Should we also import ofw_if.h? Because that is where OFW_*
> > > functions
> > > > are defined or just add a ofw_rtems_map.h which redefines
> them,
> > > instead
> > > > of importing ofw_if.h?
> > >
> > > The KOBJ stuff in the OFW support enables FreeBSD to have three
> > > different implementations of the OFW API which can be selected
> at
> > > runtime:
> > >
> > > sys/powerpc/ofw/ofw_real.c
> > > sys/dev/ofw/ofw_standard.c
> > > sys/dev/ofw/ofw_fdt.c
> > >
> > > In libbsd this is already short cut to the FDT implementation:
> > >
> > > #ifndef __rtems__
> > > static ofw_def_t*ofw_def_impl = NULL;
> > > #else /* __rtems__ */
> > > #defineofw_def_impl (_fdt)
> > > #endif /* __rtems__ */
> > >
> > > To me this looks like the KOBJ stuff was just used to enable
> some
> > > sort
> > > of object oriented programming. Do we need this flexibility at
> > > runtime
> > > in RTEMS? I would say no. I would hard wire this to the FDT
> > > implementation. If someone has a problem with it in the
> > future, this
> > > decision can be readdressed.
> > >
> > >
> > > Ok. But what is the neatest way to hardwire this to the FDT
> > > implementation?
> > > One way as Christian mentioned would be to redefine OFW_*
> functions to
> > > call the functions in ofw_fdt.c directly. Is there any other way?
> >
> > I would try to replace the function declarations in openfirm.h with
> > inline functions which call the ofw_fdt.c functions.
> >
> >
> > Should I proceed with the above method? or should I wait for others
> > to comment?
> > If I can proceed, the following is what I will be doing.
> > 1) import openfirm.h and ofw_fdt.c into RTEMS.
> > 2) Add ofw_fdt.h with functions declarations for functions in ofw_fdt.c
> > 3) Add necessary compile-time guards. This would include using __rtems__
> > preprocessor directive to avoid FreeBSD stuff and change the function
> > definitions in ofw_fdt.c from static to non-static.
> > Am I missing something? or is there any other way to do this?
>
> Maybe wait one or two more days for others to comment. For me the
> direction sounds OK.
>
> You maybe can start thinking about where you want to import the files to.
>

Since this has scope for future development. I think we should put it in a
separate directory under cpukit/include/ofw for header files and cpukit/ofw
for the source files. What do you think?




> --
> 
> 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: Odd Behavior on Cygwin

[Joel Sherrill]

On Wed, May 6, 2020 at 12:49 AM Chris Johns  wrote:

> On 6/5/20 3:46 am, Joel Sherrill wrote:
> > I have a test sweep going on Cygwin and there are a couple of oddities I
> > would like some advice on:
> >
> > 1. It appears that the same command I used on Linux and FreeBSD is not
> > managing to get mail to the build@ list. Any ideas?
>
> What is the detailed error reported in the log or output? What does the
> mail server think is happening?
>
> > ../source-builder/sb-set-builder --mail --mail-to=bu...@rtems.org
> >  --mail-from=j...@rtems.org
> >  --keep-going --log=l-aarch64-5.txt
> > --prefix=/home/jrs007/rtems-cron-5.0.0-m2005-1/tools/5 5/rtems-aarch64
>
> It is a python only SMTP client and should be portable.
>

Hmm... this is interesting. If this was a Windows firewall issue, I assume
my
Virtualbox Linux wouldn't be able to send these reports.

Mailing report: bu...@rtems.org
Mail Send Failure: error: sending mail: [Errno 111] Connection refused
Build Set: Time 1:34:28.269299

Any idea what host/port I should telnet to to test this?

I think I will message Amar for an idea as well.


>
> > 2. $HOME in a script being nohup'ed was being replaced with
> > c:/msys64/ and not /home/... . Any idea what this was an indication
> > of? When I ran the script directly, the expansion was as expected. I
> > can't seem to reproduce this in a small test case. Any suggestions?
>
> Not really, this is the sort of stuff that makes using cygwin hard. Is
> your path clean and only using cygwin executables?
>
> > The build sweep is going (slowly as expected) and it is on the second
> > tool target. It will take a long time (as in days) to finish.
>
> Thanks
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] libtests/tar01: Remove files of tar01.tar archive

[Sebastian Huber]

A

$ find -type l

returns nothing in my Git branch with this patch.

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

[PATCH] libtests/tar01: Remove files of tar01.tar archive

[Sebastian Huber]

Update #3968.
---
 testsuites/libtests/tar01/home/abc/def/test_script | 2 --
 testsuites/libtests/tar01/home/test_file   | 2 --
 testsuites/libtests/tar01/symlink  | 1 -
 3 files changed, 5 deletions(-)
 delete mode 100755 testsuites/libtests/tar01/home/abc/def/test_script
 delete mode 100644 testsuites/libtests/tar01/home/test_file
 delete mode 12 testsuites/libtests/tar01/symlink

diff --git a/testsuites/libtests/tar01/home/abc/def/test_script 
b/testsuites/libtests/tar01/home/abc/def/test_script
deleted file mode 100755
index 884924820b..00
--- a/testsuites/libtests/tar01/home/abc/def/test_script
+++ /dev/null
@@ -1,2 +0,0 @@
-#! joel
-ls -las /dev
diff --git a/testsuites/libtests/tar01/home/test_file 
b/testsuites/libtests/tar01/home/test_file
deleted file mode 100644
index 1a9e0f656f..00
--- a/testsuites/libtests/tar01/home/test_file
+++ /dev/null
@@ -1,2 +0,0 @@
-This is a test of loading an RTEMS filesystem from an
-initial tar image.
diff --git a/testsuites/libtests/tar01/symlink 
b/testsuites/libtests/tar01/symlink
deleted file mode 12
index 1f10c8dabe..00
--- a/testsuites/libtests/tar01/symlink
+++ /dev/null
@@ -1 +0,0 @@
-home/test_file
\ No newline at end of file
-- 
2.16.4

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

Re: Symlink still in m2005-2

[Joel Sherrill]

On Fri, May 8, 2020 at 8:00 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 08/05/2020 14:55, Joel Sherrill wrote:
>
> > Not sure how this didn't get resolved since Sebastian posted a patch
> > which appeared to resolve this. But the tar file still has a simlink
> > and won't untar on mingw
> Sorry, it seems I only added the archive and forgot to remove the files
> of the archive.
>

It's OK. This is why we test.  And why Chris emphasizes that there are
lots of little details that have to be 100% right to have a release. :)

I have a build sweep going on CentOS 7, Ubuntu, and FreeBSD 12. Mingw64
will have to wait.  Cygwin seemed to work last time until my laptop blue
screened
after a few days. But it wasn't sending mail logs out. Need to run that down
before I build more there.

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

Re: Symlink still in m2005-2

[Sebastian Huber]

On 08/05/2020 14:55, Joel Sherrill wrote:

Not sure how this didn't get resolved since Sebastian posted a patch 
which appeared to resolve this. But the tar file still has a simlink 
and won't untar on mingw
Sorry, it seems I only added the archive and forgot to remove the files 
of the archive.

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

Symlink still in m2005-2

[Joel Sherrill]

Hi

Not sure how this didn't get resolved since Sebastian posted a patch which
appeared to resolve this. But the tar file still has a simlink and won't
untar on mingw

jrs007@JRS-OAR-Laptop MINGW64 ~/rtems-cron-5.0.0-m2005-2
$ tar tvf rtems-5.0.0-m2005-2.tar.xz | grep "\->"
lrwxr-xr-x chris/10100 2020-05-07 05:31
rtems-5.0.0-m2005-2/testsuites/libtests/tar01/symlink -> home/test_file

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

Re: RTEMS Release Snapshot 5.0.0-m2005-2

[Cedric Berger]

Hello,

I wanted to test the snapshot, but the following link:

https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m2005-2/

contains broken references. For example, the Quick Guide:

https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m2005-2/docs/rtems-docs-5.0.0-m2005-2-user.pdf

doesn't resolve:

The requested URL 
/pub/rtems/releases/5/5.0.0/5.0.0-m2005-2/docs/rtems-docs-5.0.0-m2005-2-user.pdf 
was not found on this server.


Other files in the release notes do not resolve, like the "docs", 
"sources" folder and everything under "RTEMS documentation".


Cédric


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

RTEMS Release Snapshot 5.0.0-m2005-2

[Chris Johns]

Hello,

I have uploaded release snapshot 5.0.0-m2005-2. The path is:

 https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m2005-2/

I hope this is the last snapshot before we branch for the RTEMS 5 release.

Please download, test and report any issues.

New to this snapshot are HTML release notes for RTEMS 5:

https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m2005-2/#rtems-5.1-release-notes

Please have a look.

This is one of the most tested builds of RTEMS including hardware 
testing. You can view the build logs for just May 2020 in the build 
mailing list archives:


 https://lists.rtems.org/pipermail/build/2020-May/date.html

I posted test results for the Beaglebone Black and Xilinx Zynq BSPs this 
week:


 https://lists.rtems.org/pipermail/build/2020-May/014695.html
 https://lists.rtems.org/pipermail/build/2020-May/014694.html

Finally and most importantly thank you to everyone who has worked over 
the last few weeks. It has been fantastic to get down to one ticket. The 
milestone can be viewed here:


 https://devel.rtems.org/milestone/5.1

Thanks
Chris

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

Re: [PATCH rtems_waf] rtems: Add uninstall option to the list of commands

[Vijay Kumar Banerjee]

On Fri, May 8, 2020, 4:54 AM Chris Johns  wrote:

> On 8/5/20 4:50 am, Vijay Kumar Banerjee wrote:
> > On Tue, May 5, 2020 at 4:13 PM Chris Johns  wrote:
> > Hi Chris,
> >
> > I added support in rtems_waf to test the uninstall function, following
> > the approach that you suggested. I'm attaching the patch here, please
> > have a look.
>
> This looks fine. We can work on this once we have branched.


Thanks for reviewing it. I'll send the patches after the release to avoid
confusion.

Thanks,
Vijay

>
> Thanks
> Chris
>
> >
> > I am using it in libbsd by calling it from wscript like this:
> > ```
> > diff --git a/wscript b/wscript
> > index 0979644a..74fc1f48 100644
> > --- a/wscript
> > +++ b/wscript
> > @@ -226,6 +226,9 @@ def configure(conf):
> >   update_builders(conf, conf.env.BUILDSET)
> >   rtems.configure(conf, bsp_configure)
> >
> > +def test(bld):
> > +rtems.test_uninstall(bld)
> > +
> >   def build(bld):
> >   rtems.build(bld)
> >   builders[bld.libbsd_buildset_name].build(bld)
> > ```
> > If this approach looks alright to you, I'll send a v2 of the patchset
> > for libbsd and rtems_waf for review.
> >
> > Thanks,
> > Vijay
> >>
> >> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Test threaded log module for rtems-tools

[chrisj]

Hello,

This is a test patch of a threading logger. My testing with qemu
on a multi-core box gave me an average time of 800msec with
a number of timeouts for the xilinx_zynq_a9_qemu BSP.

I will try this code in the RSB to see if it works there.

Anders, have a look as a possible start of a solution.

Thanks
Chris


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

[PATCH] rtemstoolkit: Rework the log locking adding an output thread.

[chrisj]

From: Chris Johns 

---
 rtemstoolkit/log.py | 76 +
 1 file changed, 49 insertions(+), 27 deletions(-)

diff --git a/rtemstoolkit/log.py b/rtemstoolkit/log.py
index 00fdb05..2e73e72 100755
--- a/rtemstoolkit/log.py
+++ b/rtemstoolkit/log.py
@@ -34,8 +34,11 @@
 
 from __future__ import print_function
 
+import atexit
 import os
+import queue
 import sys
+import time
 import threading
 
 from rtemstoolkit import error
@@ -57,9 +60,47 @@ tracing = False
 quiet = False
 
 #
-# Global output lock to keep output together when working with threads
+# Run the output from a separate thread to avoid blocking with a
+# lock. We want the outout to be blocks.
 #
-lock = threading.Lock()
+_output_queue = queue.SimpleQueue()
+
+def _output_worker(timeout=None):
+try:
+is_write, is_flush, handle, out = _output_queue.get(timeout=timeout)
+except queue.Empty:
+return timeout is None
+except KeyboardInterrupt:
+return False
+except:
+return False
+if is_write:
+handle.write(out)
+else:
+for l in out.replace(chr(13), '').splitlines():
+print(l, file=handle)
+if is_flush:
+handle.flush()
+return True
+
+def _output_put(is_write, is_flush, handle, out):
+_output_queue.put((is_write, is_flush, handle, out))
+while not _output_queue.empty():
+time.sleep(0.001)
+
+def _output_exiting():
+while _output_worker(timeout=0.100):
+pass
+
+def _output_thread():
+while _output_worker():
+pass
+
+_outputter = threading.Thread(target=_output_thread,
+  daemon=True,
+  name='log_outputter')
+_outputter.start()
+atexit.register(_output_exiting)
 
 def info(args):
 s = [' Command Line: %s' % (' '.join(args))]
@@ -92,20 +133,12 @@ def _output(text = os.linesep, log = None):
 elif default is not None:
 default.output(text)
 else:
-lock.acquire()
-for l in text.replace(chr(13), '').splitlines():
-print(l)
-lock.release()
+_output_put(False, False, sys.stdout, text)
 if capture is not None:
-lock.acquire()
 capture(text)
-lock.release()
 
 def stderr(text = os.linesep, log = None):
-lock.acquire()
-for l in text.replace(chr(13), '').splitlines():
-print(l, file = sys.stderr)
-lock.release()
+_output_put(False, False, sys.stderr, text)
 
 def output(text = os.linesep, log = None):
 if not quiet:
@@ -114,10 +147,7 @@ def output(text = os.linesep, log = None):
 def notice(text = os.linesep, log = None, stdout_only = False):
 if not quiet and \
 (default is not None and not default.has_stdout() or stdout_only):
-lock.acquire()
-for l in text.replace(chr(13), '').splitlines():
-print(l)
-lock.release()
+_output_put(False, False, sys.stdout, text)
 if not stdout_only:
 _output(text, log)
 
@@ -138,7 +168,6 @@ def flush(log = None):
 class log:
 """Log output to stdout or a file."""
 def __init__(self, streams = None, tail_size = 100):
-self.lock = threading.Lock()
 self.tail = []
 self.tail_size = tail_size
 self.fhs = [None, None]
@@ -186,16 +215,9 @@ class log:
 out = os.linesep.join(text) + os.linesep
 if isinstance(out, bytes):
 out = out.decode('utf-8', 'ignore')
-self.lock.acquire()
-try:
-for f in range(0, len(self.fhs)):
-if self.fhs[f] is not None:
-self.fhs[f].write(out)
-self.flush()
-except:
-raise
-finally:
-self.lock.release()
+for f in range(0, len(self.fhs)):
+if self.fhs[f] is not None:
+_output_put(True, True, self.fhs[f], out)
 
 def flush(self):
 """Flush the output."""
-- 
2.24.1

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

Re: [PATCH] networking: Increase _SYS_MBUF_LEGACY_MSIZE to 256 to match FreeBSD

[Chris Johns]

On 8/5/20 3:15 pm, Hesham Almatary wrote:

I am not gonna push this patch. I have only tried to run loopback and
telnetd on rv64. Even though loopback doesn't make RTEMS exit with a
failure, but the scn output doesn't look right (compared to riscv32).
telnetd scn is identical and succeed on both, but I guess that's just
luck. I am not planning to debug/test further networking libtests with
the legacy stack.

Chris, I believe all the patches I submitted can wait after the
release. We can ignore this one.


OK and thanks.

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

Re: [PATCH 0/2] Source Builder: Fix UnicodeDecodeError build hang

[Chris Johns]

On 8/5/20 4:22 pm, Anders Montonen wrote:
On 8 May 2020, at 9:12, Chris Johns > wrote:

On 8/5/20 3:50 pm, Anders Montonen wrote:

On a not completely unrelated note, have there been any thoughts 
about setting a timetable for deprecating Python 2 support now that 
it is EOL, eg. in RTEMS6? Are there any specific host platforms you 
want to support that don’t have Python 3?
We cannot just yet because we have users who run long life operating 
systems and cannot move. This is one of the roles RTEMS provides. We 
maintain tools and the OS longer than others and on older target 
hardware. Large orgs cannot retool just because it exists.


Right, which is why you set a timetable to give sufficient advance 
warning, and coincide it with a major release. Though I would have 
assumed that these kinds of users don’t really switch to newer releases 
anyway.


There is a mix, those on older RTEMS versions and old host OSs, a new 
development so a newer RTEMS but the same older host OS due to a company 
or org policy, then those on new hosts but old hardware, ie PowerPC VME 
cards, and finally those on a new OS but using an old RTEMS and 
hardware. I had this a while ago where an archived project years later 
needed a minor change and the Linux host OS that was used only supported 
VL bus and would not boot on any hardware we could find or any VM. We 
took the source code archive, compiled gcc with a couple of minor fixes 
on a current Linux at the time, built RTEMS, the app and verified the 
ROM image bit for bit before making the change.


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

Re: [PATCH 0/2] Source Builder: Fix UnicodeDecodeError build hang

[Anders Montonen]

On 8 May 2020, at 9:12, Chris Johns  wrote:
> On 8/5/20 3:50 pm, Anders Montonen wrote:
> 
>> On a not completely unrelated note, have there been any thoughts about 
>> setting a timetable for deprecating Python 2 support now that it is EOL, eg. 
>> in RTEMS6? Are there any specific host platforms you want to support that 
>> don’t have Python 3?
> We cannot just yet because we have users who run long life operating systems 
> and cannot move. This is one of the roles RTEMS provides. We maintain tools 
> and the OS longer than others and on older target hardware. Large orgs cannot 
> retool just because it exists.

Right, which is why you set a timetable to give sufficient advance warning, and 
coincide it with a major release. Though I would have assumed that these kinds 
of users don’t really switch to newer releases anyway.

Regards,
Anders___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: Implementation of OFW functions

[Christian Mauderer]

On 07/05/2020 17:19, Niteesh G. S. wrote:
> On Thu, May 7, 2020 at 4:07 PM Sebastian Huber
>  > wrote:
> 
> On 07/05/2020 12:28, Niteesh G. S. wrote:
> 
> > On Thu, May 7, 2020 at 1:21 PM Sebastian Huber
> >  
> >  >> wrote:
> >
> >     On 07/05/2020 09:35, Niteesh G. S. wrote:
> >
> >     > This is what I was trying to convey in one of the previous
> mails.
> >     > https://lists.rtems.org/pipermail/devel/2020-May/059717.html
> >     > But in that mail, I was planning to replace KOBJLOOKUP.
> >     > Should I start working on it? From the top of my mind, the
> >     following has
> >     > to be done.
> >     > 1) Import openfirm.c openfirm.h, ofw_fdt.c
> >     > 2) Add ofw_fdt.h since all the functions in ofw_fdt are static.
> >     > Should we also import ofw_if.h? Because that is where OFW_*
> >     functions
> >     > are defined or just add a ofw_rtems_map.h which redefines them,
> >     instead
> >     > of importing ofw_if.h?
> >
> >     The KOBJ stuff in the OFW support enables FreeBSD to have three
> >     different implementations of the OFW API which can be selected at
> >     runtime:
> >
> >     sys/powerpc/ofw/ofw_real.c
> >     sys/dev/ofw/ofw_standard.c
> >     sys/dev/ofw/ofw_fdt.c
> >
> >     In libbsd this is already short cut to the FDT implementation:
> >
> >     #ifndef __rtems__
> >     static ofw_def_t    *ofw_def_impl = NULL;
> >     #else /* __rtems__ */
> >     #define    ofw_def_impl (_fdt)
> >     #endif /* __rtems__ */
> >
> >     To me this looks like the KOBJ stuff was just used to enable some
> >     sort
> >     of object oriented programming. Do we need this flexibility at
> >     runtime
> >     in RTEMS? I would say no. I would hard wire this to the FDT
> >     implementation. If someone has a problem with it in the
> future, this
> >     decision can be readdressed.
> >
> >
> > Ok. But what is the neatest way to hardwire this to the FDT
> > implementation?
> > One way as Christian mentioned would be to redefine OFW_* functions to
> > call the functions in ofw_fdt.c directly. Is there any other way?
> 
> I would try to replace the function declarations in openfirm.h with
> inline functions which call the ofw_fdt.c functions.
> 
> 
> Should I proceed with the above method? or should I wait for others
> to comment?
> If I can proceed, the following is what I will be doing.
> 1) import openfirm.h and ofw_fdt.c into RTEMS.
> 2) Add ofw_fdt.h with functions declarations for functions in ofw_fdt.c
> 3) Add necessary compile-time guards. This would include using __rtems__
> preprocessor directive to avoid FreeBSD stuff and change the function
> definitions in ofw_fdt.c from static to non-static.
> Am I missing something? or is there any other way to do this?

Maybe wait one or two more days for others to comment. For me the
direction sounds OK.

You maybe can start thinking about where you want to import the files to.

-- 

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 0/2] Source Builder: Fix UnicodeDecodeError build hang

[Chris Johns]

On 8/5/20 3:50 pm, Anders Montonen wrote:

On 8 May 2020, at 7:36, Chris Johns  wrote:

On 8/5/20 2:27 pm, Anders Montonen wrote:

Hi,

On 7 May 2020, at 5:10, Chris Johns  wrote:

On 7/5/20 9:37 am, Anders Montonen wrote:

This patch fixes the UnicodeDecodeError that randomly caused source
builder to hang.

In my testing, there was no difference in performance at least under
Python 3.


Have you tested python 2?

Unfortunately the patch caused the log.py module to trigger UnicodeEncodeErrors 
under Python 2, so consider it withdrawn.


Oh ok. Is it worth looking at fixing log.py? Our fix seems to me to important.


I’m looking into it, I just wanted to give a heads-up.


Ok. I have been playing with a new version of log.py in rtems-tools to 
avoid the "blocking while holding a lock" exception. I will send you a 
copy off list. I am looking to use a queue and feed all the output to a 
worker thread removing any locks. I am seeing the exception running 
rtems-test with qemu with the xilinx_zynq_a9_qemu BSP.



On a not completely unrelated note, have there been any thoughts about setting 
a timetable for deprecating Python 2 support now that it is EOL, eg. in RTEMS6? 
Are there any specific host platforms you want to support that don’t have 
Python 3?


We cannot just yet because we have users who run long life operating 
systems and cannot move. This is one of the roles RTEMS provides. We 
maintain tools and the OS longer than others and on older target 
hardware. Large orgs cannot retool just because it exists.


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