<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 27, 2021 at 1:14 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<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/01/2021 23:44, Chris Johns wrote:<br>
<br>
> On 23/1/21 12:19 am, Gedare Bloom wrote:<br>
> On Fri, Jan 22, 2021 at 5:55 AM Andrew Butterfield<br>
>> <<a href="mailto:Andrew.Butterfield@scss.tcd.ie" target="_blank">Andrew.Butterfield@scss.tcd.ie</a> <mailto:<a href="mailto:Andrew.Butterfield@scss.tcd.ie" target="_blank">Andrew.Butterfield@scss.tcd.ie</a>>> wrote:<br>
>><br>
>> Hi Sebastian,<br>
>><br>
>> I'd prefer 2.<br>
>><br>
>> The directive may be called from an interrupt context<br>
>><br>
>> (substituting "must", "must not", as appropriate)<br>
>><br>
>> Yes, I agree. (Use of "in" is ambiguous here, because "called in" has a meaning<br>
>> in colloquial speech that differs from the intent here.)<br>
> "The directive may be called from within an interrupt context."<br>
><br>
> ?<br>
><br>
> A context is a area, region or bounded "space" (what this means) so I suggest<br>
> "from within"? And this also lets you use "this call cannot be made from outside<br>
> an interrupt context".<br>
<br>
The "from within" is fine for me, you are the native speakers.<br>
<br></blockquote><div>Also fine, it does allow consistency with the second form, if needed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
After reviewing the documentation, I found these contexts relevant to <br>
the API:<br>
<br>
1. constant expressions (for example rtems_build_name(), <br>
rtems_resource_unlimited())<br>
<br>
2. runtime context (for example rtems_clock_get_ticks_per_second(), <br>
rtems_configuration_get_maximum_barriers(); better name for the context?)<br>
<br></blockquote><div>I don't quite understand this context. I guess it is "all other contexts"? or a combination of "interrupt context or task context or initialization context"?</div><div><br></div><div>Mechanically, it might be better to enumerate all the contexts in which a directive may be called?</div><div>This directive may be called from within task context.</div><div>This directive may be called from within interrupt context.</div><div>This directive must not be called from within termination context.</div><div><br></div><div>That might be verbose, but it would be very clear.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
3. interrupt context<br>
<br>
4. device driver initialization context (this is just a special case <br>
during system initialization, in this area we have a lot more <br>
"contexts", however, I think only this one visible via the API; the <br>
stack allocator initialization handler is an exception)<br></blockquote><div><br></div><div>maybe, "initialization context" is ok?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
5. task context<br>
<br>
6. fatal error context (I am not sure about the name, this is more <br>
generally the system termination context, however, through the API you <br>
end up here via the fatal error user extension)<br></blockquote><div><br></div><div>"termination context" would seem ok to me also, I guess it can be reached without necessarily a fatal error? or not?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I think 1. implies 2., 2. implies 3., 3. implies 4., and 4. implies 5. <br>
The question is if we want to use this reasoning to compact the <br>
constraints list for the directives.<br>
<br></blockquote><div>I think it is helpful to be precise about context when it matters. I don't think 2 implies 3 and 3 implies 4 makes sense. Interrupt context is a separate context to </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Another question is if we want to explicitly mention 5. I think the only <br>
directive which cannot be called in task context is <br>
rtems_initialize_executive().<br>
<br></blockquote><div><br></div><div>Countering my own argument above, we could also simplify by using some implicit rules that are made clear, such as "unless otherwise specified, all API calls can be made from task context" or even just enumerate the contexts from which an API directive can not be called, if that is somehow simpler?</div><div><br></div><div>Sorry, I'm not sure what is best to do. This will be a great contribution to the API documentation though.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-- <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>
<br>
</blockquote></div></div>