Thread name support
Hello, I added optional user-defined thread names. https://devel.rtems.org/ticket/2858 The GNU pthread extensions pthread_getname_np() and pthread_setname_np() are now available in RTEMS and work for all threads (internal, Classic, POSIX, FreeBSD). http://man7.org/linux/man-pages/man3/pthread_setname_np.3.html The maximum thread name size is a configuration option (CONFIGURE_MAXIMUM_THREAD_NAME_SIZE). Where should this new feature be documented in the C 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
Re: [PATCH] powerpc/shared/linkcmds.base: Add .rela.rtemsroset and .rela.rtemsrwset
Maybe it makes sense to add this to the other linkcmds.base as well.
On 12/01/17 23:13, Joel Sherrill wrote:
---
.../libbsp/powerpc/shared/startup/linkcmds.base|2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/c/src/lib/libbsp/powerpc/shared/startup/linkcmds.base
b/c/src/lib/libbsp/powerpc/shared/startup/linkcmds.base
index 296dd6d..072bde1 100644
--- a/c/src/lib/libbsp/powerpc/shared/startup/linkcmds.base
+++ b/c/src/lib/libbsp/powerpc/shared/startup/linkcmds.base
@@ -227,6 +227,8 @@ SECTIONS {
*(.rela.sdata2 .rela.sdata2.* .rela.gnu.linkonce.s2.*)
*(.rela.sbss2 .rela.sbss2.* .rela.gnu.linkonce.sb2.*)
*(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
+ *(.rela.rtemsroset*)
+ *(.rela.rtemsrwset*)
PROVIDE_HIDDEN (__rel_iplt_start = .);
PROVIDE_HIDDEN (__rel_iplt_end = .);
PROVIDE_HIDDEN (__rela_iplt_start = .);
--
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] configure: Add RTEMS_TOOL_CHAIN_ERROR
On 12/01/17 22:44, Joel Sherrill wrote: I repeat that I would like to purge old tests that result in conditionals in source code we no longer need. So any HAVE_XXX that are a side effect of transitioning newlib additions should be removed. I removed three tests today which I added in the last two years or so. -- 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] configure: Add RTEMS_TOOL_CHAIN_ERROR
On 13/01/17 09:48, Sebastian Huber wrote: On 12/01/17 22:44, Joel Sherrill wrote: I repeat that I would like to purge old tests that result in conditionals in source code we no longer need. So any HAVE_XXX that are a side effect of transitioning newlib additions should be removed. I removed three tests today which I added in the last two years or so. I removed a couple of more obsolete configure stuff. I am done for now. -- 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] configure: Add RTEMS_TOOL_CHAIN_ERROR
On Fri, Jan 13, 2017 at 4:47 AM, Sebastian Huber wrote: > On 13/01/17 09:48, Sebastian Huber wrote: > >> On 12/01/17 22:44, Joel Sherrill wrote: >> >>> I repeat that I would like to purge old tests that result in >>> conditionals in >>> source code we no longer need. So any HAVE_XXX that are a side >>> effect of transitioning newlib additions should be removed. >>> >> >> I removed three tests today which I added in the last two years or so. >> > > I removed a couple of more obsolete configure stuff. I am done for now. > > Thanks. It is a continuous battle of creep and push back. Without looking, I am sure you are right that __RTEMS_DO_NOT_ INLINE_THREAD_ENABLE_DISPATCH__ is no longer used but it did serve a purpose that may have been lost in all the rework. When doing coverage testing, inlining a method with one of more conditionals increases the cyclomatic complexity of the calling method and number of test cases required to do full coverage of all branch paths. That flag eliminated at least 250 paths to test in the generated code. With the rework, did anything get inlined lots of times that includes a conditional test? If so, then the calling method has hidden cyclomatic complexity and requires increased test cases for full coverage. I am pretty sure this is written down as advice in the coverage area but I have no idea how to turn it into good solid coding style/rules. The best I can formulate is: Inlining a method requires that it be fully tested in the context of each place it is called. Inlining complex methods with conditionals is undesirable from a coverage testing viewpoint. Try to inline only simple methods. --joel > > -- > 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] powerpc/shared/linkcmds.base: Add .rela.rtemsroset and .rela.rtemsrwset
On Fri, Jan 13, 2017 at 2:28 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Maybe it makes sense to add this to the other linkcmds.base as well.
>
>
No problem. Is this the list of files?
arm/shared/startup/linkcmds.base
m68k/shared/startup/linkcmds.base
or1k/shared/startup/linkcmds.base
powerpc/gen5200/startup/linkcmds.base
powerpc/shared/startup/linkcmds.base
powerpc/tqm8xx/startup/linkcmds.base
sparc/shared/startup/linkcmds.base
> On 12/01/17 23:13, Joel Sherrill wrote:
>
>> ---
>> .../libbsp/powerpc/shared/startup/linkcmds.base|2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/c/src/lib/libbsp/powerpc/shared/startup/linkcmds.base
>> b/c/src/lib/libbsp/powerpc/shared/startup/linkcmds.base
>> index 296dd6d..072bde1 100644
>> --- a/c/src/lib/libbsp/powerpc/shared/startup/linkcmds.base
>> +++ b/c/src/lib/libbsp/powerpc/shared/startup/linkcmds.base
>> @@ -227,6 +227,8 @@ SECTIONS {
>> *(.rela.sdata2 .rela.sdata2.* .rela.gnu.linkonce.s2.*)
>> *(.rela.sbss2 .rela.sbss2.* .rela.gnu.linkonce.sb2.*)
>> *(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
>> + *(.rela.rtemsroset*)
>> + *(.rela.rtemsrwset*)
>> PROVIDE_HIDDEN (__rel_iplt_start = .);
>> PROVIDE_HIDDEN (__rel_iplt_end = .);
>> PROVIDE_HIDDEN (__rela_iplt_start = .);
>>
>
> --
> 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
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Thread name support
On Fri, Jan 13, 2017 at 3:25 AM, Sebastian Huber wrote: > Hello, > > I added optional user-defined thread names. > > https://devel.rtems.org/ticket/2858 > > The GNU pthread extensions pthread_getname_np() and pthread_setname_np() are > now available in RTEMS and work for all threads (internal, Classic, POSIX, > FreeBSD). > > http://man7.org/linux/man-pages/man3/pthread_setname_np.3.html > > The maximum thread name size is a configuration option > (CONFIGURE_MAXIMUM_THREAD_NAME_SIZE). > > Where should this new feature be documented in the C user manual? > I guess at posix-users/thread.rst? I don't know if we have a list of function calls that work across the APIs, but I know quite a few do. > -- > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] rtems: define _POSIX_SHARED_MEMORY_OBJECTS
---
newlib/libc/include/sys/features.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/newlib/libc/include/sys/features.h
b/newlib/libc/include/sys/features.h
index a23158c..1f9271b 100644
--- a/newlib/libc/include/sys/features.h
+++ b/newlib/libc/include/sys/features.h
@@ -333,7 +333,7 @@ extern "C" {
#define _POSIX_PRIORITY_SCHEDULING 1
#define _POSIX_REALTIME_SIGNALS1
#define _POSIX_SEMAPHORES 1
-/* #define _POSIX_SHARED_MEMORY_OBJECTS1 */
+#define _POSIX_SHARED_MEMORY_OBJECTS 1
#define _POSIX_SYNCHRONIZED_IO 1
#define _POSIX_TIMERS 1
#define _POSIX_BARRIERS 200112L
--
1.9.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
What's Left for 4.12 Branching?
Hi What do we think is left to do before we can branch 4.12? Code Issues == >From my perspective, I think my POSIX API goals have been met with the posix_devctl and SHM patches. There may be patches but that's normal. Any other code issues? Tool Issues = A new newlib snapshot would be welcomed and I thought a binutils release was coming up. AFAIK All looks for C/C++, most look good for Fortran. I don't know about Ada. I have a patch to drop soft-float for rtems i386 gcc. This let's Fortran build. I have a similar patch which drops SH multilibs where there is only single precision FP. This solves the Fortran build issue and a long standing Ada build issue. m68k Fortran causes an ICE on soft float. We need soft-float on that target so this is a wait and track. Any other tool issues? Documentation Issues == My feeling is that documentation issues are the long pole at this point. Chris has been working hard on this but there is still stuff to do. Chris.. care to share with us what your goals are and what we can do to help? I need to add a posix_devctl() page and I expect Gedare has some documentation to add on his work. Any other documentation issues? Anything I missed? --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Update RMS documentation for overrun handling
I was unable to compile rtems-docs (cleanly), so I have not committed this patch yet. If someone else who can compile docs can build with this patch, please commit. I need to debug my baseline build still... On Wed, Dec 21, 2016 at 11:44 AM, Kuan-Hsun Chen wrote: > --- > c-user/rate_monotonic_manager.rst | 30 +- > 1 file changed, 17 insertions(+), 13 deletions(-) > > diff --git a/c-user/rate_monotonic_manager.rst > b/c-user/rate_monotonic_manager.rst > index 8ad74e5..9ba22a5 100644 > --- a/c-user/rate_monotonic_manager.rst > +++ b/c-user/rate_monotonic_manager.rst > @@ -132,7 +132,7 @@ milliseconds every 100 (10 percent of the CPU). As a > general rule of thumb, > the higher frequency at which a task executes, the more important it is to > optimize that task. > > -Rate Monotonic Manager Definitions > +Periodicity Definitions > -- > .. index:: periodic task, definition > > @@ -170,7 +170,7 @@ Rate Monotonic Scheduling Algorithm > .. index:: RMS Algorithm, definition > > The Rate Monotonic Scheduling Algorithm (RMS) is important to real-time > systems > -designers because it allows one to guarantee that a set of tasks is > +designers because it allows one to sufficiently guarantee that a set of > tasks is > schedulable. A set of tasks is said to be schedulable if all of the tasks > can > meet their deadlines. RMS provides a set of rules which can be used to > perform > a guaranteed schedulability analysis for a task set. This analysis > determines > @@ -179,11 +179,11 @@ the predictability of the system's behavior. It has > been proven that: > > .. sidebar:: *RMS* > > - RMS is an optimal static priority algorithm for scheduling independent, > + RMS is an optimal fixed-priority algorithm for scheduling independent, >preemptible, periodic tasks on a single processor. > > RMS is optimal in the sense that if a set of tasks can be scheduled by any > -static priority algorithm, then RMS will be able to schedule that task set. > +fixed-priority algorithm, then RMS will be able to schedule that task set. > RMS bases it schedulability analysis on the processor utilization level below > which all deadlines can be met. > > @@ -230,7 +230,7 @@ Schedulability Analysis > > .. index:: RMS schedulability analysis > > -RMS allows application designers to ensure that tasks can meet all deadlines, > +RMS allows application designers to ensure that tasks can meet all deadlines > under fixed-priority assignment, > even under transient overload, without knowing exactly when any given task > will > execute by applying proven schedulability analysis rules. > > @@ -468,9 +468,10 @@ monotonic period results in one of the following > scenarios: >immediately. > > - If the rate monotonic period has expired before the task invokes the > - ``rtems_rate_monotonic_period`` directive, the period will be initiated > with > - a length of period ticks and the calling task returns immediately with a > - timeout error status. > + ``rtems_rate_monotonic_period`` directive, the postponed job will be > released > + until there is no more postponed jobs. The calling task returns immediately > + with a timeout error status. In the watchdog routine, the period will still > + be updated periodically and track the number of the postponed periods. > > Obtaining the Status of a Period > > @@ -560,8 +561,8 @@ Subsequent invocations of the > ``rtems_rate_monotonic_period`` directive will > result in the task blocking for the remainder of the 100 tick period. If, > for > any reason, the body of the loop takes more than 100 ticks to execute, the > ``rtems_rate_monotonic_period`` directive will return the ``RTEMS_TIMEOUT`` > -status. If the above task misses its deadline, it will delete the rate > -monotonic period and itself. > +status and the postponed job will be released. If the above task misses > +its deadline, it will delete the rate monotonic period and itself. > > Task with Multiple Periods > -- > @@ -629,8 +630,8 @@ will not block. > > If, for any reason, the task misses any deadline, the > ``rtems_rate_monotonic_period`` directive will return the ``RTEMS_TIMEOUT`` > -directive status. If the above task misses its deadline, it will delete the > -rate monotonic periods and itself. > +directive status and the postponed job will be released. If the above task > misses > +its deadline, it will delete the rate monotonic periods and itself. > > Directives > == > @@ -839,7 +840,10 @@ DESCRIPTION: > period ticks. If id is running, then the calling task will block for the > remainder of the period before reinitiating the period with the specified > period. If id was not running (either expired or never initiated), the > -period is immediately initiated and the directive returns immediately. > +period is immediately initiated and the directi
Re: [PATCH] Update RMS documentation for overrun handling
I have committed this. If there are academic references that a user should know or this is theoretically based on, I would like to see them listed. Anything that strengthens the user's understanding of where this originated. It doesn't look like Chris has automatic updates on docs working yet but it should show up before too long at https://docs.rtems.org/. Thanks. --joel On Fri, Jan 13, 2017 at 3:21 PM, Gedare Bloom wrote: > I was unable to compile rtems-docs (cleanly), so I have not committed > this patch yet. If someone else who can compile docs can build with > this patch, please commit. I need to debug my baseline build still... > > On Wed, Dec 21, 2016 at 11:44 AM, Kuan-Hsun Chen wrote: > > --- > > c-user/rate_monotonic_manager.rst | 30 +- > > 1 file changed, 17 insertions(+), 13 deletions(-) > > > > diff --git a/c-user/rate_monotonic_manager.rst b/c-user/rate_monotonic_ > manager.rst > > index 8ad74e5..9ba22a5 100644 > > --- a/c-user/rate_monotonic_manager.rst > > +++ b/c-user/rate_monotonic_manager.rst > > @@ -132,7 +132,7 @@ milliseconds every 100 (10 percent of the CPU). As > a general rule of thumb, > > the higher frequency at which a task executes, the more important it is > to > > optimize that task. > > > > -Rate Monotonic Manager Definitions > > +Periodicity Definitions > > -- > > .. index:: periodic task, definition > > > > @@ -170,7 +170,7 @@ Rate Monotonic Scheduling Algorithm > > .. index:: RMS Algorithm, definition > > > > The Rate Monotonic Scheduling Algorithm (RMS) is important to real-time > systems > > -designers because it allows one to guarantee that a set of tasks is > > +designers because it allows one to sufficiently guarantee that a set of > tasks is > > schedulable. A set of tasks is said to be schedulable if all of the > tasks can > > meet their deadlines. RMS provides a set of rules which can be used to > perform > > a guaranteed schedulability analysis for a task set. This analysis > determines > > @@ -179,11 +179,11 @@ the predictability of the system's behavior. It > has been proven that: > > > > .. sidebar:: *RMS* > > > > - RMS is an optimal static priority algorithm for scheduling > independent, > > + RMS is an optimal fixed-priority algorithm for scheduling independent, > >preemptible, periodic tasks on a single processor. > > > > RMS is optimal in the sense that if a set of tasks can be scheduled by > any > > -static priority algorithm, then RMS will be able to schedule that task > set. > > +fixed-priority algorithm, then RMS will be able to schedule that task > set. > > RMS bases it schedulability analysis on the processor utilization level > below > > which all deadlines can be met. > > > > @@ -230,7 +230,7 @@ Schedulability Analysis > > > > .. index:: RMS schedulability analysis > > > > -RMS allows application designers to ensure that tasks can meet all > deadlines, > > +RMS allows application designers to ensure that tasks can meet all > deadlines under fixed-priority assignment, > > even under transient overload, without knowing exactly when any given > task will > > execute by applying proven schedulability analysis rules. > > > > @@ -468,9 +468,10 @@ monotonic period results in one of the following > scenarios: > >immediately. > > > > - If the rate monotonic period has expired before the task invokes the > > - ``rtems_rate_monotonic_period`` directive, the period will be > initiated with > > - a length of period ticks and the calling task returns immediately > with a > > - timeout error status. > > + ``rtems_rate_monotonic_period`` directive, the postponed job will be > released > > + until there is no more postponed jobs. The calling task returns > immediately > > + with a timeout error status. In the watchdog routine, the period will > still > > + be updated periodically and track the number of the postponed periods. > > > > Obtaining the Status of a Period > > > > @@ -560,8 +561,8 @@ Subsequent invocations of the > ``rtems_rate_monotonic_period`` directive will > > result in the task blocking for the remainder of the 100 tick period. > If, for > > any reason, the body of the loop takes more than 100 ticks to execute, > the > > ``rtems_rate_monotonic_period`` directive will return the > ``RTEMS_TIMEOUT`` > > -status. If the above task misses its deadline, it will delete the rate > > -monotonic period and itself. > > +status and the postponed job will be released. If the above task misses > > +its deadline, it will delete the rate monotonic period and itself. > > > > Task with Multiple Periods > > -- > > @@ -629,8 +630,8 @@ will not block. > > > > If, for any reason, the task misses any deadline, the > > ``rtems_rate_monotonic_period`` directive will return the > ``RTEMS_TIMEOUT`` > > -directive status. If the above task misses its deadline, it will > delete the > > -rate monotonic p
Re: [PATCH] Update RMS documentation for overrun handling
On 14/1/17 8:21 am, Gedare Bloom wrote: > I was unable to compile rtems-docs (cleanly), so I have not committed > this patch yet. What is the problem? > If someone else who can compile docs can build with > this patch, please commit. I need to debug my baseline build still... OK. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Lots of BSPs Fail to Build Tests on Master
Hi The following BSPs do not successfully complete a build with all tests enabled. A spot check of a few shows that some tests do not fit in memory. There may be other issues. This is a major regression. arm-lm3s3749 arm-lm3s6965 arm-lm4f120 arm-lpc1768_mbed_ahb_ram_eth arm-lpc1768_mbed_ahb_ram arm-lpc1768_mbed arm-lpc17xx_ea_rom_int arm-lpc17xx_plx800_rom_int arm-lpc2362 arm-lpc23xx_tli800 arm-lpc24xx_ncs_rom_int arm-lpc24xx_plx800_rom_int arm-lpc32xx_mzx_stage_1 arm-lpc40xx_ea_rom_int arm-rtl22xx arm-rtl22xx_t arm-stm32f105rc arm-stm32f4 arm-tms570ls3137_hdk_intram epiphany-epiphany_sim m32c-m32csim m68k-mcf5206elite m68k-mcf52235 m68k-mcf5225x m68k-mrm332 mips-hurricane mips-rbtx4925 mips-rbtx4938 moxie-moxiesim nios2-nios2_iss or1k-generic_or1k powerpc-gwlcfm powerpc-mpc5566evb powerpc-mpc5566evb_spe powerpc-mpc5643l_dpu powerpc-mpc5643l_evb powerpc-mpc5674f_ecu508_boot powerpc-mpc5674f_rsm6 powerpc-phycore_mpc5554 sh-gensh1 sh-gensh2 sh-simsh1 sh-simsh2e sh-simsh2 sh-simsh4 --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: What's Left for 4.12 Branching?
On 14/1/17 6:25 am, Joel Sherrill wrote: > > What do we think is left to do before we can branch 4.12? > Libbsd needs testing after the major update from Sebastian. The i386 BSP needs to work before we can branch. > > Code Issues > == > From my perspective, I think my POSIX API goals have > been met with the posix_devctl and SHM patches. There > may be patches but that's normal. > > Any other code issues? > I have some FDT support code I would like to merge. > Tool Issues > = > A new newlib snapshot would be welcomed and I thought > a binutils release was coming up. > > AFAIK All looks for C/C++, most look good for Fortran. > I don't know about Ada. > > I have a patch to drop soft-float for rtems i386 gcc. This > let's Fortran build. > > I have a similar patch which drops SH multilibs where > there is only single precision FP. This solves the Fortran > build issue and a long standing Ada build issue. > > m68k Fortran causes an ICE on soft float. We need soft-float > on that target so this is a wait and track. > > Any other tool issues? > > Documentation Issues > == > My feeling is that documentation issues are the long pole > at this point. Chris has been working hard on this but there > is still stuff to do. Chris.. care to share with us what your > goals are and what we can do to help? I have changes to add the commands in the RTEMS Tools Project and I plan to add a section on Applications to the User Manual. This will contain, what is an application, configuration workflows, and building with waf and maybe make. I have https://docs.rtems.org/ up and running. It is an initial working cut to get the baseline stable before I push onto fixing a few remaining issues. The site generates the content from XML catalogue files which are automatically generated for the ReST based documentation. The legacy documentation catalogues are generated from a configuration file held in my personal repo rtems-admin.git. Outstanding are: 1. Add support for released ReST documentation. 2. Automatic updates after a commit on master and branches. 3. Add doxygen docs after each commit. Maybe for 4.10, and 4.11 releases. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
