Bug Reporting Page

2019-08-13 Thread Sebastian Huber

Hello,

I completed my work with moving the bug reporting information to the 
user manual. Please have a look at the changed New Ticket page:


https://devel.rtems.org/wiki/NewTicket

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
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 v2] rtems-record: New program

2019-08-13 Thread Sebastian Huber

On 14/08/2019 03:57, Chris Johns wrote:

On 13/8/19 3:10 pm, Sebastian Huber wrote:

sorry for the rush,


Sorry for the delay, I have a client demo this week I am helping with.


but what do you think of this patch?


Why not C++? The rtems-tools repo has strong support for C++ and it brings a
range of benefits, for example no need to code call handlers at a low level,
containers so no need for us to include and maintain trace/record/tree.h, and
more. When I see us adding code like `tree.h` I have in the back of my mind the
long term support issues it brings while a `std::map` is maintained for us.


Originally, the program should be able to filter live traces with about 
20MiB/s. The std::map is simply too slow. Boost.Intrusive would be an 
option (it is slower than tree.h in my tests too: 
https://github.com/sebhub/rb-bench). The tree.h is a copy from Newlib, 
so it doesn't introduce new maintenance issues. Anyway, for the CTF 
conversion the map is unnecessary and could be optimized away. We didn't 
had the time to do this in the GSoC project.




GNU projects like gdb and gcc have moved to C++ and of course llvm is C++ and
this is for good reason. I provide these examples in the hope this does not
start a C vs C++ debate.


I would like to
integrate the tracing work of the GSoC project and this patch is a blocking 
point.


I understand. I am excited by the work that has been done here and what you are
doing. It is taking all my will power to not read the ARM debug trace section of
an ARM TRM as I think that hardware is ripe for integration with this code base
and set of tools. A C++ framework in rtemstoolkit would be really helpful if I
do as it would grow what we have rather than us collecting isolated C programs.

I also understand and appreciate the limited time we all have so I am happy to
hear how you see the host side progressing over time and how it fits into our
ecosystem. I would also like to hear what others think.


I don't have a problem with C++ in general. However, I don't think that 
the use of C in this small program is a blocking point to integrate the 
GSoC work. This is work in progress anyway. This program only scratches 
the surface.


When we think about C++, then we should also think about boost, but this 
is another topic.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
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: RTEMS 5 gcc-fb371a33fa6 vs gcc-9.2.0

2019-08-13 Thread Sebastian Huber



On 14/08/2019 01:52, Chris Johns wrote:

On 13/8/19 3:02 pm, Sebastian Huber wrote:


the patch just changed GCC 9.1 to 9.2 on all targets which use GCC 9, these are
or1k, riscv, and x86_64.


The change as broken MacOS due to this bug ...

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

I posted build results showing the error is still present. I had a patch in the
previous version and it should apply.


Now I am a bit confused. This patch

https://git.rtems.org/rtems-source-builder/commit/?id=5a0dba77b13eec49f86ce3812fb74f65dfa1e98d

changes the GCC version from 9.1.0 to 9.2.0 on or1k, riscv, and x86_64. 
I didn't change the patches:


https://git.rtems.org/rtems-source-builder/tree/rtems/config/tools/rtems-gcc-9.1.0-newlib-6661a67.cfg?id=5a0dba77b13eec49f86ce3812fb74f65dfa1e98d

The GCC bug doesn't seem to be a GCC 9.1.0 to 9.2.0 regression. In your 
build log only riscv failed, or1k and x86_64 passed. Is this a sporadic 
problem?





Since there will be probably no RTEMS 5 in the near future, maybe we should move
to GCC 9.2 in general.


This is a catch-22, I hope to start on the release process soon but things like
this add to the complexity and add to the time it takes.


If we do this on PowerPC, then the SPE is no longer supported.


Joel has stated many times in talks I have seen that we follow the architectures
GCC supports and if one is removed we remove support.

Does this mean 5.1 is the last version of RTEMS to support SPE?


This was my plan.


Should the specific BSPs be moved to tier 4 and marked for removal?


The SPE support should bit rot for a while. The chips are still in 
production and used with RTEMS, e.g. by EPICS users.





On ARM a breaking change in compiler options is necessary.


What options are these?


ARM changed the FPU options in GCC 8 and later.



Also this seems back to front to me. Should all hosts be on 9.2.0 and those that
cannot have specific versions?


Only PowerPC should stay at GCC 7 until the next RTEMS release from my 
point of view. Everything else can move on.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
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 v2] rtems-record: New program

2019-08-13 Thread Chris Johns
On 13/8/19 3:10 pm, Sebastian Huber wrote:
> sorry for the rush, 

Sorry for the delay, I have a client demo this week I am helping with.

> but what do you think of this patch?

Why not C++? The rtems-tools repo has strong support for C++ and it brings a
range of benefits, for example no need to code call handlers at a low level,
containers so no need for us to include and maintain trace/record/tree.h, and
more. When I see us adding code like `tree.h` I have in the back of my mind the
long term support issues it brings while a `std::map` is maintained for us.

GNU projects like gdb and gcc have moved to C++ and of course llvm is C++ and
this is for good reason. I provide these examples in the hope this does not
start a C vs C++ debate.

> I would like to
> integrate the tracing work of the GSoC project and this patch is a blocking 
> point.

I understand. I am excited by the work that has been done here and what you are
doing. It is taking all my will power to not read the ARM debug trace section of
an ARM TRM as I think that hardware is ripe for integration with this code base
and set of tools. A C++ framework in rtemstoolkit would be really helpful if I
do as it would grow what we have rather than us collecting isolated C programs.

I also understand and appreciate the limited time we all have so I am happy to
hear how you see the host side progressing over time and how it fits into our
ecosystem. I would also like to hear what others think.

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


Re: [PATCH v2] rtems-record: New program

2019-08-13 Thread Ravindra Kumar Meena
Hello Chris,

>
> sorry for the rush, but what do you think of this patch? I would like to
> integrate the tracing work of the GSoC project and this patch is a
> blocking point.
>
Please review the patches. This need to be integrated in master branch
before 19th August (GSoC ends). I have to prepare final report after the
code submission.

One documentation patch review is pending:

https://lists.rtems.org/pipermail/devel/2019-August/027215.html

Thanks

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

Re: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV

2019-08-13 Thread Chris Johns
On 14/8/19 8:34 am, Joel Sherrill wrote:
> Since I don't know how to attach gdb to the new sis for griscv, I emailed Jiri
> privately.

Does `-gdb` ...

https://git.rtems.org/sis/tree/sis.c#n133

... work?

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


Re: RTEMS 5 gcc-fb371a33fa6 vs gcc-9.2.0

2019-08-13 Thread Chris Johns
On 13/8/19 3:02 pm, Sebastian Huber wrote:

> the patch just changed GCC 9.1 to 9.2 on all targets which use GCC 9, these 
> are
> or1k, riscv, and x86_64.

The change as broken MacOS due to this bug ...

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

I posted build results showing the error is still present. I had a patch in the
previous version and it should apply.

> Since there will be probably no RTEMS 5 in the near future, maybe we should 
> move
> to GCC 9.2 in general.

This is a catch-22, I hope to start on the release process soon but things like
this add to the complexity and add to the time it takes.

> If we do this on PowerPC, then the SPE is no longer supported.

Joel has stated many times in talks I have seen that we follow the architectures
GCC supports and if one is removed we remove support.

Does this mean 5.1 is the last version of RTEMS to support SPE?
Should the specific BSPs be moved to tier 4 and marked for removal?

> On ARM a breaking change in compiler options is necessary.

What options are these?

Also this seems back to front to me. Should all hosts be on 9.2.0 and those that
cannot have specific versions?

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


Re: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV

2019-08-13 Thread Vaibhav Gupta
On Wed, Aug 14, 2019 at 4:04 AM Joel Sherrill  wrote:

>
>
> On Tue, Aug 13, 2019 at 5:09 PM Vaibhav Gupta 
> wrote:
>
>>
>>
>> On Mon, Aug 12, 2019 at 11:50 PM Joel Sherrill  wrote:
>>
>>> Can you post or email me privately the full patch? I can try to see what
>>> I spot.
>>>
>> I have sent you the patch.
>>
>>>
>>> Can you check with objdump or gdb that the methods which don't appear to
>>> work
>>> are actually the RISC-V implementation? Look at the disassembly and see
>>> if it
>>> looks like you expect.
>>>
>> I am exploring for this.
>>
>
> Since I don't know how to attach gdb to the new sis for griscv, I emailed
> Jiri privately.
> Your program works as expected on Linux. Perhaps Jiri has some advice for
> my
> debugging setup ignorance and fenv on RISC-V.
>
Okay, I will wait. Till then I can work with porting for other
architecture. :)

>
> Do you happen to have fenv support for another architecture queued up? It
> would be
> interesting to see if it works on other targets.
>
Yup, they were in my to do list. Till testsuite method is solved, I will
work on them now.

- Vaibhav Gupta

>
> --joel
>
>
>>
>> - Vaibhav Gupta
>>
>>>
>>> Does this require a patch to newlib as well?
>>>
>>> --joel
>>>
>>> On Sun, Aug 11, 2019 at 10:49 AM Vaibhav Gupta 
>>> wrote:
>>>
 Configure command I used to build BSP:
 ==
 $ /home/varodek/development/rtems/kernel/rtems/configure
 --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
 --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
 --enable-posix --disable-networking --enable-cxx 
 RISCV_ENABLE_HTIF_SUPPORT=1
 ==
 .
 .
 .
 .
 Qemu command I used to run test:
 ==
 $ qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M
 -kernel psxfenv01.exe
 ==
 .
 .
 .
 .
 Makefile.am
 ==
 + if TEST_psxfenv01
 + psx_tests += psxfenv01
 + psxfenv01_SOURCES = psxfenv01/init.c
 + psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
 +   $(support_includes)
 + psxfenv01_LDADD = -lm $(LDADD)
 + endif
 +
 ==

 On Sun, Aug 11, 2019 at 8:36 PM Vaibhav Gupta 
 wrote:

> My code of testsuite:
> ===
>   /* Test 'FE_DIVBYZERO' */
>   puts( "\nDivide by zero and confirm fetestexcept()." );
>   a = 0.0;
>   b = 1.0;
>   c = b/a;
>   printf("\n%d",FE_DIVBYZERO);
>   fegetexceptflag(,FE_ALL_EXCEPT);
>   printf("\n%d",excepts);
>   r = feraiseexcept(FE_DIVBYZERO);
>   printf("\n%d\n",r);
>   rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
> ==
> OUTPUT
> ==
> Divide by zero and confirm fetestexcept().
>
> 8
> 0
> 1
> /home/varodek/development/rtems/kernel/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:
> 84 fetestexcept( FE_DIVBYZERO )
> ==
> EXPECTED OUTPUT
> ==
> Divide by zero and confirm fetestexcept().
>
> 8
> 8
> 0
> ==
> - fetestexcept( FE_DIVBYZERO ), should return a non-zero value as
> division-by-zero was performed.
> .
> - feraiseexcept(FE_DIVBYZERO); is also not working. It should return
> zero when successful
> .
> ==
>
> Thank You
> Vaibhav Gupta
>
> ___
 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: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV

2019-08-13 Thread Joel Sherrill
On Tue, Aug 13, 2019 at 5:09 PM Vaibhav Gupta 
wrote:

>
>
> On Mon, Aug 12, 2019 at 11:50 PM Joel Sherrill  wrote:
>
>> Can you post or email me privately the full patch? I can try to see what
>> I spot.
>>
> I have sent you the patch.
>
>>
>> Can you check with objdump or gdb that the methods which don't appear to
>> work
>> are actually the RISC-V implementation? Look at the disassembly and see
>> if it
>> looks like you expect.
>>
> I am exploring for this.
>

Since I don't know how to attach gdb to the new sis for griscv, I emailed
Jiri privately.
Your program works as expected on Linux. Perhaps Jiri has some advice for my
debugging setup ignorance and fenv on RISC-V.

Do you happen to have fenv support for another architecture queued up? It
would be
interesting to see if it works on other targets.

--joel


>
> - Vaibhav Gupta
>
>>
>> Does this require a patch to newlib as well?
>>
>> --joel
>>
>> On Sun, Aug 11, 2019 at 10:49 AM Vaibhav Gupta 
>> wrote:
>>
>>> Configure command I used to build BSP:
>>> ==
>>> $ /home/varodek/development/rtems/kernel/rtems/configure
>>> --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
>>> --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
>>> --enable-posix --disable-networking --enable-cxx RISCV_ENABLE_HTIF_SUPPORT=1
>>> ==
>>> .
>>> .
>>> .
>>> .
>>> Qemu command I used to run test:
>>> ==
>>> $ qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M
>>> -kernel psxfenv01.exe
>>> ==
>>> .
>>> .
>>> .
>>> .
>>> Makefile.am
>>> ==
>>> + if TEST_psxfenv01
>>> + psx_tests += psxfenv01
>>> + psxfenv01_SOURCES = psxfenv01/init.c
>>> + psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
>>> +   $(support_includes)
>>> + psxfenv01_LDADD = -lm $(LDADD)
>>> + endif
>>> +
>>> ==
>>>
>>> On Sun, Aug 11, 2019 at 8:36 PM Vaibhav Gupta 
>>> wrote:
>>>
 My code of testsuite:
 ===
   /* Test 'FE_DIVBYZERO' */
   puts( "\nDivide by zero and confirm fetestexcept()." );
   a = 0.0;
   b = 1.0;
   c = b/a;
   printf("\n%d",FE_DIVBYZERO);
   fegetexceptflag(,FE_ALL_EXCEPT);
   printf("\n%d",excepts);
   r = feraiseexcept(FE_DIVBYZERO);
   printf("\n%d\n",r);
   rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
 ==
 OUTPUT
 ==
 Divide by zero and confirm fetestexcept().

 8
 0
 1
 /home/varodek/development/rtems/kernel/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:
 84 fetestexcept( FE_DIVBYZERO )
 ==
 EXPECTED OUTPUT
 ==
 Divide by zero and confirm fetestexcept().

 8
 8
 0
 ==
 - fetestexcept( FE_DIVBYZERO ), should return a non-zero value as
 division-by-zero was performed.
 .
 - feraiseexcept(FE_DIVBYZERO); is also not working. It should return
 zero when successful
 .
 ==

 Thank You
 Vaibhav Gupta

 ___
>>> 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: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV

2019-08-13 Thread Vaibhav Gupta
On Mon, Aug 12, 2019 at 11:50 PM Joel Sherrill  wrote:

> Can you post or email me privately the full patch? I can try to see what I
> spot.
>
I have sent you the patch.

>
> Can you check with objdump or gdb that the methods which don't appear to
> work
> are actually the RISC-V implementation? Look at the disassembly and see if
> it
> looks like you expect.
>
I am exploring for this.

- Vaibhav Gupta

>
> Does this require a patch to newlib as well?
>
> --joel
>
> On Sun, Aug 11, 2019 at 10:49 AM Vaibhav Gupta 
> wrote:
>
>> Configure command I used to build BSP:
>> ==
>> $ /home/varodek/development/rtems/kernel/rtems/configure
>> --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
>> --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
>> --enable-posix --disable-networking --enable-cxx RISCV_ENABLE_HTIF_SUPPORT=1
>> ==
>> .
>> .
>> .
>> .
>> Qemu command I used to run test:
>> ==
>> $ qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M -kernel
>> psxfenv01.exe
>> ==
>> .
>> .
>> .
>> .
>> Makefile.am
>> ==
>> + if TEST_psxfenv01
>> + psx_tests += psxfenv01
>> + psxfenv01_SOURCES = psxfenv01/init.c
>> + psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
>> +   $(support_includes)
>> + psxfenv01_LDADD = -lm $(LDADD)
>> + endif
>> +
>> ==
>>
>> On Sun, Aug 11, 2019 at 8:36 PM Vaibhav Gupta 
>> wrote:
>>
>>> My code of testsuite:
>>> ===
>>>   /* Test 'FE_DIVBYZERO' */
>>>   puts( "\nDivide by zero and confirm fetestexcept()." );
>>>   a = 0.0;
>>>   b = 1.0;
>>>   c = b/a;
>>>   printf("\n%d",FE_DIVBYZERO);
>>>   fegetexceptflag(,FE_ALL_EXCEPT);
>>>   printf("\n%d",excepts);
>>>   r = feraiseexcept(FE_DIVBYZERO);
>>>   printf("\n%d\n",r);
>>>   rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
>>> ==
>>> OUTPUT
>>> ==
>>> Divide by zero and confirm fetestexcept().
>>>
>>> 8
>>> 0
>>> 1
>>> /home/varodek/development/rtems/kernel/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:
>>> 84 fetestexcept( FE_DIVBYZERO )
>>> ==
>>> EXPECTED OUTPUT
>>> ==
>>> Divide by zero and confirm fetestexcept().
>>>
>>> 8
>>> 8
>>> 0
>>> ==
>>> - fetestexcept( FE_DIVBYZERO ), should return a non-zero value as
>>> division-by-zero was performed.
>>> .
>>> - feraiseexcept(FE_DIVBYZERO); is also not working. It should return
>>> zero when successful
>>> .
>>> ==
>>>
>>> Thank You
>>> Vaibhav Gupta
>>>
>>> ___
>> 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: Chapter/section numbers in document internal references

2019-08-13 Thread Gedare Bloom
Ok that seems good to me.

On Tue, Aug 13, 2019, 11:30 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> - Am 13. Aug 2019 um 19:05 schrieb Gedare Bloom ged...@gwmail.gwu.edu:
>
> > If you can make different rules for HTML than PDF, the Chapter part could
> > be omitted in HTML since one will expect the link to work. PDF should be
> > usable even without links.
> >
> > I'd change it to use for example "Chapter 3.3" format of
> Ch#.Sec#.subsec#.
> > this is more like a textbook reference then.
>
> I am in favour of the standard Sphinx latex_show_pagerefs option:
>
> https://lists.rtems.org/pipermail/devel/2019-August/027308.html
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Chapter/section numbers in document internal references

2019-08-13 Thread Sebastian Huber
- Am 13. Aug 2019 um 19:05 schrieb Gedare Bloom ged...@gwmail.gwu.edu:

> If you can make different rules for HTML than PDF, the Chapter part could
> be omitted in HTML since one will expect the link to work. PDF should be
> usable even without links.
> 
> I'd change it to use for example "Chapter 3.3" format of Ch#.Sec#.subsec#.
> this is more like a textbook reference then.

I am in favour of the standard Sphinx latex_show_pagerefs option:

https://lists.rtems.org/pipermail/devel/2019-August/027308.html
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


PRU libBSD shell command "pructl"

2019-08-13 Thread Nils Hölscher
Hi,

Last time we discussed about the PRU-Shell command, we decided it should be
realised as a libBSD shell command.
The reason was the driver being located in libBSD.

I tried developing the command in my App first.
But this would be more work, than just directly developing in libBSD.

So my questions are:
Where should I locate the libpru and pructl files?
Will be porting from these repos, they are actually programs for FreeBSD.
https://bitbucket.org/rpaulo/pructl/src/default/
https://bitbucket.org/rpaulo/libpru/src/default/

Also I would like to ask, where to register the command?
I saw the netcmds-config.h

and
similar files but I am not sure where the pructl command would go.

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

Re: [PATCH] user/index: Add myself to the list of copyrights

2019-08-13 Thread Sebastian Huber

On 13/08/2019 11:12, Christian Mauderer wrote:

Thanks for the patch. For everyone who didn't follow the previous
discussion: Gedare suggested that the copyright should be added here:
https://lists.rtems.org/pipermail/devel/2019-August/027204.html

Do we have a specific order in the copyright? Currently it seems to be
newest first.


https://git.rtems.org/rtems/tree/LICENSE.BSD-2-Clause#n20

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
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] user/index: Add myself to the list of copyrights

2019-08-13 Thread Christian Mauderer
Thanks for the patch. For everyone who didn't follow the previous
discussion: Gedare suggested that the copyright should be added here:
https://lists.rtems.org/pipermail/devel/2019-August/027204.html

Do we have a specific order in the copyright? Currently it seems to be
newest first.

Best regards

Christian

On 13/08/2019 10:15, Vijay Kumar Banerjee wrote:
> ---
>  user/index.rst | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/user/index.rst b/user/index.rst
> index eff85f3..0e644c9 100644
> --- a/user/index.rst
> +++ b/user/index.rst
> @@ -10,6 +10,7 @@ RTEMS User Manual (|version|).
>  
>  .. topic:: Copyrights and License
>  
> +| |copy| 2019 Vijay Kumar Banerjee
>  | |copy| 2018 Amaan Cheval
>  | |copy| 2018 Marçal Comajoan Cara
>  | |copy| 2018 Vidushi Vashishth
> 

-- 

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

[PATCH] user/index: Add myself to the list of copyrights

2019-08-13 Thread Vijay Kumar Banerjee
---
 user/index.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/user/index.rst b/user/index.rst
index eff85f3..0e644c9 100644
--- a/user/index.rst
+++ b/user/index.rst
@@ -10,6 +10,7 @@ RTEMS User Manual (|version|).
 
 .. topic:: Copyrights and License
 
+| |copy| 2019 Vijay Kumar Banerjee
 | |copy| 2018 Amaan Cheval
 | |copy| 2018 Marçal Comajoan Cara
 | |copy| 2018 Vidushi Vashishth
-- 
2.20.1

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