On Thu, 15 May 2008 18:23:30 +0200, Philippe Gerum <[EMAIL PROTECTED]> wrote: > Gilles Chanteperdrix wrote: >> On Thu, May 15, 2008 at 5:56 PM, Philippe Gerum <[EMAIL PROTECTED]> wrote: >>> Gilles Chanteperdrix wrote: >>>> On Thu, May 15, 2008 at 4:14 PM, Philippe Gerum <[EMAIL PROTECTED]> > wrote: >>>>> Matthieu wrote: >>>>>> On Thu, 15 May 2008 15:12:32 +0200, "Gilles Chanteperdrix" >>>>>> <[EMAIL PROTECTED]> wrote: >>>>>>> On Thu, May 15, 2008 at 11:28 AM, Gilles Chanteperdrix >>>>>>> <[EMAIL PROTECTED]> wrote: >>>>>>>> On Thu, May 15, 2008 at 8:10 AM, Matthieu >>>>>>>> <[EMAIL PROTECTED]> wrote: >>>>>>>> I think >>>>>>>>> that VxWorks Task Control Block ,implemeted by WIND RIVER, is > keeping >>>>>>> the >>>>>>>>> context in hard real-time. That's why I would like to know if > there are >>>>>>>>> other possibilities ? >>>>>>>> Yes, there are possibilities: fix your code not to use such > internal >>>>>>>> data as the WIND_TCB members. >>>>>>> Even VxWorks documentation considers accessing WIND_TCB directly as > a >>>>>>> bad practice. See the doc of taskInfoGet at: >>>>>>> >>>>>>> >>>>>> > http://spacegrant.colorado.edu/~dixonc/vxworks/docs/vxworks/ref/taskShow.html >>>>>>> So, what I would agree we can do is implement taskInfoGet. >>>>>>> >>>>>>> -- >>>>>>> Gilles >>>>>> Well, what a great issue for me... >>>>>> >>>>> The attached patch provides taskInfoGet(). Whether it does provide > everything >>>>> you need from the task information block is another issue, but at > least, you >>>>> would have the proper infrastructure to add the missing bits to. >>>> You have been fast. >>> I cheated: this code has been floating around on my disk for some time > now. >>> >>> One minor concern. The definition of TASK_DESC in >>>> vxworks headers seems to be: >>>> >>>> typedef struct /* TASK_DESC - information > structure */ >>>> { >>>> int td_id; /* task id */ >>>> char * td_name; /* name of task */ >>>> int td_priority; /* task priority */ >>>> int td_status; /* task status */ >>>> int td_options; /* task option bits (see > below) */ >>>> FUNCPTR td_entry; /* original entry point of task > */ >>>> char * td_sp; /* saved stack pointer */ >>>> char * td_pStackBase; /* the bottom of the stack */ >>>> char * td_pStackLimit; /* the effective end of the > stack */ >>>> char * td_pStackEnd; /* the actual end of the stack > */ >>>> int td_stackSize; /* size of stack in > bytes */ >>>> int td_stackCurrent;/* current stack usage > in bytes */ >>>> int td_stackHigh; /* maximum stack usage > in bytes */ >>>> int td_stackMargin; /* current stack margin > in bytes */ >>>> int td_errorStatus; /* most recent task > error status */ >>>> int td_delay; /* delay/timeout ticks > */ >>>> } TASK_DESC; >>>> >>>> >>> My concern is that this layout and naming might be arch-dependent > and/or even >>> WIND version dependent. >>> >>> Could any ppc and arm people with access to Tornado headers > confirm/refute this >>> assumption? TIA, >> >> Found it here: >> > http://rts-lab.eas.asu.edu/NSF_EI/courses/cse591_RTES/document/reference_document/vxworks_taskLib.h >> > > The arch-dependent part of this "generic kernel interface header" (eh...) > does > not look like including the TASK_DESC stuff and moreover, this seems to be > based > on VxWorks 5.4 which is our reference version too, so I agree, we should > probably comply with their naming as well. > > -- > Philippe.
It's a great pleasure to work with people having such a reactivity and efficiency. Do I patch my kernel now or would you operate for some modifications before ? Matthieu _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
