RE: [PATCH v1 1/1] bsps/pc386: Fix IPI for non-consecutive APICIDs

2020-07-07 Thread Jan.Sommer 
Hello, 

Could someone please push this patch to the branches 5 and master?
Or do I need a ticket for the 5 branch first?

Cheers,

   Jan

> -Original Message-
> From: Sommer, Jan
> Sent: Friday, July 3, 2020 2:32 PM
> To: devel@rtems.org
> Cc: Sommer, Jan
> Subject: [PATCH v1 1/1] bsps/pc386: Fix IPI for non-consecutive APICIDs
> 
> - properly use the cpu <-> apic maps for IPIs
> ---
>  bsps/i386/pc386/start/smp-imps.c | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/bsps/i386/pc386/start/smp-imps.c b/bsps/i386/pc386/start/smp-
> imps.c
> index 0985b8f08f..763ac0afc7 100644
> --- a/bsps/i386/pc386/start/smp-imps.c
> +++ b/bsps/i386/pc386/start/smp-imps.c
> @@ -226,9 +226,11 @@ get_checksum(unsigned start, int length)
>  int
>  send_ipi(unsigned int dst, unsigned int v)
>  {
> -  int to, send_status;
> +  int to, send_status, apicid;
> 
> -  IMPS_LAPIC_WRITE(LAPIC_ICR+0x10, (dst << 24));
> +  apicid = imps_cpu_apic_map[dst];
> +
> +  IMPS_LAPIC_WRITE(LAPIC_ICR+0x10, (apicid << 24));
>IMPS_LAPIC_WRITE(LAPIC_ICR, v);
> 
>/* Wait for send to finish */
> @@ -251,9 +253,11 @@ static int
>  boot_cpu(imps_processor *proc)
>  {
>int apicid = proc->apic_id, success = 1;
> +  int cpuid;
>unsigned bootaddr;
>unsigned bios_reset_vector = PHYS_TO_VIRTUAL(BIOS_RESET_VECTOR);
> 
> +  cpuid = imps_apic_cpu_map[apicid];
>/*
> * Copy boot code for secondary CPUs here.  Find it in between
> * "patch_code_start" and "patch_code_end" symbols.  The other CPUs
> @@ -276,7 +280,7 @@ boot_cpu(imps_processor *proc)
>/* Pass start function, stack region and gdtdescr to AP
> * see startAP.S for location */
>reset[1] = (uint32_t)secondary_cpu_initialize;
> -  reset[2] = (uint32_t)_Per_CPU_Get_by_index(apicid)-
> >interrupt_stack_high;
> +  reset[2] = (uint32_t)_Per_CPU_Get_by_index(cpuid)-
> >interrupt_stack_high;
>memcpy(
>   (char*) &reset[3],
>   &gdtdesc,
> @@ -295,13 +299,13 @@ boot_cpu(imps_processor *proc)
> 
>/* assert INIT IPI */
>send_ipi(
> -apicid,
> +cpuid,
>  LAPIC_ICR_TM_LEVEL | LAPIC_ICR_LEVELASSERT | LAPIC_ICR_DM_INIT
>);
>UDELAY(1);
> 
>/* de-assert INIT IPI */
> -  send_ipi(apicid, LAPIC_ICR_TM_LEVEL | LAPIC_ICR_DM_INIT);
> +  send_ipi(cpuid, LAPIC_ICR_TM_LEVEL | LAPIC_ICR_DM_INIT);
> 
>UDELAY(1);
> 
> @@ -312,7 +316,7 @@ boot_cpu(imps_processor *proc)
>if (proc->apic_ver >= APIC_VER_NEW) {
>  int i;
>  for (i = 1; i <= 2; i++) {
> -  send_ipi(apicid, LAPIC_ICR_DM_SIPI | ((bootaddr >> 12) & 0xFF));
> +  send_ipi(cpuid, LAPIC_ICR_DM_SIPI | ((bootaddr >> 12) & 0xFF));
>UDELAY(1000);
>  }
>}
> --
> 2.17.1

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

Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

2020-07-07 Thread Christian Mauderer 
On 08/07/2020 08:35, Niteesh G. S. wrote:
> On Wed, Jul 8, 2020 at 11:52 AM Christian Mauderer
>  > wrote:
> 
> On 08/07/2020 08:13, Sebastian Huber wrote:
> > On 08/07/2020 08:10, Niteesh G. S. wrote:
> >
> >> On Tue, Jul 7, 2020 at 10:42 AM Sebastian Huber
> >>  
> >>  >> wrote:
> >>
> >>     Hello,
> >>
> >>     the problem is that the new build system doesn't export
> optimization
> >>     flags such as -Wl,--gc-sections. The libbsd build should
> enable this
> >>     linker option unconditionally.
> >>
> >>
> >> Thank you. I got it fixed (temporarily) by modifying rtems.py.
> >>
> >> conf.env.CFLAGS    = cflags['cflags'] + ['-ffunction-sections'] +
> >> ['-fdata-sections']
> > This instructs the compiler to add data elements and functions into
> > separate sections. This is necessary so that the linker can carry out
> > the garbage collection.
> 
> There is an unused function in libbsd that can't link because a function
> it calls isn't there. Till now the two flags had been provided by the
> BSP. It seems that now they are not provided anymore.
> 
> The problematic function is m_unmappedtouio in uipc_mbuf.c. It tries to
> use PHYS_TO_VM_PAGE which isn't defined in libbsd. I think we should
> just remove m_unmappedtouio (with #ifndef __rtems__) on the longer term.
> But not having the -ffunction-sections and -fdata-sections most likely
> makes our binary bigger and maybe leads to other similar bugs. Therefore
> I suggested to add the CFLAGS first.
> 
> >>
> >> As per Christian suggestions, I tried exporting CFLAGS with these GCC
> >> flags and then calling ./waf configure but they didn't work.
> > You have to add -Wl,--gc-sections to the linker flags.
> 
> As far as I know Niteesh used that one too. I think for that one LDFLAGS
> worked as a workarround.
> 
>  
> Yes, I did try exporting LDFLAGS too but they also didn't work out.
> I tried the following:
> 1) export LDFLAGS="-Wl,--gc-sections"
> 2) ./waf configure --prefix=$RTEMS/6 --rtems-version=6
> --rtems-bsps=arm/beagleboneblack --buildset=buildset/minimal.ini
> I also tried running
> 1) LDFLAGS="-Wl,--gc-sections" ./waf configure --prefix=$RTEMS/6
> --rtems-version=6 --rtems-bsps=arm/beagleboneblack
> --buildset=buildset/minimal.ini
> Both of them didn't work out.

Have the flags been ignored and not used or did that not fix the
problem? I would assume the second. You should see the difference if you
call "./waf -v" and take a look at one of the linker calls to generate
the test applications.

> 
> I might be wrong here but waf seems to add the "-Wl,--gc-sections"
> flags if "--function-sections" flags are defined.
> https://git.rtems.org/rtems_waf/tree/rtems.py#n389
> 

That's a bit odd. I don't think that I ever used that flag. But you are
right: If CFLAGS contains the -function-section (only one -),
"-Wl,--gc-sections" is added to the LDFLAGS here.

>  
> 
> Best regards
> 
> Christian
> -- 
> 
> 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.
> 

-- 

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: NEW BUILD SYSTEM: Cannot build rtems-libbsd

2020-07-07 Thread Niteesh G. S. 
On Wed, Jul 8, 2020 at 11:52 AM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> On 08/07/2020 08:13, Sebastian Huber wrote:
> > On 08/07/2020 08:10, Niteesh G. S. wrote:
> >
> >> On Tue, Jul 7, 2020 at 10:42 AM Sebastian Huber
> >>  >> > wrote:
> >>
> >> Hello,
> >>
> >> the problem is that the new build system doesn't export optimization
> >> flags such as -Wl,--gc-sections. The libbsd build should enable this
> >> linker option unconditionally.
> >>
> >>
> >> Thank you. I got it fixed (temporarily) by modifying rtems.py.
> >>
> >> conf.env.CFLAGS= cflags['cflags'] + ['-ffunction-sections'] +
> >> ['-fdata-sections']
> > This instructs the compiler to add data elements and functions into
> > separate sections. This is necessary so that the linker can carry out
> > the garbage collection.
>
> There is an unused function in libbsd that can't link because a function
> it calls isn't there. Till now the two flags had been provided by the
> BSP. It seems that now they are not provided anymore.
>
> The problematic function is m_unmappedtouio in uipc_mbuf.c. It tries to
> use PHYS_TO_VM_PAGE which isn't defined in libbsd. I think we should
> just remove m_unmappedtouio (with #ifndef __rtems__) on the longer term.
> But not having the -ffunction-sections and -fdata-sections most likely
> makes our binary bigger and maybe leads to other similar bugs. Therefore
> I suggested to add the CFLAGS first.
>
> >>
> >> As per Christian suggestions, I tried exporting CFLAGS with these GCC
> >> flags and then calling ./waf configure but they didn't work.
> > You have to add -Wl,--gc-sections to the linker flags.
>
> As far as I know Niteesh used that one too. I think for that one LDFLAGS
> worked as a workarround.
>

Yes, I did try exporting LDFLAGS too but they also didn't work out.
I tried the following:
1) export LDFLAGS="-Wl,--gc-sections"
2) ./waf configure --prefix=$RTEMS/6 --rtems-version=6
--rtems-bsps=arm/beagleboneblack --buildset=buildset/minimal.ini
I also tried running
1) LDFLAGS="-Wl,--gc-sections" ./waf configure --prefix=$RTEMS/6
--rtems-version=6 --rtems-bsps=arm/beagleboneblack
--buildset=buildset/minimal.ini
Both of them didn't work out.

I might be wrong here but waf seems to add the "-Wl,--gc-sections"
flags if "--function-sections" flags are defined.
https://git.rtems.org/rtems_waf/tree/rtems.py#n389



> Best regards
>
> Christian
> --
> 
> 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: NEW BUILD SYSTEM: Cannot build rtems-libbsd

2020-07-07 Thread Christian Mauderer 
On 08/07/2020 08:13, Sebastian Huber wrote:
> On 08/07/2020 08:10, Niteesh G. S. wrote:
> 
>> On Tue, Jul 7, 2020 at 10:42 AM Sebastian Huber
>> > > wrote:
>>
>>     Hello,
>>
>>     the problem is that the new build system doesn't export optimization
>>     flags such as -Wl,--gc-sections. The libbsd build should enable this
>>     linker option unconditionally.
>>
>>
>> Thank you. I got it fixed (temporarily) by modifying rtems.py.
>>
>> conf.env.CFLAGS    = cflags['cflags'] + ['-ffunction-sections'] +
>> ['-fdata-sections']
> This instructs the compiler to add data elements and functions into
> separate sections. This is necessary so that the linker can carry out
> the garbage collection.

There is an unused function in libbsd that can't link because a function
it calls isn't there. Till now the two flags had been provided by the
BSP. It seems that now they are not provided anymore.

The problematic function is m_unmappedtouio in uipc_mbuf.c. It tries to
use PHYS_TO_VM_PAGE which isn't defined in libbsd. I think we should
just remove m_unmappedtouio (with #ifndef __rtems__) on the longer term.
But not having the -ffunction-sections and -fdata-sections most likely
makes our binary bigger and maybe leads to other similar bugs. Therefore
I suggested to add the CFLAGS first.

>>
>> As per Christian suggestions, I tried exporting CFLAGS with these GCC
>> flags and then calling ./waf configure but they didn't work.
> You have to add -Wl,--gc-sections to the linker flags.

As far as I know Niteesh used that one too. I think for that one LDFLAGS
worked as a workarround.

Best regards

Christian
-- 

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: NEW BUILD SYSTEM: Cannot build rtems-libbsd

2020-07-07 Thread Sebastian Huber 

On 08/07/2020 08:10, Niteesh G. S. wrote:

On Tue, Jul 7, 2020 at 10:42 AM Sebastian Huber 
> wrote:


Hello,

the problem is that the new build system doesn't export optimization
flags such as -Wl,--gc-sections. The libbsd build should enable this
linker option unconditionally.


Thank you. I got it fixed (temporarily) by modifying rtems.py.

conf.env.CFLAGS    = cflags['cflags'] + ['-ffunction-sections'] + 
['-fdata-sections']
This instructs the compiler to add data elements and functions into 
separate sections. This is necessary so that the linker can carry out 
the garbage collection.


As per Christian suggestions, I tried exporting CFLAGS with these GCC
flags and then calling ./waf configure but they didn't work.

You have to add -Wl,--gc-sections to the linker flags.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

2020-07-07 Thread Niteesh G. S. 
Hello,
On Tue, Jul 7, 2020 at 10:42 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> the problem is that the new build system doesn't export optimization
> flags such as -Wl,--gc-sections. The libbsd build should enable this
> linker option unconditionally.
>

Thank you. I got it fixed (temporarily) by modifying rtems.py.

conf.env.CFLAGS= cflags['cflags'] + ['-ffunction-sections'] +
['-fdata-sections']

As per Christian suggestions, I tried exporting CFLAGS with these GCC
flags and then calling ./waf configure but they didn't work.

Thanks,
Niteesh




> --
> 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 0/1] Generate application configuration option documentation

2020-07-07 Thread Sebastian Huber 

On 08/07/2020 07:35, Sebastian Huber wrote:



It seems to me the key is the central repo and how it functions, how 
easy or
hard it is to learn about it and how well it will work in practice. A 
key
concern is taking it from a single person repo, ie you, to a project 
wide repo
with concurrent updates ad lots of moving pieces. It is easy to ask 
these
questions and I appreciate they are not all easy to answer but I 
think we need

to try.
My approach would be to document common tasks for the every day RTEMS 
maintenance:


https://docs.rtems.org/branches/master/eng/req/howto.html

You also have to consider the future rate of change. The API parts, 
application configuration options, and glossary terms for example are 
all things which don't change every week. 
We have a new employee since last week. He has no RTEMS, embedded 
system, ECSS, and ESA experience. He should help me with the 
pre-qualification work. My approach would be to document the tasks in 
the howto section of the RTEMS Software Engineering manual and try to 
avoid instructions in person. This should help to work out documentation 
relevant for the RTEMS maintenance which is understandable for newcomers.

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

Re: [PATCH 0/1] Generate application configuration option documentation

2020-07-07 Thread Sebastian Huber 

[It seems Thunderbird misformatted the e-mail, maybe this one looks better.]

Hello Chris,


thanks for the detailed response.

On 08/07/2020 03:55, Chris Johns wrote:

Hi Sebastian,

Thank you for this patch. I am sorry but I would like to see this 
central repo
issue resolved before any generated files are added to any of the 
project's repos.


I understand to some level the path you are taking and moving along 
but these
generated files are coming from a personal repo that has changes, 
processes and
tools that are not being reviewed. I think it would be wise for us to 
agree on

what is behind all this before we agree to what is being generated.


I rescheduled some work to be able to provide this patch earlier. Richi 
Dubey asked a couple of questions with respect to the scheduler 
implementation and some of them are related to how application 
configuration options define internal scheduler data structures. So, It 
would be nice to be able to reference them in Doxygen. You can review 
this patch independent from the way it is produced.




On 7/7/20 9:25 pm, Sebastian Huber wrote:
This patch adds the application configuration option documentation 
generated

from specification items:

https://git.rtems.org/sebh/rtems-qual.git/tree/spec/if/acfg
 That is a lot of files. I am not sure I am ready to accept 
documentation

as a lot of small files. I am happy to be persuaded otherwise.

It is not clear to me if these YAML files generate documentation, 
headers, are

requirements or something else.


Each application configuration option and group is provided as a 
separate specification item (YAML file). The type of the specification 
items is documented here:


https://docs.rtems.org/branches/master/eng/req/items.html

https://docs.rtems.org/branches/master/eng/req/items.html#spectypeapplicationconfigurationoptionitemtype

Application configuration options are things on their own, so they have 
their own items. This enables other items to reference application 
configuration options. In the manual you have now a lot more cross 
references for example if you compare it with the RTEMS 4.11 
documentation. Items have their own history and can be reviewed 
individually. I see this as benefits.



There is nothing I can see in them that defines
their `role` or `roles`.


When you look at an item

https://git.rtems.org/sebh/rtems-qual.git/tree/spec/if/acfg/message-buffer-memory.yml

you see attributes like

type: interface

interface-type: appl-config-option

appl-config-option-type: integer

This defines the type of an item. I corresponds to the specification 
type refinement:


https://docs.rtems.org/branches/master/eng/req/items.html#spectyperootitemtype

https://docs.rtems.org/branches/master/eng/req/items.html#spectypeinterfaceitemtype

https://docs.rtems.org/branches/master/eng/req/items.html#spectypeapplicationconfigurationoptionitemtype

https://docs.rtems.org/branches/master/eng/req/items.html#spectypeapplicationconfigurationvalueoptionitemtype

All attributes and the value types are defined by specification item 
types. The specification item types are defined by specification items:


https://git.rtems.org/sebh/rtems-qual.git/tree/spec/spec

The type information is used to generate the documentation in the RTEMS 
Software Engineering manual and is used to verify that the items are in 
line with the type specification:


https://git.rtems.org/sebh/rtems-qual.git/tree/specverify.py



If they do generate files how does that happen and how
are those generated header files related to the C code they are an 
interface

for?


The Doxygen header file of this patch is not read by the C compiler. 
However, I would like to generate also the API header files from 
specification items. I am now able to generate  and all header 
files included by this header which define API elements. About 585 items 
describe the API defined by :


https://git.rtems.org/sebh/rtems-qual.git/tree/spec/if/rtems

This item describes rtems_semaphore_create():

https://git.rtems.org/sebh/rtems-qual.git/tree/spec/if/rtems/sem/create.yml

It is worth to have a closer look at this item.

The interface specification items can be used to generate the header 
files with Doxygen markup, Sphinx sources for the manuals, and an 
Interface Control Document (ICD, a document required by ECSS).



How do I keep each piece in sync?
The basic work flow would be to update an item, then call one or more 
scripts, run make or ./waf, or whatever, to generate the derived 
content. This will alter the state of Git submodules. Then you create 
patch sets from the changes in the submodules and send them for review. 
After acceptance you push the changes and update the submodules.

A compile error seems a long way from one
of these YAML files.
Yes, this is a bit harder to correlate. I don't think this will be a 
real issue. It is for example easy to figure out with "grep" which item 
is relevant.


For example, if I was to add a YAML file to this directory

Re: [PATCH 0/1] Generate application configuration option documentation

2020-07-07 Thread Sebastian Huber 

Hello Chris,

thanks for the detailed response.

On 08/07/2020 03:55, Chris Johns wrote:

Hi Sebastian,

Thank you for this patch. I am sorry but I would like to see this central repo
issue resolved before any generated files are added to any of the project's 
repos.

I understand to some level the path you are taking and moving along but these
generated files are coming from a personal repo that has changes, processes and
tools that are not being reviewed. I think it would be wise for us to agree on
what is behind all this before we agree to what is being generated.


I rescheduled some work to be able to provide this patch earlier. Richi 
Dubey asked a couple of questions with respect to the scheduler 
implementation and some of them are related to how application 
configuration options define internal scheduler data structures. So, It 
would be nice to be able to reference them in Doxygen. You can review 
this patch independent from the way it is produced.




On 7/7/20 9:25 pm, Sebastian Huber wrote:

This patch adds the application configuration option documentation generated
from specification items:

https://git.rtems.org/sebh/rtems-qual.git/tree/spec/if/acfg

 That is a lot of files. I am not sure I am ready to accept documentation
as a lot of small files. I am happy to be persuaded otherwise.

It is not clear to me if these YAML files generate documentation, headers, are
requirements or something else.


Each application configuration option and group is provided as a 
separate specification item (YAML file). The type of the specification 
items is documented here:


https://docs.rtems.org/branches/master/eng/req/items.html

https://docs.rtems.org/branches/master/eng/req/items.html#spectypeapplicationconfigurationoptionitemtype

Application configuration options are things on their own, so they have 
their own items. This enables other items to reference application 
configuration options. In the manual you have now a lot more cross 
references for example if you compare it with the RTEMS 4.11 
documentation. Items have their own history and can be reviewed 
individually. I see this as benefits.



There is nothing I can see in them that defines
their `role` or `roles`.


When you look at an item

https://git.rtems.org/sebh/rtems-qual.git/tree/spec/if/acfg/message-buffer-memory.yml

you see attributes like

|type: interface ||interface-type: appl-config-option ||appl-config-option-type: integer This defines the type of an item. I 
corresponds to the specification type refinement: 
https://docs.rtems.org/branches/master/eng/req/items.html#spectyperootitemtype 
https://docs.rtems.org/branches/master/eng/req/items.html#spectypeinterfaceitemtype 
https://docs.rtems.org/branches/master/eng/req/items.html#spectypeapplicationconfigurationoptionitemtype 
https://docs.rtems.org/branches/master/eng/req/items.html#spectypeapplicationconfigurationvalueoptionitemtype 
All attributes and the value types are defined by specification item 
types. The specification item types are defined by specification items: 
https://git.rtems.org/sebh/rtems-qual.git/tree/spec/spec The type 
information is used to generate the documentation in the RTEMS Software 
Engineering manual and is used to verify that the items are in line with 
the type specification: 
https://git.rtems.org/sebh/rtems-qual.git/tree/specverify.py |



If they do generate files how does that happen and how
are those generated header files related to the C code they are an interface
for?


The Doxygen header file of this patch is not read by the C compiler. 
However, I would like to generate also the API header files from 
specification items. I am now able to generate  and all header 
files included by this header which define API elements. About 585 items 
describe the API defined by :


https://git.rtems.org/sebh/rtems-qual.git/tree/spec/if/rtems

This item describes rtems_semaphore_create():

https://git.rtems.org/sebh/rtems-qual.git/tree/spec/if/rtems/sem/create.yml

It is worth to have a closer look at this item.

The interface specification items can be used to generate the header 
files with Doxygen markup, Sphinx sources for the manuals, and an 
Interface Control Document (ICD, a document required by ECSS).



How do I keep each piece in sync?
The basic work flow would be to update an item, then call one or more 
scripts, run make or ./waf, or whatever, to generate the derived 
content. This will alter the state of Git submodules. Then you create 
patch sets from the changes in the submodules and send them for review. 
After acceptance you push the changes and update the submodules.

A compile error seems a long way from one
of these YAML files.
Yes, this is a bit harder to correlate. I don't think this will be a 
real issue. It is for example easy to figure out with "grep" which item 
is relevant.


For example, if I was to add a YAML file to this directory I have no idea where
I look to find the naming, what roles are assumed, how it integr

Re: [PATCH] Use *.md extension for the release notes

2020-07-07 Thread Chris Johns 
OK to push.

On 8/7/20 2:37 pm, Sebastian Huber wrote:
> ---
>  rtems-notes-5.txt => rtems-notes-5.md | 0
>  rtems-notes-6.txt => rtems-notes-6.md | 0
>  rtems-release | 4 ++--
>  3 files changed, 2 insertions(+), 2 deletions(-)
>  rename rtems-notes-5.txt => rtems-notes-5.md (100%)
>  rename rtems-notes-6.txt => rtems-notes-6.md (100%)
> 
> diff --git a/rtems-notes-5.txt b/rtems-notes-5.md
> similarity index 100%
> rename from rtems-notes-5.txt
> rename to rtems-notes-5.md
> diff --git a/rtems-notes-6.txt b/rtems-notes-6.md
> similarity index 100%
> rename from rtems-notes-6.txt
> rename to rtems-notes-6.md
> diff --git a/rtems-release b/rtems-release
> index b66ace3..86fa36d 100755
> --- a/rtems-release
> +++ b/rtems-release
> @@ -101,8 +101,8 @@ release=${version}.${revision}
>  #
>  # Does the release provide release notes?
>  #
> -if [ -f rtems-notes-${version}.txt ]; then
> - rtems_readme_release_notes=rtems-notes-${version}.txt
> +if [ -f rtems-notes-${version}.md ]; then
> + rtems_readme_release_notes=rtems-notes-${version}.md
>  fi
>  
>  #
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] common: Remove probably superfluous import

2020-07-07 Thread Chris Johns 
On 8/7/20 2:33 pm, Sebastian Huber wrote:
> On 08/07/2020 03:11, Chris Johns wrote:
> 
>> On 7/7/20 3:29 pm, Sebastian Huber wrote:
>>> The purpose of this import is unclear.
>>>
>>> This import caused the following error with Sphinx 3.0:
>>>
>>> Extension error:
>>> Could not import extension rtemsdomain (exception: cannot import name 'l_')
>>> ---
>>>   common/rtemsdomain.py | 1 -
>>>   1 file changed, 1 deletion(-)
>>>
>>> diff --git a/common/rtemsdomain.py b/common/rtemsdomain.py
>>> index 49d0728..9b092a3 100644
>>> --- a/common/rtemsdomain.py
>>> +++ b/common/rtemsdomain.py
>>> @@ -3,7 +3,6 @@ from docutils.parsers.rst import directives
>>>     from sphinx import addnodes
>>>   from sphinx.roles import XRefRole
>>> -from sphinx.locale import l_, _
>> Is this backwards compatible?
> It seems to work also with Sphinx 2.4. I didn't find uses of "l_" and "_" in 
> the
> file.

Great and thanks for checking.

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

[PATCH] Use *.md extension for the release notes

2020-07-07 Thread Sebastian Huber 
---
 rtems-notes-5.txt => rtems-notes-5.md | 0
 rtems-notes-6.txt => rtems-notes-6.md | 0
 rtems-release | 4 ++--
 3 files changed, 2 insertions(+), 2 deletions(-)
 rename rtems-notes-5.txt => rtems-notes-5.md (100%)
 rename rtems-notes-6.txt => rtems-notes-6.md (100%)

diff --git a/rtems-notes-5.txt b/rtems-notes-5.md
similarity index 100%
rename from rtems-notes-5.txt
rename to rtems-notes-5.md
diff --git a/rtems-notes-6.txt b/rtems-notes-6.md
similarity index 100%
rename from rtems-notes-6.txt
rename to rtems-notes-6.md
diff --git a/rtems-release b/rtems-release
index b66ace3..86fa36d 100755
--- a/rtems-release
+++ b/rtems-release
@@ -101,8 +101,8 @@ release=${version}.${revision}
 #
 # Does the release provide release notes?
 #
-if [ -f rtems-notes-${version}.txt ]; then
- rtems_readme_release_notes=rtems-notes-${version}.txt
+if [ -f rtems-notes-${version}.md ]; then
+ rtems_readme_release_notes=rtems-notes-${version}.md
 fi
 
 #
-- 
2.26.2

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

Re: [PATCH] common: Remove probably superfluous import

2020-07-07 Thread Sebastian Huber 

On 08/07/2020 03:11, Chris Johns wrote:


On 7/7/20 3:29 pm, Sebastian Huber wrote:

The purpose of this import is unclear.

This import caused the following error with Sphinx 3.0:

Extension error:
Could not import extension rtemsdomain (exception: cannot import name 'l_')
---
  common/rtemsdomain.py | 1 -
  1 file changed, 1 deletion(-)

diff --git a/common/rtemsdomain.py b/common/rtemsdomain.py
index 49d0728..9b092a3 100644
--- a/common/rtemsdomain.py
+++ b/common/rtemsdomain.py
@@ -3,7 +3,6 @@ from docutils.parsers.rst import directives
  
  from sphinx import addnodes

  from sphinx.roles import XRefRole
-from sphinx.locale import l_, _

Is this backwards compatible?
It seems to work also with Sphinx 2.4. I didn't find uses of "l_" and 
"_" in the file.

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

Re: [PATCH 1/2] c-user: Avoid Sphinx-specifics in appl config

2020-07-07 Thread Chris Johns 
On 7/7/20 9:06 pm, Sebastian Huber wrote:
> This helps to generate Doxygen markup from the application configuration
> option specification items.

I do not understand this and the second part of this patch. I am suspicious this
is introducing constraints on what we can use in the documentation.

Maybe the relationships that are happening here, the constraints if there are
any, and reasons we need to have them are discussed in relation to the central
repo to save having more than one thread on this topic.

Thanks
Chris

> 
> Update #3994.
> ---
>  c-user/config/bsp-related.rst   |  8 ++--
>  c-user/config/classic-api.rst   | 63 -
>  c-user/config/classic-init-task.rst |  2 +-
>  c-user/config/device-driver.rst | 26 ++--
>  c-user/config/filesystem.rst| 28 ++---
>  c-user/config/general.rst   | 12 +++---
>  c-user/config/mpci.rst  |  2 +-
>  c-user/config/posix-api.rst | 52 +---
>  c-user/config/scheduler-general.rst |  6 +--
>  9 files changed, 107 insertions(+), 92 deletions(-)
> 
> diff --git a/c-user/config/bsp-related.rst b/c-user/config/bsp-related.rst
> index 5af5cc2..0b3436c 100644
> --- a/c-user/config/bsp-related.rst
> +++ b/c-user/config/bsp-related.rst
> @@ -104,7 +104,7 @@ DEFAULT VALUE:
>  
>  VALUE CONSTRAINTS:
>  The value of this configuration option shall be a list of initializers 
> for
> -structures of type :c:type:`rtems_extensions_table`.
> +structures of type ``rtems_extensions_table``.
>  
>  DESCRIPTION:
>  If
> @@ -181,7 +181,7 @@ DEFAULT VALUE:
>  
>  VALUE CONSTRAINTS:
>  The value of this configuration option shall be a list of initializers 
> for
> -structures of type :c:type:`rtems_extensions_table`.
> +structures of type ``rtems_extensions_table``.
>  
>  DESCRIPTION:
>  If
> @@ -259,9 +259,9 @@ DESCRIPTION:
>  * and :ref:`CONFIGURE_DISABLE_BSP_SETTINGS` is undefined,
>  
>  then not all memory is made available to the C Program Heap immediately 
> at
> -system initialization time.  When :c:func:`malloc()` or other standard 
> memory
> +system initialization time.  When ``malloc()`` or other standard memory
>  allocation functions are unable to allocate memory, they will call the 
> BSP
> -supplied :c:func:`sbrk()` function to obtain more memory.
> +supplied ``sbrk()`` function to obtain more memory.
>  
>  NOTES:
>  This option should not be defined by the application. Only the BSP knows 
> how
> diff --git a/c-user/config/classic-api.rst b/c-user/config/classic-api.rst
> index bd2fa00..b72ad30 100644
> --- a/c-user/config/classic-api.rst
> +++ b/c-user/config/classic-api.rst
> @@ -37,9 +37,10 @@ VALUE CONSTRAINTS:
>memory available to the application.
>  
>  * It may be defined through
> -  :c:func:`rtems_resource_unlimited` the enable unlimited objects for 
> this
> -  object class, if the value passed to :c:func:`rtems_resource_unlimited`
> -  satisfies all other constraints of this configuration option.
> +  ``rtems_resource_unlimited()`` the enable unlimited objects for
> +  this object class, if the value passed to
> +  ``rtems_resource_unlimited()`` satisfies all other constraints
> +  of this configuration option.
>  
>  DESCRIPTION:
>  The value of this configuration option defines the maximum number of 
> Classic
> @@ -78,9 +79,10 @@ VALUE CONSTRAINTS:
>memory available to the application.
>  
>  * It may be defined through
> -  :c:func:`rtems_resource_unlimited` the enable unlimited objects for 
> this
> -  object class, if the value passed to :c:func:`rtems_resource_unlimited`
> -  satisfies all other constraints of this configuration option.
> +  ``rtems_resource_unlimited()`` the enable unlimited objects for
> +  this object class, if the value passed to
> +  ``rtems_resource_unlimited()`` satisfies all other constraints
> +  of this configuration option.
>  
>  DESCRIPTION:
>  The value of this configuration option defines the maximum number of 
> Classic
> @@ -121,9 +123,10 @@ VALUE CONSTRAINTS:
>memory available to the application.
>  
>  * It may be defined through
> -  :c:func:`rtems_resource_unlimited` the enable unlimited objects for 
> this
> -  object class, if the value passed to :c:func:`rtems_resource_unlimited`
> -  satisfies all other constraints of this configuration option.
> +  ``rtems_resource_unlimited()`` the enable unlimited objects for
> +  this object class, if the value passed to
> +  ``rtems_resource_unlimited()`` satisfies all other constraints
> +  of this configuration option.
>  
>  DESCRIPTION:
>  The value of this configuration option defines the maximum number of 
> Classic
> @@ -162,9 +165,10 @@ VALUE CONSTRAINTS:
>memory available to the application.
>  
>  * It may be defined through
> -  :c:func:`rtems_resou

Re: [PATCH 0/1] Generate application configuration option documentation

2020-07-07 Thread Chris Johns 
Hi Sebastian,

Thank you for this patch. I am sorry but I would like to see this central repo
issue resolved before any generated files are added to any of the project's 
repos.

I understand to some level the path you are taking and moving along but these
generated files are coming from a personal repo that has changes, processes and
tools that are not being reviewed. I think it would be wise for us to agree on
what is behind all this before we agree to what is being generated.

On 7/7/20 9:25 pm, Sebastian Huber wrote:
> This patch adds the application configuration option documentation generated
> from specification items:
> 
> https://git.rtems.org/sebh/rtems-qual.git/tree/spec/if/acfg

 That is a lot of files. I am not sure I am ready to accept documentation
as a lot of small files. I am happy to be persuaded otherwise.

It is not clear to me if these YAML files generate documentation, headers, are
requirements or something else. There is nothing I can see in them that defines
their `role` or `roles`. If they do generate files how does that happen and how
are those generated header files related to the C code they are an interface
for? How do I keep each piece in sync? A compile error seems a long way from one
of these YAML files.

For example, if I was to add a YAML file to this directory I have no idea where
I look to find the naming, what roles are assumed, how it integrates into the
existing documentation, doxygen or header files? I also have no idea how I would
create a new API header file? What if I push a new header file to the rtems.git
repo with a new #include in rtems.h. Does a regenerate over write it?

It seems to me the key is the central repo and how it functions, how easy or
hard it is to learn about it and how well it will work in practice. A key
concern is taking it from a single person repo, ie you, to a project wide repo
with concurrent updates ad lots of moving pieces. It is easy to ask these
questions and I appreciate they are not all easy to answer but I think we need
to try.

> The header file is generated by the following script and module:
> 
> https://git.rtems.org/sebh/rtems-qual.git/tree/spec2doc.py
> 
> https://git.rtems.org/sebh/rtems-qual.git/tree/rtemsqual/applconfig.py
> 
> The module uses currently a hack to resolve references external to 
> specification
> items, e.g. sections in the RTEMS Classic API Guide or URLs.  I think we need
> specialized specification items for these external references.

I do not understand what this means?

> Sebastian Huber (1):
>   Document application configuration options
> 
>  cpukit/doxygen/appl-config.h | 4133 ++
>  1 file changed, 4133 insertions(+)
>  create mode 100644 cpukit/doxygen/appl-config.h

Is this information found in the user manual as well? I am struggling to
understand the relationships and what is being presented where.

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

Re: [PATCH] common: Remove probably superfluous import

2020-07-07 Thread Chris Johns 
On 7/7/20 3:29 pm, Sebastian Huber wrote:
> The purpose of this import is unclear.
> 
> This import caused the following error with Sphinx 3.0:
> 
> Extension error:
> Could not import extension rtemsdomain (exception: cannot import name 'l_')
> ---
>  common/rtemsdomain.py | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/common/rtemsdomain.py b/common/rtemsdomain.py
> index 49d0728..9b092a3 100644
> --- a/common/rtemsdomain.py
> +++ b/common/rtemsdomain.py
> @@ -3,7 +3,6 @@ from docutils.parsers.rst import directives
>  
>  from sphinx import addnodes
>  from sphinx.roles import XRefRole
> -from sphinx.locale import l_, _

Is this backwards compatible?

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

Re: RTEMS 6 and GCC 10 Status

2020-07-07 Thread Chris Johns 
On 7/7/20 11:03 pm, Sebastian Huber wrote:
> On 05/07/2020 19:13, Joel Sherrill wrote:
>> Should these be the first entries in the RTEMS 6 release description?
> 
> I added:
> 
> https://github.com/RTEMS/rtems-release/blob/master/rtems-notes-6.txt

Thank you.

> Should we rename this file to rtems-notes-6.md?

Yes this makes sense now the source is MD. You will need to update ...

https://git.rtems.org/rtems-release/tree/rtems-release#n101

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

Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5

2020-07-07 Thread Mritunjay Sharma 



From: Heinz Junkes 
Sent: Wednesday, July 8, 2020 1:05 AM
To: Mritunjay Sharma
Cc: Gedare Bloom; Joel Sherrill; Chris Johns; RTEMS Devel
Subject: Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5

I’m away from my keyboard. If you use the epics Adaption to rtems from my 
github “playground?” and bsp’s with —enable-networks should compile.
Heinz

FHI, Heinz Junkes

Thank you Heinz, I was doing the same. I went to your GitHub and am 
experimenting with "playground" right now.

Thanks,
Mritunjay

On 7. Jul 2020, at 18:14, Mritunjay Sharma  wrote:


[UPDATE]: I tried building EPICS with RTEMS5 for pc-386 and pc-386-qemu.
Everything worked fine while building the pc-386 with  RTEMS5.

After this when I entered epics-base and made the following change:

epics-base/os/CONFIG_SITE.Common.RTEMS
RTEMS_VERSION = 5
RTEMS_BASE = /home/mritunjay/development/rtems_dev/$(RTEMS_VERSION)

As an experiment, I ran the make and as expected got the following error

Error:

```...de/compiler/gcc -I../../../../include/os/RTEMS -I../../../../include  
   -c ../rtems_init.c
../rtems_init.c:21:10: fatal error: sys/termios.h: No such file or directory
 #include 
  ^~~
compilation terminated.
../../../../configure/RULES_BUILD:240: recipe for target 'rtems_init.o' failed
make[4]: *** [rtems_init.o] Error 1
make[4]: Leaving directory 
'/home/mritunjay/development/EPICS/epics-base/modules/libcom/RTEMS/O.RTEMS-pc386'
../../../configure/RULES_ARCHS:58: recipe for target 'install.RTEMS-pc386' 
failed
make[3]: *** [install.RTEMS-pc386] Error 2
make[3]: Leaving directory 
'/home/mritunjay/development/EPICS/epics-base/modules/libcom/RTEMS'
../../configure/RULES_DIRS:85: recipe for target 'RTEMS.install' failed
make[2]: *** [RTEMS.install] Error 2
make[2]: Leaving directory 
'/home/mritunjay/development/EPICS/epics-base/modules/libcom'
../configure/RULES_DIRS:85: recipe for target 'libcom.install' failed
make[1]: *** [libcom.install] Error 2
make[1]: Leaving directory 
'/home/mritunjay/development/EPICS/epics-base/modules'
configure/RULES_DIRS:85: recipe for target 'modules.install' failed
make: *** [modules.install] Error 2
```

I am trying to figure out the error and making the changes in code to debug it.
However, I will appreciate if Heinz and everyone else can help me a little, if 
they have an
idea of this error.

Thanks
Mritunjay

On Tue, Jul 7, 2020 at 7:30 PM Mritunjay Sharma 
mailto:mritunjaysharma...@gmail.com>> wrote:


On Tue, Jul 7, 2020 at 5:33 AM Gedare Bloom 
mailto:ged...@rtems.org>> wrote:
On Mon, Jul 6, 2020 at 5:49 PM Joel Sherrill 
mailto:j...@rtems.org>> wrote:
>
>
>
> On Mon, Jul 6, 2020, 6:14 PM Gedare Bloom 
> mailto:ged...@rtems.org>> wrote:
>>
>> On Mon, Jul 6, 2020 at 10:12 AM Mritunjay Sharma
>> mailto:mritunjaysharma...@gmail.com>> wrote:
>> >
>> > Hello everyone,
>> >
>> > Thank you, Heinz, Gedare, Chris and Joel for your advice.
>> > If there are issues in making a buildset for 4.10
>> > then should I build EPICS with RTEMS 5 by hand first and note
>> > down the process and then proceed to make the buildset for it?
>> >
>>
>> Yes.
>
>
> +1
>
> And by 5, we definitely mean the 5 branch for all rtems repo and the 
> similarly named one for libbsd.

Excellent point. We want to add support for easy build (and eventually
test) of EPICS+RTEMS starting with 5.1 and moving forward, which means
also doing it for RTEMS 6, Mritunjay.

Sounds good, I have begun building it hand by today for RTEMS 5 branch and 
later on continue the
same for RTEMS6

Thank you so much Gedare and Joel.
Mritunjay
>>
>>
>> > Please suggest for the future steps.
>> >
>> > Thanks
>> > Mritunjay
>> >
>> > On Mon, Jul 6, 2020 at 5:38 AM Joel Sherrill 
>> > mailto:j...@rtems.org>> wrote:
>> >>
>> >>
>> >>
>> >> On Sun, Jul 5, 2020, 6:12 PM Chris Johns 
>> >> mailto:chr...@rtems.org>> wrote:
>> >>>
>> >>> On 6/7/20 12:47 am, Heinz Junkes wrote:
>> >>> > Thank you, this is exactly where I was unsure.
>> >>> > @Chris: Can you give a recommendation here?
>> >>> > Danke Heinz
>> >>> > --
>> >>> > Fritz-Haber-Institut| Phone: (+49 30) 8413-4270
>> >>> > Heinz Junkes | Fax (G3+G4):   (+49 30) 8413-5900
>> >>> > Faradayweg 4-6| VC: 
>> >>> > 102220181...@bjn.vc
>> >>> > D - 14195 Berlin| E-Mail:
>> >>> > jun...@fhi-berlin.mpg.de
>> >>> > --
>> >>> >
>> >>> >> On 5. Jul 2020, at 16:20, Gedare Bloom 
>> >>> >> mailto:ged...@rtems.org>> wrote:
>> >>> >>
>> >>> >> On Sat, Jul 4, 2020 at 1:18 PM Mritunjay Sharma
>> >>> >> mailto:mritunjaysharma...@gmail.com>> 
>> >>> >> wrote:
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> On Sun, Jul 5, 2020 at 12:28 AM Heinz Junkes 
>> >>> >>> mailto:jun...@fhi-berlin.mpg.de>> wrote:
>> >>> 
>> >>>

Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5

2020-07-07 Thread Heinz Junkes 
I’m away from my keyboard. If you use the epics Adaption to rtems from my 
github “playground?” and bsp’s with —enable-networks should compile.
Heinz 

FHI, Heinz Junkes

> On 7. Jul 2020, at 18:14, Mritunjay Sharma  
> wrote:
> 
> 
> [UPDATE]: I tried building EPICS with RTEMS5 for pc-386 and pc-386-qemu. 
> Everything worked fine while building the pc-386 with  RTEMS5.
> 
> After this when I entered epics-base and made the following change:
> 
> epics-base/os/CONFIG_SITE.Common.RTEMS
> RTEMS_VERSION = 5
> RTEMS_BASE = /home/mritunjay/development/rtems_dev/$(RTEMS_VERSION) 
>  
> As an experiment, I ran the make and as expected got the following error
> 
> Error: 
> 
> ```...de/compiler/gcc -I../../../../include/os/RTEMS -I../../../../include
>  -c ../rtems_init.c
> ../rtems_init.c:21:10: fatal error: sys/termios.h: No such file or directory
>  #include 
>   ^~~
> compilation terminated.
> ../../../../configure/RULES_BUILD:240: recipe for target 'rtems_init.o' failed
> make[4]: *** [rtems_init.o] Error 1
> make[4]: Leaving directory 
> '/home/mritunjay/development/EPICS/epics-base/modules/libcom/RTEMS/O.RTEMS-pc386'
> ../../../configure/RULES_ARCHS:58: recipe for target 'install.RTEMS-pc386' 
> failed
> make[3]: *** [install.RTEMS-pc386] Error 2
> make[3]: Leaving directory 
> '/home/mritunjay/development/EPICS/epics-base/modules/libcom/RTEMS'
> ../../configure/RULES_DIRS:85: recipe for target 'RTEMS.install' failed
> make[2]: *** [RTEMS.install] Error 2
> make[2]: Leaving directory 
> '/home/mritunjay/development/EPICS/epics-base/modules/libcom'
> ../configure/RULES_DIRS:85: recipe for target 'libcom.install' failed
> make[1]: *** [libcom.install] Error 2
> make[1]: Leaving directory 
> '/home/mritunjay/development/EPICS/epics-base/modules'
> configure/RULES_DIRS:85: recipe for target 'modules.install' failed
> make: *** [modules.install] Error 2
> ```
> 
> I am trying to figure out the error and making the changes in code to debug 
> it. 
> However, I will appreciate if Heinz and everyone else can help me a little, 
> if they have an
> idea of this error. 
> 
> Thanks
> Mritunjay 
> 
>> On Tue, Jul 7, 2020 at 7:30 PM Mritunjay Sharma 
>>  wrote:
>> 
>> 
>>> On Tue, Jul 7, 2020 at 5:33 AM Gedare Bloom  wrote:
>>> On Mon, Jul 6, 2020 at 5:49 PM Joel Sherrill  wrote:
>>> >
>>> >
>>> >
>>> > On Mon, Jul 6, 2020, 6:14 PM Gedare Bloom  wrote:
>>> >>
>>> >> On Mon, Jul 6, 2020 at 10:12 AM Mritunjay Sharma
>>> >>  wrote:
>>> >> >
>>> >> > Hello everyone,
>>> >> >
>>> >> > Thank you, Heinz, Gedare, Chris and Joel for your advice.
>>> >> > If there are issues in making a buildset for 4.10
>>> >> > then should I build EPICS with RTEMS 5 by hand first and note
>>> >> > down the process and then proceed to make the buildset for it?
>>> >> >
>>> >>
>>> >> Yes.
>>> >
>>> >
>>> > +1
>>> >
>>> > And by 5, we definitely mean the 5 branch for all rtems repo and the 
>>> > similarly named one for libbsd.
>>> 
>>> Excellent point. We want to add support for easy build (and eventually
>>> test) of EPICS+RTEMS starting with 5.1 and moving forward, which means
>>> also doing it for RTEMS 6, Mritunjay.
>>> 
>> Sounds good, I have begun building it hand by today for RTEMS 5 branch and 
>> later on continue the 
>> same for RTEMS6
>> 
>> Thank you so much Gedare and Joel. 
>> Mritunjay 
>>> >>
>>> >>
>>> >> > Please suggest for the future steps.
>>> >> >
>>> >> > Thanks
>>> >> > Mritunjay
>>> >> >
>>> >> > On Mon, Jul 6, 2020 at 5:38 AM Joel Sherrill  wrote:
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> On Sun, Jul 5, 2020, 6:12 PM Chris Johns  wrote:
>>> >> >>>
>>> >> >>> On 6/7/20 12:47 am, Heinz Junkes wrote:
>>> >> >>> > Thank you, this is exactly where I was unsure.
>>> >> >>> > @Chris: Can you give a recommendation here?
>>> >> >>> > Danke Heinz
>>> >> >>> > --
>>> >> >>> > Fritz-Haber-Institut| Phone: (+49 30) 8413-4270
>>> >> >>> > Heinz Junkes | Fax (G3+G4):   (+49 30) 8413-5900
>>> >> >>> > Faradayweg 4-6| VC: 102220181...@bjn.vc
>>> >> >>> > D - 14195 Berlin| E-Mail:jun...@fhi-berlin.mpg.de
>>> >> >>> > --
>>> >> >>> >
>>> >> >>> >> On 5. Jul 2020, at 16:20, Gedare Bloom  wrote:
>>> >> >>> >>
>>> >> >>> >> On Sat, Jul 4, 2020 at 1:18 PM Mritunjay Sharma
>>> >> >>> >>  wrote:
>>> >> >>> >>>
>>> >> >>> >>>
>>> >> >>> >>>
>>> >> >>> >>> On Sun, Jul 5, 2020 at 12:28 AM Heinz Junkes 
>>> >> >>> >>>  wrote:
>>> >> >>> 
>>> >> >>>  Hello, Mritunjay,
>>> >> >>>  that's good news. Don't you want to try to develop a rsb-set 
>>> >> >>>  for exactly this combination of RTEMS4.10 and EPICS7?
>>> >> >>> >>>
>>> >> >>> >>>
>>> >> >>> >>> Sure, I am ready to do this and then do it with RTEMS5 in the 
>>> >> >>> >>> same way. Please tell how to begin or some existing similar
>>> >> >>> >>> work that

Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5

2020-07-07 Thread Mritunjay Sharma 
[UPDATE]: I tried building EPICS with RTEMS5 for pc-386 and pc-386-qemu.
Everything worked fine while building the pc-386 with  RTEMS5.

After this when I entered epics-base and made the following change:

epics-base/os/CONFIG_SITE.Common.RTEMS
RTEMS_VERSION = 5
RTEMS_BASE = /home/mritunjay/development/rtems_dev/$(RTEMS_VERSION)

As an experiment, I ran the make and as expected got the following error

Error:

```...de/compiler/gcc -I../../../../include/os/RTEMS -I../../../../include
-c ../rtems_init.c
../rtems_init.c:21:10: fatal error: sys/termios.h: No such file or directory
 #include 
  ^~~
compilation terminated.
../../../../configure/RULES_BUILD:240: recipe for target 'rtems_init.o'
failed
make[4]: *** [rtems_init.o] Error 1
make[4]: Leaving directory
'/home/mritunjay/development/EPICS/epics-base/modules/libcom/RTEMS/O.RTEMS-pc386'
../../../configure/RULES_ARCHS:58: recipe for target 'install.RTEMS-pc386'
failed
make[3]: *** [install.RTEMS-pc386] Error 2
make[3]: Leaving directory
'/home/mritunjay/development/EPICS/epics-base/modules/libcom/RTEMS'
../../configure/RULES_DIRS:85: recipe for target 'RTEMS.install' failed
make[2]: *** [RTEMS.install] Error 2
make[2]: Leaving directory
'/home/mritunjay/development/EPICS/epics-base/modules/libcom'
../configure/RULES_DIRS:85: recipe for target 'libcom.install' failed
make[1]: *** [libcom.install] Error 2
make[1]: Leaving directory
'/home/mritunjay/development/EPICS/epics-base/modules'
configure/RULES_DIRS:85: recipe for target 'modules.install' failed
make: *** [modules.install] Error 2
```

I am trying to figure out the error and making the changes in code to debug
it.
However, I will appreciate if Heinz and everyone else can help me a little,
if they have an
idea of this error.

Thanks
Mritunjay

On Tue, Jul 7, 2020 at 7:30 PM Mritunjay Sharma <
mritunjaysharma...@gmail.com> wrote:

>
>
> On Tue, Jul 7, 2020 at 5:33 AM Gedare Bloom  wrote:
>
>> On Mon, Jul 6, 2020 at 5:49 PM Joel Sherrill  wrote:
>> >
>> >
>> >
>> > On Mon, Jul 6, 2020, 6:14 PM Gedare Bloom  wrote:
>> >>
>> >> On Mon, Jul 6, 2020 at 10:12 AM Mritunjay Sharma
>> >>  wrote:
>> >> >
>> >> > Hello everyone,
>> >> >
>> >> > Thank you, Heinz, Gedare, Chris and Joel for your advice.
>> >> > If there are issues in making a buildset for 4.10
>> >> > then should I build EPICS with RTEMS 5 by hand first and note
>> >> > down the process and then proceed to make the buildset for it?
>> >> >
>> >>
>> >> Yes.
>> >
>> >
>> > +1
>> >
>> > And by 5, we definitely mean the 5 branch for all rtems repo and the
>> similarly named one for libbsd.
>>
>> Excellent point. We want to add support for easy build (and eventually
>> test) of EPICS+RTEMS starting with 5.1 and moving forward, which means
>> also doing it for RTEMS 6, Mritunjay.
>>
>> Sounds good, I have begun building it hand by today for RTEMS 5 branch
> and later on continue the
> same for RTEMS6
>
> Thank you so much Gedare and Joel.
> Mritunjay
>
>> >>
>> >>
>> >> > Please suggest for the future steps.
>> >> >
>> >> > Thanks
>> >> > Mritunjay
>> >> >
>> >> > On Mon, Jul 6, 2020 at 5:38 AM Joel Sherrill  wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Sun, Jul 5, 2020, 6:12 PM Chris Johns  wrote:
>> >> >>>
>> >> >>> On 6/7/20 12:47 am, Heinz Junkes wrote:
>> >> >>> > Thank you, this is exactly where I was unsure.
>> >> >>> > @Chris: Can you give a recommendation here?
>> >> >>> > Danke Heinz
>> >> >>> >
>> --
>> >> >>> > Fritz-Haber-Institut| Phone: (+49 30) 8413-4270
>> >> >>> > Heinz Junkes | Fax (G3+G4):   (+49 30) 8413-5900
>> >> >>> > Faradayweg 4-6| VC: 102220181...@bjn.vc
>> >> >>> > D - 14195 Berlin| E-Mail:
>> jun...@fhi-berlin.mpg.de
>> >> >>> >
>> --
>> >> >>> >
>> >> >>> >> On 5. Jul 2020, at 16:20, Gedare Bloom 
>> wrote:
>> >> >>> >>
>> >> >>> >> On Sat, Jul 4, 2020 at 1:18 PM Mritunjay Sharma
>> >> >>> >>  wrote:
>> >> >>> >>>
>> >> >>> >>>
>> >> >>> >>>
>> >> >>> >>> On Sun, Jul 5, 2020 at 12:28 AM Heinz Junkes <
>> jun...@fhi-berlin.mpg.de> wrote:
>> >> >>> 
>> >> >>>  Hello, Mritunjay,
>> >> >>>  that's good news. Don't you want to try to develop a rsb-set
>> for exactly this combination of RTEMS4.10 and EPICS7?
>> >> >>> >>>
>> >> >>> >>>
>> >> >>> >>> Sure, I am ready to do this and then do it with RTEMS5 in the
>> same way. Please tell how to begin or some existing similar
>> >> >>> >>> work that can guide me how to proceed further in relation to
>> rsb-set for  RTEMS4.10 and EPICS7.
>> >> >>> >>>
>> >> >>> >>
>> >> >>> >> I don't know if this is best. RSB didn't exist in 4.10. I
>> haven't
>> >> >>> >> looked to see how well the rtems-source-builder/4.10 would
>> support a
>> >> >>> >> package build. It should be discussed with Chris probably. A
>> couple of
>> >> >>> >> packages were added in the 4.11

Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5

2020-07-07 Thread Mritunjay Sharma 
On Tue, Jul 7, 2020 at 5:33 AM Gedare Bloom  wrote:

> On Mon, Jul 6, 2020 at 5:49 PM Joel Sherrill  wrote:
> >
> >
> >
> > On Mon, Jul 6, 2020, 6:14 PM Gedare Bloom  wrote:
> >>
> >> On Mon, Jul 6, 2020 at 10:12 AM Mritunjay Sharma
> >>  wrote:
> >> >
> >> > Hello everyone,
> >> >
> >> > Thank you, Heinz, Gedare, Chris and Joel for your advice.
> >> > If there are issues in making a buildset for 4.10
> >> > then should I build EPICS with RTEMS 5 by hand first and note
> >> > down the process and then proceed to make the buildset for it?
> >> >
> >>
> >> Yes.
> >
> >
> > +1
> >
> > And by 5, we definitely mean the 5 branch for all rtems repo and the
> similarly named one for libbsd.
>
> Excellent point. We want to add support for easy build (and eventually
> test) of EPICS+RTEMS starting with 5.1 and moving forward, which means
> also doing it for RTEMS 6, Mritunjay.
>
> Sounds good, I have begun building it hand by today for RTEMS 5 branch and
later on continue the
same for RTEMS6

Thank you so much Gedare and Joel.
Mritunjay

> >>
> >>
> >> > Please suggest for the future steps.
> >> >
> >> > Thanks
> >> > Mritunjay
> >> >
> >> > On Mon, Jul 6, 2020 at 5:38 AM Joel Sherrill  wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Sun, Jul 5, 2020, 6:12 PM Chris Johns  wrote:
> >> >>>
> >> >>> On 6/7/20 12:47 am, Heinz Junkes wrote:
> >> >>> > Thank you, this is exactly where I was unsure.
> >> >>> > @Chris: Can you give a recommendation here?
> >> >>> > Danke Heinz
> >> >>> >
> --
> >> >>> > Fritz-Haber-Institut| Phone: (+49 30) 8413-4270
> >> >>> > Heinz Junkes | Fax (G3+G4):   (+49 30) 8413-5900
> >> >>> > Faradayweg 4-6| VC: 102220181...@bjn.vc
> >> >>> > D - 14195 Berlin| E-Mail:jun...@fhi-berlin.mpg.de
> >> >>> >
> --
> >> >>> >
> >> >>> >> On 5. Jul 2020, at 16:20, Gedare Bloom  wrote:
> >> >>> >>
> >> >>> >> On Sat, Jul 4, 2020 at 1:18 PM Mritunjay Sharma
> >> >>> >>  wrote:
> >> >>> >>>
> >> >>> >>>
> >> >>> >>>
> >> >>> >>> On Sun, Jul 5, 2020 at 12:28 AM Heinz Junkes <
> jun...@fhi-berlin.mpg.de> wrote:
> >> >>> 
> >> >>>  Hello, Mritunjay,
> >> >>>  that's good news. Don't you want to try to develop a rsb-set
> for exactly this combination of RTEMS4.10 and EPICS7?
> >> >>> >>>
> >> >>> >>>
> >> >>> >>> Sure, I am ready to do this and then do it with RTEMS5 in the
> same way. Please tell how to begin or some existing similar
> >> >>> >>> work that can guide me how to proceed further in relation to
> rsb-set for  RTEMS4.10 and EPICS7.
> >> >>> >>>
> >> >>> >>
> >> >>> >> I don't know if this is best. RSB didn't exist in 4.10. I haven't
> >> >>> >> looked to see how well the rtems-source-builder/4.10 would
> support a
> >> >>> >> package build. It should be discussed with Chris probably. A
> couple of
> >> >>> >> packages were added in the 4.11 branch.
> >> >>>
> >> >>> I would leave 4.10 and move on. It may work but these things can
> expose issues
> >> >>> that turn into distractions.
> >> >>>
> >> >>> Would making a script that does the build so we can document the
> steps be worth
> >> >>> while
> >> >>
> >> >>
> >> >> Yes. Emphatically yes. We need to make sure we know how it is best
> built by hand to automate it.
> >> >>
> >> >> I firmly believe you should not attempt to automate something until
> doing it manually is well understood and documented.
> >> >>
> >> >> After you have this down for one BSP, we need to ask questions like:
> >> >>
> >> >> + Is there any per BSP tailoring beyond the obviod architecture and
> compilation settings?
> >> >>
> >> >> + Any tweaks to settings users may want?
> >> >>
> >> >> The manual process should include testing. The RSB is a great way to
> automate and ease building but it doesn't address testing the packages yet.
> >> >>
> >> >> --joel
> >> >>
> >> >>>
> >> >>> 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: libbsd rtems 5 branches

2020-07-07 Thread Sebastian Huber 

On 07/07/2020 15:19, Joel Sherrill wrote:

Hi

What's the difference between these two branches?

   remotes/origin/5


This branch synchronizes with the FreeBSD master.


   remotes/origin/5-freebsd-12



This branch synchronizes with the FreeBSD 12 branch.

Both are for RTEMS 5.

--
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

libbsd rtems 5 branches

2020-07-07 Thread Joel Sherrill 
Hi

What's the difference between these two branches?

  remotes/origin/5
  remotes/origin/5-freebsd-12

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

Re: RTEMS 6 and GCC 10 Status

2020-07-07 Thread Joel Sherrill 
On Tue, Jul 7, 2020 at 8:03 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 05/07/2020 19:13, Joel Sherrill wrote:
> > Good job!
> >
> > Should these be the first entries in the RTEMS 6 release description?
>
> I added:
>
> https://github.com/RTEMS/rtems-release/blob/master/rtems-notes-6.txt
>
> Should we rename this file to rtems-notes-6.md?
>

If it is really markdown and that's how it will be used, I suppose it makes
sense.

Besides, it we change our mind, it isn't a big deal to change it again. :)

>
> I added also a migration from v5 to v6 section for the user manual.
>

+1

>
> --
> 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

[PATCH] user: Add v5 to v6 migration help

2020-07-07 Thread Sebastian Huber 
---
 user/migration/index.rst|  1 +
 user/migration/v5-to-v6.rst | 20 
 2 files changed, 21 insertions(+)
 create mode 100644 user/migration/v5-to-v6.rst

diff --git a/user/migration/index.rst b/user/migration/index.rst
index 76012b5..06af484 100644
--- a/user/migration/index.rst
+++ b/user/migration/index.rst
@@ -15,3 +15,4 @@ from one version of RTEMS to a new version.
 .. toctree::
 
 v4_11-to-v5
+v5-to-v6
diff --git a/user/migration/v5-to-v6.rst b/user/migration/v5-to-v6.rst
new file mode 100644
index 000..5997057
--- /dev/null
+++ b/user/migration/v5-to-v6.rst
@@ -0,0 +1,20 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+
+.. _Migration_5_to_6:
+
+RTEMS 5 to RTEMS 6
+==
+
+This section provides helpful information when migrating from RTEMS 5 to
+RTEMS 6.
+
+Update to GCC 10
+
+
+The tool suite for RTEMS 6 uses GCC 10.  GCC 10 enables ``-fno-common`` by
+default.  Code bases which never used this option before may observe now
+multiple definition linker errors.  For example, if global variables are
+declared and defined in header files (usually a missing ``extern`` in the 
header
+file).
-- 
2.26.2

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

Re: RTEMS 6 and GCC 10 Status

2020-07-07 Thread Sebastian Huber 

On 05/07/2020 19:13, Joel Sherrill wrote:

Good job!

Should these be the first entries in the RTEMS 6 release description?


I added:

https://github.com/RTEMS/rtems-release/blob/master/rtems-notes-6.txt

Should we rename this file to rtems-notes-6.md?

I added also a migration from v5 to v6 section for the user manual.

--
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

[PATCH] sptests/sp21: Fix deprecated warning

2020-07-07 Thread Aschref Ben-Thabet 
---
 testsuites/sptests/sp21/init.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/testsuites/sptests/sp21/init.c b/testsuites/sptests/sp21/init.c
index f44f2ba851..71abe467a9 100644
--- a/testsuites/sptests/sp21/init.c
+++ b/testsuites/sptests/sp21/init.c
@@ -7,6 +7,8 @@
  *  http://www.rtems.org/license/LICENSE.
  */
 
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
+
 #ifdef HAVE_CONFIG_H
 #include "config.h"
 #endif
-- 
2.26.2

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

[PATCH 1/1] Document application configuration options

2020-07-07 Thread Sebastian Huber 
Add a new directory for Doxygen-specific documentation content.  Add a
Doxygen only header file containing documentation of the application
configuration options.  The header file is generated from specification
items.

Update #3994.
---
 cpukit/doxygen/appl-config.h | 4125 ++
 1 file changed, 4125 insertions(+)
 create mode 100644 cpukit/doxygen/appl-config.h

diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
new file mode 100644
index 00..0544356c92
--- /dev/null
+++ b/cpukit/doxygen/appl-config.h
@@ -0,0 +1,4125 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2019, 2020 embedded brains GmbH 
(http://www.embedded-brains.de)
+ * Copyright (C) 2010 Gedare Bloom
+ * Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/**
+ * @defgroup RTEMSApplConfig Application Configuration Options
+ *
+ * @ingroup RTEMSAPI
+ */
+
+/**
+ * @defgroup RTEMSApplConfigBlockDeviceCacheConfiguration Block Device Cache 
Configuration
+ *
+ * @ingroup RTEMSApplConfig
+ *
+ * This section describes configuration options related to the Block Device
+ * Cache (bdbuf).
+ *
+ * @{
+ */
+
+/**
+ * @brief This configuration option is a boolean feature define.
+ *
+ * In case this configuration option is defined, then the Block Device Cache is
+ * initialized during system initialization.
+ *
+ * @par Default Configuration
+ * If this configuration option is undefined, then the described feature is not
+ * enabled.
+ *
+ * @par Notes
+ * Each option of the Block Device Cache (bdbuf) configuration can be
+ * explicitly set by the user with the configuration options below.  The Block
+ * Device Cache is used for example by the RFS and DOSFS filesystems.
+ */
+#define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
+
+/**
+ * @brief This configuration option is an integer define.
+ *
+ * The value of this configuration option defines the maximum size of a buffer
+ * in bytes.
+ *
+ * @par Default Value
+ * The default value is 4096.
+ *
+ * @par Value Constraints
+ * @parblock
+ * The value of this configuration option shall satisfy all of the following
+ * constraints:
+ *
+ * * It shall be greater than or equal to 0.
+ *
+ * * It shall be an integral multiple of #CONFIGURE_BDBUF_BUFFER_MIN_SIZE.
+ * @endparblock
+ */
+#define CONFIGURE_BDBUF_BUFFER_MAX_SIZE
+
+/**
+ * @brief This configuration option is an integer define.
+ *
+ * The value of this configuration option defines the minimum size of a buffer
+ * in bytes.
+ *
+ * @par Default Value
+ * The default value is 512.
+ *
+ * @par Value Constraints
+ * The value of this configuration option shall be greater than or equal to 0
+ * and less than or equal to ``UINT32_MAX``.
+ */
+#define CONFIGURE_BDBUF_BUFFER_MIN_SIZE
+
+/**
+ * @brief This configuration option is an integer define.
+ *
+ * The value of this configuration option defines the size of the cache memory
+ * in bytes.
+ *
+ * @par Default Value
+ * The default value is 32768.
+ *
+ * @par Value Constraints
+ * The value of this configuration option shall be greater than or equal to 0
+ * and less than or equal to ``SIZE_MAX``.
+ */
+#define CONFIGURE_BDBUF_CACHE_MEMORY_SIZE
+
+/**
+ * @brief This configuration option is an integer define.
+ *
+ * The value of this configuration option defines the maximum blocks per
+ * read-ahead request.
+ *
+ * @par Default Value
+ * The default value is 0.
+ *
+ * @par Value Constraints
+ * The value of this configuration option shall be greater than or equal to 0
+ * and less than or equal to ``UINT32_MAX``.
+ *
+ * @par Notes
+ * A value of 0 disables the read-ahead task (default).

[PATCH 0/1] Generate application configuration option documentation

2020-07-07 Thread Sebastian Huber 
This patch adds the application configuration option documentation generated
from specification items:

https://git.rtems.org/sebh/rtems-qual.git/tree/spec/if/acfg

The header file is generated by the following script and module:

https://git.rtems.org/sebh/rtems-qual.git/tree/spec2doc.py

https://git.rtems.org/sebh/rtems-qual.git/tree/rtemsqual/applconfig.py

The module uses currently a hack to resolve references external to specification
items, e.g. sections in the RTEMS Classic API Guide or URLs.  I think we need
specialized specification items for these external references.

Sebastian Huber (1):
  Document application configuration options

 cpukit/doxygen/appl-config.h | 4133 ++
 1 file changed, 4133 insertions(+)
 create mode 100644 cpukit/doxygen/appl-config.h

-- 
2.26.2

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

[PATCH 2/2] c-user: Canonicalize document internal references

2020-07-07 Thread Sebastian Huber 
This helps to generate Doxygen markup from the application configuration
option specification items.

Update #3994.
---
 c-user/config/classic-api.rst   |  7 +--
 c-user/config/general.rst   |  6 +-
 c-user/config/posix-api.rst | 11 ++--
 c-user/config/scheduler-general.rst | 87 +
 4 files changed, 49 insertions(+), 62 deletions(-)

diff --git a/c-user/config/classic-api.rst b/c-user/config/classic-api.rst
index b72ad30..07c79b2 100644
--- a/c-user/config/classic-api.rst
+++ b/c-user/config/classic-api.rst
@@ -356,11 +356,8 @@ NOTES:
 
 The calculations for the required memory in the RTEMS Workspace for tasks
 assume that each task has a minimum stack size and has floating point
-support enabled.  The configuration parameter
-``CONFIGURE_EXTRA_TASK_STACKS`` is used to specify task stack requirements
-*ABOVE* the minimum size required.  See :ref:`Reserve Task/Thread Stack
-Memory Above Minimum` for more information about
-``CONFIGURE_EXTRA_TASK_STACKS``.
+support enabled.  The configuration option 
:ref:`CONFIGURE_EXTRA_TASK_STACKS` is used
+to specify task stack requirements *above* the minimum size required.
 
 The maximum number of POSIX threads is specified by
 :ref:`CONFIGURE_MAXIMUM_POSIX_THREADS`.
diff --git a/c-user/config/general.rst b/c-user/config/general.rst
index 08f2a92..d495c7a 100644
--- a/c-user/config/general.rst
+++ b/c-user/config/general.rst
@@ -216,9 +216,9 @@ NOTES:
 to perform the sequential system initialization before the multithreading
 is started.
 
-The interrupt stacks are covered by the :ref:`stack checker
-`.  However, using a too small interrupt
-stack size may still result in undefined behaviour.
+The interrupt stacks are covered by the stack checker, see
+:ref:`CONFIGURE_STACK_CHECKER_ENABLED`.  However, using a too small 
interrupt stack
+size may still result in undefined behaviour.
 
 In releases before RTEMS 5.1 the default value was
 :ref:`CONFIGURE_MINIMUM_TASK_STACK_SIZE` instead of 
``CPU_STACK_MINIMUM_SIZE``.
diff --git a/c-user/config/posix-api.rst b/c-user/config/posix-api.rst
index 23aeb62..7a683d4 100644
--- a/c-user/config/posix-api.rst
+++ b/c-user/config/posix-api.rst
@@ -330,13 +330,10 @@ NOTES:
 This object class can be configured in unlimited allocation mode, see
 :ref:`ConfigUnlimitedObjects`.
 
-This calculations for the required memory in the RTEMS Workspace for
-threads assume that each thread has a minimum stack size and has floating
-point support enabled.  The configuration option
-:ref:`CONFIGURE_EXTRA_TASK_STACKS` is used to specify thread stack
-requirements **above** the minimum size required.  See :ref:`Reserve
-Task/Thread Stack Memory Above Minimum` for more information about
-``CONFIGURE_EXTRA_TASK_STACKS``.
+This calculations for the required memory in the RTEMS Workspace for 
threads
+assume that each thread has a minimum stack size and has floating point
+support enabled.  The configuration option 
:ref:`CONFIGURE_EXTRA_TASK_STACKS` is used
+to specify thread stack requirements **above** the minimum size required.
 
 The maximum number of Classic API Tasks is specified by
 :ref:`CONFIGURE_MAXIMUM_TASKS`.
diff --git a/c-user/config/scheduler-general.rst 
b/c-user/config/scheduler-general.rst
index c353f16..274a7cf 100644
--- a/c-user/config/scheduler-general.rst
+++ b/c-user/config/scheduler-general.rst
@@ -13,17 +13,18 @@ and only necessary in very specific circumstances.  A 
normal application
 configuration does not need any of the configuration options described in this
 section.
 
-By default, the :ref:`Deterministic Priority Scheduler `
+By default, the :ref:`SchedulerPriority`
 algorithm is used in uniprocessor configurations.  In case SMP is enabled and
 the configured maximum processors
 (:ref:`CONFIGURE_MAXIMUM_PROCESSORS`) is greater
-than one, then the :ref:`Earliest Deadline First (EDF) SMP Scheduler
-` is selected as the default scheduler algorithm.
+than one, then the
+:ref:`SchedulerSMPEDF`
+is selected as the default scheduler algorithm.
 
-For the :ref:`schedulers built into
-RTEMS `, the configuration is straightforward.  All that is
-required is to define the configuration option which specifies which scheduler
-you want for in your application.
+For the schedulers provided by RTEMS (see :ref:`SchedulingConcepts`), the
+configuration is straightforward.  All that is required is to define the
+configuration option which specifies which scheduler you want for in your
+application.
 
 The pluggable scheduler interface also enables the user to provide their own
 scheduling algorithm.  If you choose to do this, you must define multiple
@@ -183,16 +184,15 @@ DEFAULT CONFIGURATION:
 
 DESCRIPTION:
 In case this configuration option is defined, then
-:ref:`Constant Bandwidth Server (CBS) Scheduler `
+:ref:`SchedulerCBS`

[PATCH 1/2] c-user: Avoid Sphinx-specifics in appl config

2020-07-07 Thread Sebastian Huber 
This helps to generate Doxygen markup from the application configuration
option specification items.

Update #3994.
---
 c-user/config/bsp-related.rst   |  8 ++--
 c-user/config/classic-api.rst   | 63 -
 c-user/config/classic-init-task.rst |  2 +-
 c-user/config/device-driver.rst | 26 ++--
 c-user/config/filesystem.rst| 28 ++---
 c-user/config/general.rst   | 12 +++---
 c-user/config/mpci.rst  |  2 +-
 c-user/config/posix-api.rst | 52 +---
 c-user/config/scheduler-general.rst |  6 +--
 9 files changed, 107 insertions(+), 92 deletions(-)

diff --git a/c-user/config/bsp-related.rst b/c-user/config/bsp-related.rst
index 5af5cc2..0b3436c 100644
--- a/c-user/config/bsp-related.rst
+++ b/c-user/config/bsp-related.rst
@@ -104,7 +104,7 @@ DEFAULT VALUE:
 
 VALUE CONSTRAINTS:
 The value of this configuration option shall be a list of initializers for
-structures of type :c:type:`rtems_extensions_table`.
+structures of type ``rtems_extensions_table``.
 
 DESCRIPTION:
 If
@@ -181,7 +181,7 @@ DEFAULT VALUE:
 
 VALUE CONSTRAINTS:
 The value of this configuration option shall be a list of initializers for
-structures of type :c:type:`rtems_extensions_table`.
+structures of type ``rtems_extensions_table``.
 
 DESCRIPTION:
 If
@@ -259,9 +259,9 @@ DESCRIPTION:
 * and :ref:`CONFIGURE_DISABLE_BSP_SETTINGS` is undefined,
 
 then not all memory is made available to the C Program Heap immediately at
-system initialization time.  When :c:func:`malloc()` or other standard 
memory
+system initialization time.  When ``malloc()`` or other standard memory
 allocation functions are unable to allocate memory, they will call the BSP
-supplied :c:func:`sbrk()` function to obtain more memory.
+supplied ``sbrk()`` function to obtain more memory.
 
 NOTES:
 This option should not be defined by the application. Only the BSP knows 
how
diff --git a/c-user/config/classic-api.rst b/c-user/config/classic-api.rst
index bd2fa00..b72ad30 100644
--- a/c-user/config/classic-api.rst
+++ b/c-user/config/classic-api.rst
@@ -37,9 +37,10 @@ VALUE CONSTRAINTS:
   memory available to the application.
 
 * It may be defined through
-  :c:func:`rtems_resource_unlimited` the enable unlimited objects for this
-  object class, if the value passed to :c:func:`rtems_resource_unlimited`
-  satisfies all other constraints of this configuration option.
+  ``rtems_resource_unlimited()`` the enable unlimited objects for
+  this object class, if the value passed to
+  ``rtems_resource_unlimited()`` satisfies all other constraints
+  of this configuration option.
 
 DESCRIPTION:
 The value of this configuration option defines the maximum number of 
Classic
@@ -78,9 +79,10 @@ VALUE CONSTRAINTS:
   memory available to the application.
 
 * It may be defined through
-  :c:func:`rtems_resource_unlimited` the enable unlimited objects for this
-  object class, if the value passed to :c:func:`rtems_resource_unlimited`
-  satisfies all other constraints of this configuration option.
+  ``rtems_resource_unlimited()`` the enable unlimited objects for
+  this object class, if the value passed to
+  ``rtems_resource_unlimited()`` satisfies all other constraints
+  of this configuration option.
 
 DESCRIPTION:
 The value of this configuration option defines the maximum number of 
Classic
@@ -121,9 +123,10 @@ VALUE CONSTRAINTS:
   memory available to the application.
 
 * It may be defined through
-  :c:func:`rtems_resource_unlimited` the enable unlimited objects for this
-  object class, if the value passed to :c:func:`rtems_resource_unlimited`
-  satisfies all other constraints of this configuration option.
+  ``rtems_resource_unlimited()`` the enable unlimited objects for
+  this object class, if the value passed to
+  ``rtems_resource_unlimited()`` satisfies all other constraints
+  of this configuration option.
 
 DESCRIPTION:
 The value of this configuration option defines the maximum number of 
Classic
@@ -162,9 +165,10 @@ VALUE CONSTRAINTS:
   memory available to the application.
 
 * It may be defined through
-  :c:func:`rtems_resource_unlimited` the enable unlimited objects for this
-  object class, if the value passed to :c:func:`rtems_resource_unlimited`
-  satisfies all other constraints of this configuration option.
+  ``rtems_resource_unlimited()`` the enable unlimited objects for
+  this object class, if the value passed to
+  ``rtems_resource_unlimited()`` satisfies all other constraints
+  of this configuration option.
 
 DESCRIPTION:
 The value of this configuration option defines the maximum number of 
Classic
@@ -203,9 +207,10 @@ VALUE CONSTRAINTS:
   memory available to the application.
 
 * It may be defined through
-  :