<div dir="ltr"><font size="2"><span style="font-family:arial,sans-serif">Thank you for the quick reply.

<span class="gmail-ui-provider gmail-chh gmail-chi gmail-c gmail-d gmail-e gmail-f gmail-g gmail-h gmail-i gmail-j gmail-k gmail-l gmail-m gmail-n gmail-o gmail-p gmail-q gmail-r gmail-s gmail-t gmail-chj gmail-chk gmail-w gmail-x gmail-y gmail-z gmail-ab gmail-ac gmail-ae gmail-af gmail-ag gmail-ah gmail-ai gmail-aj gmail-ak" dir="ltr"><span style="white-space:pre-wrap"><span class="gmail-ui-provider gmail-chh gmail-chi gmail-c gmail-d gmail-e gmail-f gmail-g gmail-h gmail-i gmail-j gmail-k gmail-l gmail-m gmail-n gmail-o gmail-p gmail-q gmail-r gmail-s gmail-t gmail-chj gmail-chk gmail-w gmail-x gmail-y gmail-z gmail-ab gmail-ac gmail-ae gmail-af gmail-ag gmail-ah gmail-ai gmail-aj gmail-ak" dir="ltr"><font size="2"><span style="font-family:arial,sans-serif"><span style="white-space:pre-wrap">We agree that it is in fact inconvenient for each user having to provide a custom stack allocator in order to be able to use the Timer Server feature. It makes a lot of sense to us and ESA to have this new rtems_timer_server_construct directive available<span class="gmail_default"> to the space industry, thus avoiding the custom stack allocator, which adds inefficiency to the development process and might be more prone to failure.

</p><p>Best regards,</p></span></span></font></span></span></span><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><br></div><div>Luís Alves</div></div></div></div></div></div></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Critical Software</div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> escreveu no dia sexta, 23/09/2022 à(s) 12:55:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 23.09.22 13:19, Luis Alves wrote:<br>

> Dear RTEMS community,<br>

> <br>

> I’m part of the team performing the Independent Software Verification <br>

> and Validation (ISVV) of the RTEMS SMP Qualification Data Pack (which is <br>

> being provided through <a href="https://rtems-qual.io.esa.int/" rel="noreferrer" target="_blank">https://rtems-qual.io.esa.int/</a> <br>

> <<a href="https://rtems-qual.io.esa.int/" rel="noreferrer" target="_blank">https://rtems-qual.io.esa.int/</a>>).<br>

> <br>

> While trying to setup tests to assert the overall “Timer Server” <br>

> feature, one has realized that:<br>

> <br>

>   * Although rtems_timer_initiate_server() is mentioned within section<br>

>     4.10 of the SW Configuration File (SCF) as a pre-qualified item<br>

>     (“/which may be directly used by applications/”), one gets build<br>

>     issues while trying to use it, as it depends on rtems_timer_create().<br>

<br>

Yes.<br>

<br>

>   * The same SCF (within section 4.9.3) also says: “/The<br>

>     rtems_task_create() directive is pre-qualified, however, it is only<br>

>     available if a custom stack allocator is configured. It is<br>

>     recommended to use rtems_task_construct() instead/”:<br>

>       o Isn’t this contradictory, as:<br>

>           + Both rtems_timer_initiate_server() and tems_task_create()<br>

>             are listed within SCF section 4.10 and<br>

>           + at the start of section 4.10, it is said that listed items<br>

>             are “/pre-qualified items .. which may be directly used by<br>

>             applications/”? <br>

<br>

For the current pre-qualified feature set of RTEMS, if you want to use <br>

rtems_timer_initiate_server(), then you have to provide a custom stack <br>

allocator.<br>

<br>

>   * Given this, shouldn’t rtems_timer_initiate_server() natively use of<br>

>     rtems_task_construct() rather than rtems_timer_create() as advised?<br>

<br>

If you don't want to change the API of rtems_timer_initiate_server(), <br>

how can you do this?<br>

<br>

>   * This makes other two functions listed within SCF section 4.10 as not<br>

>     directly usable, namely rtems_timer_server_fire_after() and<br>

>     rtems_timer_server_fire_when() as those are to be used in<br>

>     conjunction with rtems_timer_initiate_server().<br>

<br>

You can use them, if you provide a custom stack allocator.<br>

<br>

>   * In a nutshell, this compromises the overall “Timer Server” feature<br>

>     in the qual-only setup of the QDP.<br>

<br>

I just makes it a bit inconvenient to use. One option would be to <br>

provide a new directive to construct the timer server, for example <br>

rtems_timer_server_construct().<br>

<br>

-- <br>

embedded brains GmbH<br>

Herr Sebastian HUBER<br>

Dornierstr. 4<br>

82178 Puchheim<br>

Germany<br>

email: <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>

phone: +49-89-18 94 741 - 16<br>

fax:   +49-89-18 94 741 - 08<br>

<br>

Registergericht: Amtsgericht München<br>

Registernummer: HRB 157899<br>

Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>

Unsere Datenschutzerklärung finden Sie hier:<br>

<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>

</blockquote></div>