Re: Need help in understanding some of the existing code in RTEMS

> > It was difficult to find this mail. Descriptive subjects would be helpful. Thank you for your efforts. I understand. Here are important scheduler-specific macros: > https://git.rtems.org/rtems/tree/cpukit/include/rtems/scheduler.h#n131 Exactly what I was looking for! Thanks. On Thu, Jul 30,

Re: Need help in understanding some of the existing code in RTEMS

On 13/07/2020 13:27, Richi Dubey wrote: We use a zero-length array  in the definition of Scheduler_EDF_SMP_Context, but I can not see any code in scheduleredfsmp.c (https://git.rtems.org/rtems/tree/cpukit/scor

Re: Need help in understanding some of the existing code in RTEMS

On Tue, Jul 28, 2020 at 7:23 AM Richi Dubey wrote: > > Hi, > > I do not have much expertise in timers. I was wondering what the name ACTN > means/defines in the following context: > https://git.rtems.org/rtems/tree/testsuites/smptests/smpschededf02/init.c#n368 > > Please let me know. > Names are

Re: Need help in understanding some of the existing code in RTEMS

Hi, I do not have much expertise in timers. I was wondering what the name ACTN means/defines in the following context: https://git.rtems.org/rtems/tree/testsuites/smptests/smpschededf02/init.c#n368 Please let me know. On Wed, Jul 22, 2020 at 6:46 PM Richi Dubey wrote: > Thank you for the clari

Re: Need help in understanding some of the existing code in RTEMS

Thank you for the clarification. On Sat, Jul 18, 2020 at 9:06 PM Gedare Bloom wrote: > On Fri, Jul 17, 2020 at 2:22 AM Richi Dubey wrote: > >> > >> > >> > Scheduler_Node *nodes; > >> > } Thread_Scheduler_control; > >> > > >> > Why do we have a Scheduler_Node *nodes? What does it indicate? Sin

Re: Need help in understanding some of the existing code in RTEMS

On Fri, Jul 17, 2020 at 2:22 AM Richi Dubey wrote: >> >> >> > Scheduler_Node *nodes; >> > } Thread_Scheduler_control; >> > >> > Why do we have a Scheduler_Node *nodes? What does it indicate? Since the >> > pointer can point to a single value, why is it being called nodes? >> > >> See cpukit/sco

Re: Need help in understanding some of the existing code in RTEMS

> > During system startup the application configuration defines which > processor is available to RTEMS. Every configured and present processor > gets an idle thread assigned which is managed by a scheduler. This is > the starting point of the system. If someone calls > rtems_scheduler_remove_proce

Re: Need help in understanding some of the existing code in RTEMS

> > > > Scheduler_Node *nodes; > > } Thread_Scheduler_control; > > > > Why do we have a Scheduler_Node *nodes? What does it indicate? Since the > pointer can point to a single value, why is it being called nodes? > > > See cpukit/score/src/threadinitialize.c +153 Thank you for your help. /**

Re: Need help in understanding some of the existing code in RTEMS

On 15/07/2020 14:55, Richi Dubey wrote: On Wed, Jul 15, 2020 at 5:57 PM Richi Dubey > wrote: Hi, I had a small question. The scheduler struct inside percpu.h looks like: --

Re: Need help in understanding some of the existing code in RTEMS

On Wed, Jul 15, 2020 at 6:55 AM Richi Dubey wrote: > > Another quick question: > typedef struct { > > #if defined(RTEMS_SMP) > ... > Chain_Control Scheduler_nodes; > > #endif > /** >* @brief The scheduler nodes of this thread. >* >* Each thread has a scheduler node for each scheduler

Re: Need help in understanding some of the existing code in RTEMS

Another quick question: typedef struct { #if defined(RTEMS_SMP) ... Chain_Control Scheduler_nodes; #endif /** * @brief The scheduler nodes of this thread. * * Each thread has a scheduler node for each scheduler instance. */ Scheduler_Node *nodes; } Thread_Scheduler_control; Why d

Re: Need help in understanding some of the existing code in RTEMS

Hi, I had a small question. The scheduler struct inside percpu.h looks like: -- struct { /** * @brief The scheduler control of the scheduler owning this processor. * *

Re: Need help in understanding some of the existing code in RTEMS

I understand. Thank you. On Tue, Jul 14, 2020 at 7:05 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 14/07/2020 13:37, Richi Dubey wrote: > > > Here we remove the affine ready queue if it > > exists from the chain of affine queues since now an affine thread is > >

Re: Need help in understanding some of the existing code in RTEMS

On 14/07/2020 13:37, Richi Dubey wrote: Here we remove the affine ready queue if it exists from the chain of affine queues since now an affine thread is scheduled on a processor. Why are we removing the entire affine queue corresponding to a CPU when a single node of the queue gets

Re: Need help in understanding some of the existing code in RTEMS

> > Here we remove the affine ready queue if it > exists from the chain of affine queues since now an affine thread is > scheduled on a processor. Why are we removing the entire affine queue corresponding to a CPU when a single node of the queue gets scheduled? On Tue, Jul 14, 2020 at 2:51 PM Seb

Re: Need help in understanding some of the existing code in RTEMS

On 14/07/2020 11:11, Sebastian Huber wrote: On 14/07/2020 10:47, Richi Dubey wrote: Can someone please help me understand how this (https://git.rtems.org/rtems/tree/cpukit/score/src/scheduleredfsmp.c#n385) if condition works. Why are we removing the ready queue Node from the chain of Affine

Re: Need help in understanding some of the existing code in RTEMS

On 14/07/2020 10:47, Richi Dubey wrote: Can someone please help me understand how this (https://git.rtems.org/rtems/tree/cpukit/score/src/scheduleredfsmp.c#n385) if condition works. Why are we removing the ready queue Node from the chain of Affine queues when we are allocating a different proc

Re: Need help in understanding some of the existing code in RTEMS

Hi, Can someone please help me understand how this ( https://git.rtems.org/rtems/tree/cpukit/score/src/scheduleredfsmp.c#n385) if condition works. Why are we removing the ready queue Node from the chain of Affine queues when we are allocating a different processor ( https://git.rtems.org/rtems/tre

Re: Need help in understanding some of the existing code in RTEMS

Hi, We use a zero-length array in the definition of Scheduler_EDF_SMP_Context, but I can not see any code in scheduleredfsmp.c ( https://git.rtems.org/rtems/tree/cpukit/score/src/scheduleredfsmp.c) which actually

Re: Need help in understanding some of the existing code in RTEMS

I understand now. Thank you. On Sat, Jul 11, 2020 at 7:35 PM Gedare Bloom wrote: > On Sat, Jul 11, 2020 at 12:31 AM Richi Dubey wrote: > > > > Hi, > > > > I noticed that we have defined all the scheduler non entry-point > functions in > https://git.rtems.org/rtems/tree/cpukit/score/src/schedule

Re: Need help in understanding some of the existing code in RTEMS

On Sat, Jul 11, 2020 at 12:31 AM Richi Dubey wrote: > > Hi, > > I noticed that we have defined all the scheduler non entry-point functions in > https://git.rtems.org/rtems/tree/cpukit/score/src/scheduleredfsmp.c as static > inline, which makes them invisible inside the doxygen comments > (https