<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 19, 2021, 10:31 AM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Feb 18, 2021 at 11:56 PM Sebastian Huber<br>
<<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a>> wrote:<br>
><br>
> On 18/02/2021 20:25, Joel Sherrill wrote:<br>
><br>
> >     > -  /*<br>
> >     > -   * api may be NULL in case of a thread close in progress<br>
> >     > -   */<br>
> >     > -  if ( !api )<br>
> >     > -    return;<br>
> >     > -<br>
> >     I believe you, but should we replace this with an assert for now?<br>
> ><br>
> ><br>
> > And a comment explaining why it can't be NULL.<br>
><br>
> This is not the only place which uses<br>
><br>
> api = executing->API_Extensions[ THREAD_API_POSIX ];<br>
><br>
> or<br>
><br>
> api = executing->API_Extensions[ THREAD_API_RTEMS ];<br>
><br>
> I don't think it makes sense to add a comment to all these places.<br>
><br>
> While looking at this, I think we should remove this API_Extensions<br>
> indirection and add the structures directly to Thread_Control. This<br>
> makes the code more efficient, simpler, faster, and easier to debug.<br>
><br>
<br>
I think this makes sense from an object-oriented perspective. But,<br>
does it (greatly) increase the memory consumption for a system that<br>
uses classic tasks but enables posix?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Enable POSIX is now misnamed and should have been changed. It only enables some POSIX signals support. But in a review of an executable recently, I realized that posix signal apis inside our teams were built even though they were fundamentally non-functional. </div><div dir="auto"><br></div><div dir="auto">Moving this inside may make sense on one level but it breaks the fundamental layering in the design of the super core. The design intent was to not embed knowledge of any particular API in the super core. Thus the apis are viewed as extensions.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> We just have to move a couple of typedefs to score to define these<br>
> structures in thread.h.<br>
><br>
> #if defined(RTEMS_POSIX_API)<br>
> /**<br>
>   * This defines the POSIX API support structure associated with<br>
>   * each thread in a system with POSIX configured.<br>
>   */<br>
> typedef struct {<br>
>    /**<br>
>     * @brief Control block for the sporadic server scheduling policy.<br>
>     */<br>
>    struct {<br>
>      /** The thread of this sporadic control block */<br>
>      Thread_Control *thread;<br>
><br>
>      /**<br>
>       * @brief This is the timer which controls when the thread executes<br>
> at high<br>
>       * and low priority when using the sporadic server scheduling policy.<br>
>       */<br>
>      Watchdog_Control Timer;<br>
><br>
>      /**<br>
>       * @brief The low priority when using the sporadic server scheduling<br>
>       * policy.<br>
>       */<br>
>      Priority_Node Low_priority;<br>
><br>
>      /**<br>
>       * @brief Replenishment period for sporadic server.<br>
>       */<br>
>      struct timespec sched_ss_repl_period;<br>
><br>
>      /**<br>
>       * @brief Initial budget for sporadic server.<br>
>       */<br>
>      struct timespec sched_ss_init_budget;<br>
><br>
>      /**<br>
>       * @brief Maximum pending replenishments.<br>
>       *<br>
>       * Only used by pthread_getschedparam() and pthread_getattr_np().<br>
>      */<br>
>      int sched_ss_max_repl;<br>
>    } Sporadic;<br>
><br>
>    /** This is the set of signals which are currently unblocked. */<br>
>    sigset_t                signals_unblocked;<br>
>    /** This is the set of signals which are currently pending. */<br>
>    sigset_t                signals_pending;<br>
><br>
>    /**<br>
>     * @brief Signal post-switch action in case signals are pending.<br>
>     */<br>
>    Thread_Action           Signal_action;<br>
> } POSIX_API_Control;<br>
><br>
> /**<br>
>   *  This is the API specific information required by each thread for<br>
>   *  the RTEMS API to function correctly.<br>
>   *<br>
>   */<br>
> typedef struct {<br>
>    /** This field contains the event control for this task. */<br>
>    Event_Control            Event;<br>
>    /** This field contains the system event control for this task. */<br>
>    Event_Control            System_event;<br>
>    /** This field contains the Classic API Signal information for this<br>
> task. */<br>
>    ASR_Information          Signal;<br>
><br>
>    /**<br>
>     * @brief Signal post-switch action in case signals are pending.<br>
>     */<br>
>    Thread_Action            Signal_action;<br>
> }  RTEMS_API_Control;<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" rel="noreferrer">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 noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
><br>
</blockquote></div></div></div>