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,
--
Philippe.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
