Re: Documentation image source

2020-10-07 Thread Chris Johns
On 8/10/20 5:30 pm, Sebastian Huber wrote: > On 08/10/2020 08:18, Chris Johns wrote: >> On 8/10/20 4:31 pm, Sebastian Huber wrote: >>> On 08/10/2020 03:01, Chris Johns wrote: >>> I see generated .png and .pdf for some images which I am questioning we need. The user document images I

[PATCH v2] rtems: Generate

2020-10-07 Thread Sebastian Huber
The manager documentation is a consolidation of the comments in Doxygen markup and the documentation sources in Sphinx markup. The documentation was transfered to interface specification items. This header file was generated from the items by a script. Change license to BSD-2-Clause according to

Re: Documentation image source

2020-10-07 Thread Sebastian Huber
On 08/10/2020 08:18, Chris Johns wrote: On 8/10/20 4:31 pm, Sebastian Huber wrote: On 08/10/2020 03:01, Chris Johns wrote: I see generated .png and .pdf for some images which I am questioning we need. The user document images I have contributed are only .png files so I am not sure why a PDF i

Re: [PATCH v2] rtems: Generate

2020-10-07 Thread Sebastian Huber
On 07/10/2020 21:12, Gedare Bloom wrote: On Wed, Oct 7, 2020 at 11:40 AM Sebastian Huber wrote: On 07/10/2020 17:26, Gedare Bloom wrote: Thinking about the discussion about ordering directives in the docs, the generated header reorders directives also. Is it also doing generation by alphabet

Re: Documentation image source

2020-10-07 Thread Chris Johns
On 8/10/20 4:31 pm, Sebastian Huber wrote: > On 08/10/2020 03:01, Chris Johns wrote: > >> I see generated .png and .pdf for some images which I am questioning we need. >> The user document images I have contributed are only .png files so I am not >> sure >> why a PDF is needed for some. > Images

[PATCH] grlib: Add and use irqmp_has_timestamp()

2020-10-07 Thread Sebastian Huber
Replace leon3_irqmp_has_timestamp() with irqmp_has_timestamp() and move it to grlib.h. Close #4128. --- bsps/riscv/griscv/clock/clockdrv.c | 2 +- bsps/shared/grlib/btimer/tlib_ckinit.c | 2 +- bsps/sparc/leon3/clock/ckinit.c| 4 ++-- bsps/sparc/leon3/include/leon.h| 7 ---

Re: Documentation image source

2020-10-07 Thread Sebastian Huber
On 08/10/2020 03:01, Chris Johns wrote: I see generated .png and .pdf for some images which I am questioning we need. The user document images I have contributed are only .png files so I am not sure why a PDF is needed for some. Images in a vector format is very important for a high quality PDF.

Re: [PATCH 1/2] rtems: Add "Generated from ..." comments

2020-10-07 Thread Chris Johns
On 8/10/20 2:18 pm, Joel Sherrill wrote: > On Wed, Oct 7, 2020, 10:14 PM Chris Johns > wrote: > On 7/10/20 9:14 pm, Sebastian Huber wrote: > > Improve file header comment. > > This is great. > > Agreed. I assume the spec: is defined somewhere. The patch has

Re: Documentation image source

2020-10-07 Thread Chris Johns
On 8/10/20 2:23 pm, Joel Sherrill wrote: > On Wed, Oct 7, 2020, 8:12 PM Chris Johns > wrote: > On 8/10/20 12:04 pm, Joel Sherrill wrote: > > On Wed, Oct 7, 2020, 8:01 PM Chris Johns > >

Re: Documentation image source

2020-10-07 Thread Joel Sherrill
On Wed, Oct 7, 2020, 8:12 PM Chris Johns wrote: > On 8/10/20 12:04 pm, Joel Sherrill wrote: > > On Wed, Oct 7, 2020, 8:01 PM Chris Johns > > wrote: > > > > Hi, > > > > In an update of my rtems-docs.git repo I noticed some new image > source formats: > > > > $

Re: [PATCH 1/2] rtems: Add "Generated from ..." comments

2020-10-07 Thread Joel Sherrill
On Wed, Oct 7, 2020, 10:14 PM Chris Johns wrote: > On 7/10/20 9:14 pm, Sebastian Huber wrote: > > Improve file header comment. > > This is great. > Agreed. I assume the spec: is defined somewhere. > > Thanks > Chris > ___ > devel mailing list > devel@

Re: [PATCH 1/2] rtems: Add "Generated from ..." comments

2020-10-07 Thread Chris Johns
On 7/10/20 9:14 pm, Sebastian Huber wrote: > Improve file header comment. This is great. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: Documentation image source

2020-10-07 Thread Chris Johns
On 8/10/20 12:04 pm, Joel Sherrill wrote: > On Wed, Oct 7, 2020, 8:01 PM Chris Johns > wrote: > > Hi, > > In an update of my rtems-docs.git repo I noticed some new image source > formats: > > $ find . -name \*.dot > ./images/eng/bld-bsp.dot > ./imag

Re: Documentation image source

2020-10-07 Thread Joel Sherrill
On Wed, Oct 7, 2020, 8:01 PM Chris Johns wrote: > Hi, > > In an update of my rtems-docs.git repo I noticed some new image source > formats: > > $ find . -name \*.dot > ./images/eng/bld-bsp.dot > ./images/eng/bld-deps2.dot > ./images/eng/bld-bsp2.dot > ./images/eng/bld-deps.dot > > Do we have a po

Documentation image source

2020-10-07 Thread Chris Johns
Hi, In an update of my rtems-docs.git repo I noticed some new image source formats: $ find . -name \*.dot ./images/eng/bld-bsp.dot ./images/eng/bld-deps2.dot ./images/eng/bld-bsp2.dot ./images/eng/bld-deps.dot Do we have a policy on what image source types can be used? Any additional image sourc

Re: [PATCH v2] rtems: Generate

2020-10-07 Thread Gedare Bloom
On Wed, Oct 7, 2020 at 11:40 AM Sebastian Huber wrote: > > On 07/10/2020 17:26, Gedare Bloom wrote: > > > Thinking about the discussion about ordering directives in the docs, > > the generated header reorders directives also. Is it also doing > > generation by alphabetical order? > > > > Should we

Re: [PATCH v2] rtems: Generate

2020-10-07 Thread Sebastian Huber
On 07/10/2020 17:26, Gedare Bloom wrote: Thinking about the discussion about ordering directives in the docs, the generated header reorders directives also. Is it also doing generation by alphabetical order? Should we consider using the same order as defined for the API documentation? I guess t

Re: Legacy networking stack removal

2020-10-07 Thread Joel Sherrill
On Wed, Oct 7, 2020 at 10:12 AM Christian Mauderer < christian.maude...@embedded-brains.de> wrote: > > On 07/10/2020 16:12, Joel Sherrill wrote: > > > > > > On Wed, Oct 7, 2020 at 6:30 AM Peter Dufault > > wrote: > > > > > > > > > On Oct 7, 2020, at 01:43 , Sebastian H

Re: [PATCH v2] rtems: Generate

2020-10-07 Thread Gedare Bloom
it would be good to review the generated doxygen. some comments below. overall a positive improvement. On Wed, Oct 7, 2020 at 4:19 AM Sebastian Huber wrote: > > The manager documentation is a consolidation of the comments in Doxygen > markup and the documentation sources in Sphinx markup. The >

Re: Legacy networking stack removal

2020-10-07 Thread Christian Mauderer
On 07/10/2020 16:12, Joel Sherrill wrote: > > > On Wed, Oct 7, 2020 at 6:30 AM Peter Dufault > wrote: > > > > > On Oct 7, 2020, at 01:43 , Sebastian Huber > > wrote: > > > > On 07/10/2020 02:07, Chris Joh

Re: BSP Build Sweep (7 Oct 2020)

2020-10-07 Thread Joel Sherrill
On Wed, Oct 7, 2020 at 9:01 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > > On 07/10/2020 15:54, Joel Sherrill wrote: > > x86_64 failures that Sebastian says should be fixed, > Someone has to say yes or no to the patch. > > and raspberry pi failures which are because Pi doesn't

Re: Legacy networking stack removal

2020-10-07 Thread Joel Sherrill
On Wed, Oct 7, 2020 at 6:30 AM Peter Dufault wrote: > > > > On Oct 7, 2020, at 01:43 , Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > > > > On 07/10/2020 02:07, Chris Johns wrote: > > > >> On 7/10/20 10:21 am, Joel Sherrill wrote: > >>> On Tue, Oct 6, 2020, 6:16 PM Chris Johns

Re: BSP Build Sweep (7 Oct 2020)

2020-10-07 Thread Sebastian Huber
On 07/10/2020 15:54, Joel Sherrill wrote: x86_64 failures that Sebastian says should be fixed, Someone has to say yes or no to the patch. and raspberry pi failures which are because Pi doesn't support SMP. This should be fixed. That still leaves 43 failures to account for. About half of th

BSP Build Sweep (7 Oct 2020)

2020-10-07 Thread Joel Sherrill
Hi Results from the sweep that just finished. It is clear that since this takes ~42 hours to run that it tends to have failures which were fixed in the almost 2 days it takes for this to finish. Total: 1744 all-bsps-log.txt Passed: 1657 Failed: 87 Failed autoconf: 60 Failed waf: 27 Fa

Re: Legacy networking stack removal

2020-10-07 Thread Sebastian Huber
On 07/10/2020 13:29, Peter Dufault wrote: On Oct 7, 2020, at 01:43 , Sebastian Huber wrote: On 07/10/2020 02:07, Chris Johns wrote: On 7/10/20 10:21 am, Joel Sherrill wrote: On Tue, Oct 6, 2020, 6:16 PM Chris Johns mailto:chr...@rtems.org>> wrote: What is the life span of the legacy

Re: [PATCH v2] build: Disable RTEMS_NETWORKING for some arch/bsp

2020-10-07 Thread Joel Sherrill
This seems reasonable until we can remove it. On Wed, Oct 7, 2020 at 2:29 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > The old network stack is not supported on 64-bit targets. > --- > v2: > > Add sparc64 to black list. > > spec/build/cpukit/optnet.yml | 13 - >

Re: BSP Count (rtems-bsps, autoconf, and waf)

2020-10-07 Thread Joel Sherrill
On Wed, Oct 7, 2020 at 8:18 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 07/10/2020 14:57, Joel Sherrill wrote: > > > How is clang vs gcc done in waf? > > It is a configuration option: > > # Selects the compiler used to build the BSP (allowed values are "gcc" and > # "clang

Re: BSP Count (rtems-bsps, autoconf, and waf)

2020-10-07 Thread Sebastian Huber
On 07/10/2020 14:57, Joel Sherrill wrote: How is clang vs gcc done in waf? It is a configuration option: # Selects the compiler used to build the BSP (allowed values are "gcc" and # "clang").  Please note that the values of some options depend on the compiler # selection and changing the co

Re: BSP Count (rtems-bsps, autoconf, and waf)

2020-10-07 Thread Joel Sherrill
On Wed, Oct 7, 2020 at 1:07 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Here is the difference: > > --- old 2020-10-07 08:01:12.249050086 +0200 > +++ new 2020-10-07 08:00:51.436897826 +0200 > @@ -1,6 +1,7 @@ > +aarch64/a53_ilp32_qemu > +aarch64/a53_lp64_qemu > arm/altcycv_d

Re: Legacy networking stack removal

2020-10-07 Thread Peter Dufault
> On Oct 7, 2020, at 01:43 , Sebastian Huber > wrote: > > On 07/10/2020 02:07, Chris Johns wrote: > >> On 7/10/20 10:21 am, Joel Sherrill wrote: >>> On Tue, Oct 6, 2020, 6:16 PM Chris Johns >> > wrote: >>> >>> What is the life span of the legacy stack in rtems.gi

[PATCH v2] rtems: Generate

2020-10-07 Thread Sebastian Huber
The manager documentation is a consolidation of the comments in Doxygen markup and the documentation sources in Sphinx markup. The documentation was transfered to interface specification items. This header file was generated from the items by a script. Change license to BSD-2-Clause according to

[PATCH 2/2] doxygen: Add "Generated from ..." comments

2020-10-07 Thread Sebastian Huber
Improve file header comment. Update #3994. --- cpukit/doxygen/appl-config.h | 343 ++- 1 file changed, 339 insertions(+), 4 deletions(-) diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h index eb9bf72abf..fe567b6e0f 100644 --- a/cpukit/doxyg

[PATCH 1/2] rtems: Add "Generated from ..." comments

2020-10-07 Thread Sebastian Huber
Improve file header comment. Update #3993. --- cpukit/include/rtems.h | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/cpukit/include/rtems.h b/cpukit/include/rtems.h index cda2bd5b24..9b0765efda 100644 --- a/cpukit/include/rtems.h +++ b/cpukit/include/rtems.

[PATCH v2] build: Disable RTEMS_NETWORKING for some arch/bsp

2020-10-07 Thread Sebastian Huber
The old network stack is not supported on 64-bit targets. --- v2: Add sparc64 to black list. spec/build/cpukit/optnet.yml | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/spec/build/cpukit/optnet.yml b/spec/build/cpukit/optnet.yml index 8678c8dbb8..8a223423ad 100

Re: [PATCH] build: Disable RTEMS_NETWORKING for some arch/bsp

2020-10-07 Thread Gedare Bloom
disable it for the sparc64 too please. thanks On Tue, Oct 6, 2020 at 11:52 PM Sebastian Huber wrote: > > The old network stack is not supported on 64-bit targets. > --- > spec/build/cpukit/optnet.yml | 12 +++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/spec/build