Re: Odd Behavior on Cygwin

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

Re: [PATCH 3/7] rtems: Deprecate RTEMS_MAXIMUM_NAME_LENGTH

On 6/5/20 2:35 pm, Sebastian Huber wrote: On 06/05/2020 02:25, Chris Johns wrote: Why is this being removed? It is not documented. It is not used in the RTEMS code base. It is longer than sizeof(rtems_name). Could you please add this to the commit message? This is important information

[PATCH] libtests/tar0[12]: Add tar archive

Do not generate the test tar archive on the host computer since not all file systems support symbolic links. Close #3968. --- testsuites/libtests/Makefile.am | 18 ++ testsuites/libtests/configure.ac| 3 +-- testsuites/libtests/tar01/tar01.tar | Bin 0 -> 10240 bytes

Re: GSoC 2020: Implementation of OFW functions

Hello Niteesh, On 05/05/2020 19:10, Niteesh G. S. wrote: This is thread is about implementing OFW functions in RTEMS as part of my GSoC project. I would like to start off with this part since the refactoring work will somewhat depend on this. Implementing these functions into RTEMS will make

Re: Purpose of _Copyright_Notice?

On 06/05/2020 04:37, gro...@chichak.ca wrote: On 2020-May-05, at 06:37, Joel Sherrill wrote: The original intent wasn't as much a copyright notice as to just leave some breadcrumb the system was based on RTEMS. I don't know that even when it was introduced, there was any guarantee it would be

Re: [PATCH 3/7] rtems: Deprecate RTEMS_MAXIMUM_NAME_LENGTH

On 06/05/2020 02:25, Chris Johns wrote: Why is this being removed? It is not documented. It is not used in the RTEMS code base. It is longer than sizeof(rtems_name). ___ devel mailing list devel@rtems.org

Re: GSoC 2020: Implementation of OFW functions

On Wed, May 6, 2020 at 1:22 AM Gedare Bloom wrote: > Just to pile on, I have a small port of OFW underneath sparc64, it > would be great to replace it. It might also provide some useful code, > maybe.. Anyway, look at what it is using. Thanks for letting me know about this. It somewhat gives me

Re: Purpose of _Copyright_Notice?

On 2020-May-05, at 06:37, Joel Sherrill wrote: > > The original intent wasn't as much a copyright notice as to just > leave some breadcrumb the system was based on RTEMS. I don't > know that even when it was introduced, there was any guarantee > it would be there. > > Any ideas on how to leave

Re: [PATCH 3/7] rtems: Deprecate RTEMS_MAXIMUM_NAME_LENGTH

Why is this being removed? Chris On 6/5/20 12:23 am, Sebastian Huber wrote: Close #3971. --- cpukit/include/rtems/system.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/cpukit/include/rtems/system.h b/cpukit/include/rtems/system.h index 2fb5e8add7..23d805d0bc

Re: [PATCH 1/7] Use rtems_get_version_string()

This patch is OK for 5.1. On 6/5/20 12:23 am, Sebastian Huber wrote: Update #3970. --- bsps/powerpc/beatnik/start/bspstart.c | 2 +- bsps/powerpc/motorola_powerpc/start/bspstart.c | 2 +- bsps/powerpc/mvme3100/start/bspstart.c | 2 +- bsps/powerpc/mvme5500/start/bspstart.c

Re: GSoC 2020: Implementation of OFW functions

Just to pile on, I have a small port of OFW underneath sparc64, it would be great to replace it. It might also provide some useful code, maybe.. Anyway, look at what it is using. On Tue, May 5, 2020 at 12:20 PM Christian Mauderer wrote: > > Hello Niteesh, > > On 05/05/2020 19:10, Niteesh G. S.

Re: GSoC 2020: Implementation of OFW functions

Hello Niteesh, On 05/05/2020 19:10, Niteesh G. S. wrote: > This is thread is about implementing OFW functions in RTEMS as part > of my GSoC project. I would like to start off with this part since the > refactoring > work will somewhat depend on this. I'm not sure whether everyone on the list is

Re: GSoC 2020: Implementation of OFW functions

On Tue, May 5, 2020 at 10:40 PM Niteesh G. S. wrote: > This is thread is about implementing OFW functions in RTEMS as part > of my GSoC project. I would like to start off with this part since the > refactoring > work will somewhat depend on this. > > Implementing these functions into RTEMS will

Re: [PATCH 1/7] Use rtems_get_version_string()

I would like to include this in the RTEMS 5.1 release since I would like to remove the stuff from the API level exported by in RTEMS 6. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Odd Behavior on Cygwin

Hi 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? ../source-builder/sb-set-builder --mail --mail-to=bu...@rtems.org

GSoC 2020: Implementation of OFW functions

This is thread is about implementing OFW functions in RTEMS as part of my GSoC project. I would like to start off with this part since the refactoring work will somewhat depend on this. Implementing these functions into RTEMS will make porting drivers from FreeBSD to RTEMS easy. Currently, the

Re: m2005 untar error on msys2 (tar01 directory)

On 05/05/2020 12:38, Chris Johns wrote: On 5 May 2020, at 6:25 pm, Sebastian Huber wrote: On 05/05/2020 09:48, Chris Johns wrote: It is currently busy building the 5/rtems-sparc build set (without GDB) in a mingw64 shell. Is a build in the msys shell something useful/supported? Yes, we

Re: [PATCH 4/7] rtems: Deprecate

On 05/05/2020 17:05, Joel Sherrill wrote: Doesn't all the deprecation impact user documentation? This stuff was not documented as far as I know, but since it was used in BSP and other code in RTEMS I guess it was used in applications as well. ___

Re: [PATCH 4/7] rtems: Deprecate

Doesn't all the deprecation impact user documentation? On Tue, May 5, 2020 at 9:23 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Close #3972. > --- > cpukit/include/rtems/system.h | 4 > 1 file changed, 4 insertions(+) > > diff --git a/cpukit/include/rtems/system.h

[PATCH 4/7] rtems: Deprecate

Close #3972. --- cpukit/include/rtems/system.h | 4 1 file changed, 4 insertions(+) diff --git a/cpukit/include/rtems/system.h b/cpukit/include/rtems/system.h index 23d805d0bc..8019717bc2 100644 --- a/cpukit/include/rtems/system.h +++ b/cpukit/include/rtems/system.h @@ -22,6 +22,10 @@

[PATCH 6/7] rtems: Deprecate _Copyright_Notice

Update #3973. --- cpukit/include/rtems/system.h| 2 +- cpukit/sapi/src/getcopyrightnotice.c | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/cpukit/include/rtems/system.h b/cpukit/include/rtems/system.h index 8019717bc2..032ac56a95 100644 ---

[PATCH 7/7] score: Update _Copyright_Notice

Add the _Copyright_Notice to a special linker set to prevent a garbage collection of this item. --- cpukit/sapi/src/exinit.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/cpukit/sapi/src/exinit.c b/cpukit/sapi/src/exinit.c index 623d4022c8..db0d1fb70d 100644 ---

[PATCH 3/7] rtems: Deprecate RTEMS_MAXIMUM_NAME_LENGTH

Close #3971. --- cpukit/include/rtems/system.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/cpukit/include/rtems/system.h b/cpukit/include/rtems/system.h index 2fb5e8add7..23d805d0bc 100644 --- a/cpukit/include/rtems/system.h +++ b/cpukit/include/rtems/system.h @@

[PATCH 2/7] rtems: Deprecate use of _RTEMS_version

Close #3970. --- cpukit/include/rtems/system.h | 9 - cpukit/sapi/src/getversionstring.c | 2 ++ testsuites/sptests/spsize/size.c | 2 ++ 3 files changed, 8 insertions(+), 5 deletions(-) diff --git a/cpukit/include/rtems/system.h b/cpukit/include/rtems/system.h index

[PATCH 1/7] Use rtems_get_version_string()

Update #3970. --- bsps/powerpc/beatnik/start/bspstart.c | 2 +- bsps/powerpc/motorola_powerpc/start/bspstart.c | 2 +- bsps/powerpc/mvme3100/start/bspstart.c | 2 +- bsps/powerpc/mvme5500/start/bspstart.c | 2 +- cpukit/libmisc/shell/shell.c | 6 +++---

[PATCH 5/7] rtems: Add rtems_get_copyright_notice()

Update #3973. --- cpukit/Makefile.am | 1 + cpukit/include/rtems.h | 5 cpukit/libmisc/shell/shell.c | 14 +-- cpukit/sapi/src/getcopyrightnotice.c | 46 testsuites/sptests/sp43/init.c | 1 +

Re: Gsoc improvement for next time

Hello Suyash, There are always more good students and proposals than slots. We have had a few students in the past that did not get accepted one time and came back again successfully in the future. Some of them might even still be around to give you some advice. In your case, the main concern

Re: Purpose of _Copyright_Notice?

On Tue, May 5, 2020 at 7:43 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 05/05/2020 14:37, Joel Sherrill wrote: > > > The original intent wasn't as much a copyright notice as to just > > leave some breadcrumb the system was based on RTEMS. I don't > > know that even when

Re: Purpose of _Copyright_Notice?

On 05/05/2020 14:37, Joel Sherrill wrote: The original intent wasn't as much a copyright notice as to just leave some breadcrumb the system was based on RTEMS. I don't know that even when it was introduced, there was any guarantee it would be there. Maybe change it to "Copyright (C) 1988,

Purpose of _Copyright_Notice?

Hello, there is a constant _Copyright_Notice declared in and defined in exinit.c: const char _Copyright_Notice[] = "COPYRIGHT (c) 1989-2008.\n\ On-Line Applications Research Corporation (OAR).\n"; This copyright notice is out of date and incomplete. Since it is not referenced by the

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

> On 5 May 2020, at 5:37 pm, Vijay Kumar Banerjee wrote: > >  > > >> On Tue, May 5, 2020 at 9:56 AM Chris Johns wrote: >> On 4/5/20 8:16 pm, Vijay Kumar Banerjee wrote: >> > >> > >> > On Mon, May 4, 2020 at 4:39 AM Chris Johns > > > wrote: >> > >> > Hi >> >

Re: m2005 untar error on msys2 (tar01 directory)

> On 5 May 2020, at 6:25 pm, Sebastian Huber > wrote: > > On 05/05/2020 09:48, Chris Johns wrote: > > It is currently busy building the 5/rtems-sparc build set (without GDB) > in a mingw64 shell. Is a build in the msys shell something > useful/supported? Yes, we

Re: m2005 untar error on msys2 (tar01 directory)

On 05/05/2020 09:48, Chris Johns wrote: It is currently busy building the 5/rtems-sparc build set (without GDB) in a mingw64 shell. Is a build in the msys shell something useful/supported? Yes, we have valid users. Plus building on Windows is valid for the same reasons we build from source

Re: m2005 untar error on msys2 (tar01 directory)

On 5/5/20 5:34 pm, Anders Montonen wrote: Hi, On 5 May 2020, at 8:44, Sebastian Huber > wrote: On 05/05/2020 07:41, Chris Johns wrote: On 5/5/20 3:34 pm, Sebastian Huber wrote: What does `os.uname()` return? In the msys shell: $ python Python

Re: m2005 untar error on msys2 (tar01 directory)

On 5/5/20 5:37 pm, Sebastian Huber wrote: On 05/05/2020 09:25, Chris Johns wrote: Oh OK, maybe keep it? Could you patch the RSB and see if it works? I removed the GDB from the build set. I am pretty sure it would work with a patched windows.py. Which patch? I am a bit lost, I thought the

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

On Tue, May 5, 2020 at 9:56 AM Chris Johns wrote: > On 4/5/20 8:16 pm, Vijay Kumar Banerjee wrote: > > > > > > On Mon, May 4, 2020 at 4:39 AM Chris Johns > > wrote: > > > > Hi > > > > Are uninstall command useful with RTEMS? A use case that shows how it > >

Re: m2005 untar error on msys2 (tar01 directory)

On 05/05/2020 09:25, Chris Johns wrote: Oh OK, maybe keep it? Could you patch the RSB and see if it works? I removed the GDB from the build set. I am pretty sure it would work with a patched windows.py. Which patch? It is currently busy building the 5/rtems-sparc build set (without GDB)

Re: m2005 untar error on msys2 (tar01 directory)

Hi, > On 5 May 2020, at 8:44, Sebastian Huber > wrote: > On 05/05/2020 07:41, Chris Johns wrote: > >> On 5/5/20 3:34 pm, Sebastian Huber wrote: >> >> What does `os.uname()` return? > > In the msys shell: > > $ python > Python 3.7.4 (default, Jul 11 2019, 09:35:14) > [GCC 9.1.0] on msys >

Re: m2005 untar error on msys2 (tar01 directory)

On 5/5/20 5:01 pm, Sebastian Huber wrote: On 05/05/2020 08:57, Chris Johns wrote: On 5/5/20 4:05 pm, Sebastian Huber wrote: On 05/05/2020 08:01, Chris Johns wrote: What does `os.uname()` return? In the msys shell: $ python Python 3.7.4 (default, Jul 11 2019, 09:35:14) That is what I

Re: m2005 untar error on msys2 (tar01 directory)

On 05/05/2020 08:57, Chris Johns wrote: On 5/5/20 4:05 pm, Sebastian Huber wrote: On 05/05/2020 08:01, Chris Johns wrote: What does `os.uname()` return? In the msys shell: $ python Python 3.7.4 (default, Jul 11 2019, 09:35:14) That is what I have installed. [GCC 9.1.0] on msys Type

Re: m2005 untar error on msys2 (tar01 directory)

On 5/5/20 4:05 pm, Sebastian Huber wrote: On 05/05/2020 08:01, Chris Johns wrote: What does `os.uname()` return? In the msys shell: $ python Python 3.7.4 (default, Jul 11 2019, 09:35:14) That is what I have installed. [GCC 9.1.0] on msys Type "help", "copyright", "credits" or "license"

Re: m2005 untar error on msys2 (tar01 directory)

On 05/05/2020 08:01, Chris Johns wrote: What does `os.uname()` return? In the msys shell: $ python Python 3.7.4 (default, Jul 11 2019, 09:35:14) That is what I have installed. [GCC 9.1.0] on msys Type "help", "copyright", "credits" or "license" for more information.  >>> import os  >>>

Re: m2005 untar error on msys2 (tar01 directory)

On 5/5/20 3:44 pm, Sebastian Huber wrote: On 05/05/2020 07:41, Chris Johns wrote: On 5/5/20 3:34 pm, Sebastian Huber wrote: On 05/05/2020 07:22, Chris Johns wrote: On 5/5/20 3:20 pm, Sebastian Huber wrote: In a msys2 shell I get: $ ../source-builder/sb-set-builder --prefix=/opt/rtems/5