[Xenomai-help] VxWorks skin problem concerning WIND_TCB structure

[Xenomai-help] VxWorks skin problem concerning WIND_TCB structure

[Matthieu]

I’m currently porting a VxWorks Application in SuSE Linux patched with
Xenomai. I encounter some problems with the taskLib.h emulation. Indeed,
I’ve got an error concerning WIND_TCB structure. I think that not the
whole structure is implemented or maybe it’s implemented by Xenomai
Native API and not VxWorks skin.

Here are extracts of Code.c:
 #include <vxworks/vxworks.h>
 WIND_TCB * pTcb;
 pTcb->entry
 pTcb->lockCnt
 pTcb->pSignalInfo->sigt_blocked
 pTcb->pStackBase 
 … 

Here are the errors:
 Code.c:270: warning: implicit declaration of function ‘taskTcb’ 
 Code.c:270: warning: assignment makes pointer from integer without a cast 
 Code.c:286: error: ‘WIND_TCB’ has no member named ‘entry’ 
 Code.c:292: error: ‘WIND_TCB’ has no member named ‘entry’ 
 Code.c:315: error: ‘WIND_TCB’ has no member named ‘lockCnt’ 
 Code.c:324: error: ‘WIND_TCB’ has no member named ‘pSignalInfo’ 
 Code.c:339: error: ‘WIND_TCB’ has no member named ‘pStackBase’ 
 Code.c:474: warning: assignment makes pointer from integer without a cast 
 Code.c:492: error: ‘WIND_TCB’ has no member named ‘safeCnt’ 
 Code.c:493: warning: implicit declaration of function ‘TASK_UNSAFE’ 
 Code.c:511: warning: implicit declaration of function ‘intLock’ 
 Code.c:512: error: ‘WIND_TCB’ has no member named ‘safeCnt’ 
 Code.c:513: error: ‘WIND_TCB’ has no member named ‘status’ 
 Code.c:513: error: ‘WIND_READY’ undeclared (first use in this
function) 
 Code.c:513: error: (Each undeclared identifier is reported only once 
 Code.c:513: error: for each function it appears in.) 
 Code.c:513: error: ‘WIND_TCB’ has no member named ‘lockCnt’
 Code.c:517: warning: implicit declaration of function ‘intUnlock’
 Code.c:519: error: ‘taskIdCurrent’ undeclared (first use in this
function)
 Code.c:522: error: ‘WIND_TCB’ has no member named ‘safeCnt’
 Code.c:523: error: ‘WIND_TCB’ has no member named ‘lockCnt’
 Code.c:525: warning: implicit declaration of function ‘Q_FIRST’
 Code.c:525: error: ‘WIND_TCB’ has no member named ‘safetyQHead’
 Code.c:525: warning: comparison between pointer and integer
 Code.c:526: warning: implicit declaration of function ‘windPendQFlush’
 Code.c:526: error: ‘WIND_TCB’ has no member named ‘safetyQHead’
 Code.c:532: warning: implicit declaration of function ‘windPendQPut’
 Code.c:532: error: ‘WIND_TCB’ has no member named ‘safetyQHead’
 Code.c:553: warning: implicit declaration of function ‘TASK_ID_VERIFY’
 Code.c:566: warning: implicit declaration of function ‘TASK_SAFE’
 Code.c:578: error: ‘WIND_TCB’ has no member named ‘pTaskVar’
 Code.c:579: error: ‘WIND_TCB’ has no member named ‘pTaskVar’
 Code.c:583: error: ‘WIND_TCB’ has no member named ‘pSignalInfo’
 Code.c:620: error: ‘WIND_TCB’ has no member named ‘pStackBase’
 Code.c:638: error: ‘WIND_TCB’ has no member named ‘options’
 Code.c:644: warning: implicit declaration of function ‘taskRestart’
 Code.c:654: error: ‘WIND_TCB’ has no member named ‘pTaskVar’
 Code.c:658: error: invalid application of ‘sizeof’ to incomplete type
‘struct sigtcb’
 Code.c:659: error: ‘_NSIGS’ undeclared (first use in this function)
 Code.c:660: error: dereferencing pointer to incomplete type
 Code.c:660: error: dereferencing pointer to incomplete type
 Code.c:660: error: dereferencing pointer to incomplete type
 Code.c:667: error: ‘WIND_TCB’ has no member named ‘pSignalInfo’
 Code.c:876: warning: suggest explicit braces to avoid ambiguous ‘else’
 Code.c: In function ‘sigTcbPut’:
 Code.c:994: warning: implicit declaration of function ‘INT_RESTRICT’
 Code.c:997: error: ‘WIND_TCB’ has no member named ‘pSignalInfo’
 Code.c:998: error: ‘WIND_TCB’ has no member named ‘pSignalInfo’
 Code.c:1000: warning: implicit declaration of function
‘taskStackAllot’
 Code.c:1001: error: invalid application of ‘sizeof’ to incomplete type
‘struct sigtcb’
 Code.c:1008: error: ‘WIND_TCB’ has no member named ‘pSignalInfo’
 Code.c:1009: error: invalid application of ‘sizeof’ to incomplete type
‘struct sigtcb’
 Code.c:1011: error: ‘_NSIGS’ undeclared (first use in this function)
 Code.c:1012: error: dereferencing pointer to incomplete type
 Code.c:1012: error: dereferencing pointer to incomplete type 
 Code.c:1013: error: dereferencing pointer to incomplete type What are my
issues?

Thanks in advance 

Re: [Xenomai-help] VxWorks skin problem concerning WIND_TCB structure

[Philippe Gerum]

Matthieu wrote:
> I’m currently porting a VxWorks Application in SuSE Linux patched with
> Xenomai. I encounter some problems with the taskLib.h emulation. Indeed,
> I’ve got an error concerning WIND_TCB structure. I think that not the
> whole structure is implemented or maybe it’s implemented by Xenomai
> Native API and not VxWorks skin.
>

Implementing the whole WIND_TCB structure is out of scope. Most of the fields
you attempt to access in your app are dependent on the VxWorks innards, which is
meaningless in an emulation environment. You can emulate the others (or their
meaning) fairly easily (e.g. pStackBase and status).

> Here are extracts of Code.c:
>  #include <vxworks/vxworks.h>
>  WIND_TCB * pTcb;
>  pTcb->entry
>  pTcb->lockCnt
>  pTcb->pSignalInfo->sigt_blocked
>  pTcb->pStackBase 
>  … 
> 
> Here are the errors:
>  Code.c:270: warning: implicit declaration of function ‘taskTcb’ 
>  Code.c:270: warning: assignment makes pointer from integer without a cast 
>  Code.c:286: error: ‘WIND_TCB’ has no member named ‘entry’ 
>  Code.c:292: error: ‘WIND_TCB’ has no member named ‘entry’ 
>  Code.c:315: error: ‘WIND_TCB’ has no member named ‘lockCnt’ 
>  Code.c:324: error: ‘WIND_TCB’ has no member named ‘pSignalInfo’ 
>  Code.c:339: error: ‘WIND_TCB’ has no member named ‘pStackBase’ 
>  Code.c:474: warning: assignment makes pointer from integer without a cast 
>  Code.c:492: error: ‘WIND_TCB’ has no member named ‘safeCnt’ 
>  Code.c:493: warning: implicit declaration of function ‘TASK_UNSAFE’ 
>  Code.c:511: warning: implicit declaration of function ‘intLock’ 
>  Code.c:512: error: ‘WIND_TCB’ has no member named ‘safeCnt’ 
>  Code.c:513: error: ‘WIND_TCB’ has no member named ‘status’ 
>  Code.c:513: error: ‘WIND_READY’ undeclared (first use in this
> function) 
>  Code.c:513: error: (Each undeclared identifier is reported only once 
>  Code.c:513: error: for each function it appears in.) 
>  Code.c:513: error: ‘WIND_TCB’ has no member named ‘lockCnt’
>  Code.c:517: warning: implicit declaration of function ‘intUnlock’
>  Code.c:519: error: ‘taskIdCurrent’ undeclared (first use in this
> function)
>  Code.c:522: error: ‘WIND_TCB’ has no member named ‘safeCnt’
>  Code.c:523: error: ‘WIND_TCB’ has no member named ‘lockCnt’
>  Code.c:525: warning: implicit declaration of function ‘Q_FIRST’
>  Code.c:525: error: ‘WIND_TCB’ has no member named ‘safetyQHead’
>  Code.c:525: warning: comparison between pointer and integer
>  Code.c:526: warning: implicit declaration of function ‘windPendQFlush’
>  Code.c:526: error: ‘WIND_TCB’ has no member named ‘safetyQHead’
>  Code.c:532: warning: implicit declaration of function ‘windPendQPut’
>  Code.c:532: error: ‘WIND_TCB’ has no member named ‘safetyQHead’
>  Code.c:553: warning: implicit declaration of function ‘TASK_ID_VERIFY’
>  Code.c:566: warning: implicit declaration of function ‘TASK_SAFE’
>  Code.c:578: error: ‘WIND_TCB’ has no member named ‘pTaskVar’
>  Code.c:579: error: ‘WIND_TCB’ has no member named ‘pTaskVar’
>  Code.c:583: error: ‘WIND_TCB’ has no member named ‘pSignalInfo’
>  Code.c:620: error: ‘WIND_TCB’ has no member named ‘pStackBase’
>  Code.c:638: error: ‘WIND_TCB’ has no member named ‘options’
>  Code.c:644: warning: implicit declaration of function ‘taskRestart’
>  Code.c:654: error: ‘WIND_TCB’ has no member named ‘pTaskVar’
>  Code.c:658: error: invalid application of ‘sizeof’ to incomplete type
> ‘struct sigtcb’
>  Code.c:659: error: ‘_NSIGS’ undeclared (first use in this function)
>  Code.c:660: error: dereferencing pointer to incomplete type
>  Code.c:660: error: dereferencing pointer to incomplete type
>  Code.c:660: error: dereferencing pointer to incomplete type
>  Code.c:667: error: ‘WIND_TCB’ has no member named ‘pSignalInfo’
>  Code.c:876: warning: suggest explicit braces to avoid ambiguous ‘else’
>  Code.c: In function ‘sigTcbPut’:
>  Code.c:994: warning: implicit declaration of function ‘INT_RESTRICT’
>  Code.c:997: error: ‘WIND_TCB’ has no member named ‘pSignalInfo’
>  Code.c:998: error: ‘WIND_TCB’ has no member named ‘pSignalInfo’
>  Code.c:1000: warning: implicit declaration of function
> ‘taskStackAllot’
>  Code.c:1001: error: invalid application of ‘sizeof’ to incomplete type
> ‘struct sigtcb’
>  Code.c:1008: error: ‘WIND_TCB’ has no member named ‘pSignalInfo’
>  Code.c:1009: error: invalid application of ‘sizeof’ to incomplete type
> ‘struct sigtcb’
>  Code.c:1011: error: ‘_NSIGS’ undeclared (first use in this function)
>  Code.c:1012: error: dereferencing pointer to incomplete type
>  Code.c:1012: error: dereferencing pointer to incomplete type 
>  Code.c:1013: error: dereferencing pointer to incomplete type What are my
> issues?
> 
> Thanks in advance 
> 
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help


-- 
Philippe.

Re: [Xenomai-help] VxWorks skin problem concerning WIND_TCB structure

[Gilles Chanteperdrix]

Philippe Gerum wrote:
 > Matthieu wrote:
 > > Im currently porting a VxWorks Application in SuSE Linux patched with
 > > Xenomai. I encounter some problems with the taskLib.h emulation. Indeed,
 > > Ive got an error concerning WIND_TCB structure. I think that not the
 > > whole structure is implemented or maybe its implemented by Xenomai
 > > Native API and not VxWorks skin.
 > >
 > 
 > Implementing the whole WIND_TCB structure is out of scope. Most of the fields
 > you attempt to access in your app are dependent on the VxWorks innards, which is
 > meaningless in an emulation environment. You can emulate the others (or their
 > meaning) fairly easily (e.g. pStackBase and status).
 > 
 > > Here are extracts of Code.c:
 > >  #include <vxworks/vxworks.h>
 > >  WIND_TCB * pTcb;
 > >  pTcb->entry
 > >  pTcb->lockCnt
 > >  pTcb->pSignalInfo->sigt_blocked

... And you may access signal mask with the posix pthread_sigmask
service (if the first sigset_t pointer is NULL, the "how" argument is
ignored, and the only effect of the service is to copy the current
signal mask).

-- 


					    Gilles.

[Xenomai-help] Re: VxWorks skin problem concerning WIND_TCBstructure

[Matthieu]

On Sun, 11 May 2008 00:40:07 +0200, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> Philippe Gerum wrote:
>  > Matthieu wrote:
>  > > Im currently porting a VxWorks Application in SuSE Linux patched
with
>  > > Xenomai. I encounter some problems with the taskLib.h emulation.
> Indeed,
>  > > Ive got an error concerning WIND_TCB structure. I think that not the
>  > > whole structure is implemented or maybe its implemented by Xenomai
>  > > Native API and not VxWorks skin.
>  > >
>  >
>  > Implementing the whole WIND_TCB structure is out of scope. Most of the
> fields
>  > you attempt to access in your app are dependent on the VxWorks
innards,
> which is
>  > meaningless in an emulation environment. You can emulate the others
(or
> their
>  > meaning) fairly easily (e.g. pStackBase and status).
>  >
>  > > Here are extracts of Code.c:
>  > >  #include <vxworks/vxworks.h>
>  > >  WIND_TCB * pTcb;
>  > >  pTcb->entry
>  > >  pTcb->lockCnt
>  > >  pTcb->pSignalInfo->sigt_blocked
> 
> ... And you may access signal mask with the posix pthread_sigmask
> service (if the first sigset_t pointer is NULL, the "how" argument is
> ignored, and the only effect of the service is to copy the current
> signal mask).
> 
> --
> 
> 
> 					    Gilles.

Thank you for your answers.
First, in my investigation, I found out that in vxworks/vxworks.h there are
different definitions of WIND_TCB while the compilation occur in kernel
mode and xeno_sim or not. What does it mean ?
I think I've understood what you say. The problem is how can I emulate the
fields I need since I don't know if they can be treated as standard threads
with pthread.h and signal.h ? Do I need to use Xenomai specific
implementation of such information to get the field value ?
The field are
 entry         (entry point of task)
 lockCnt       (preemtion lock count)
 pSignalInfo   (ptr to signal info for task)
 pStackBase    (points to bottom of stack)
 SafeCnt       (safe_from_delete count)
 status        (status of task)
 safetyQHead   (safe_from_delete q head)
 ptaskVar      (ptr to task variable list)
 options       (task option bits)
 
Matthieu

[Xenomai-help] Re: Re: VxWorks skin problem concerning WIND_TCBstructure

[Matthieu]

On Tue, 13 May 2008 11:16:56 +0200, Matthieu
<matthieu.connaulte_xenomai@domain.hid> wrote:
> On Sun, 11 May 2008 00:40:07 +0200, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> Philippe Gerum wrote:
>>  > Matthieu wrote:
>>  > > Im currently porting a VxWorks Application in SuSE Linux patched
> with
>>  > > Xenomai. I encounter some problems with the taskLib.h emulation.
>> Indeed,
>>  > > Ive got an error concerning WIND_TCB structure. I think that not
> the
>>  > > whole structure is implemented or maybe its implemented by Xenomai
>>  > > Native API and not VxWorks skin.
>>  > >
>>  >
>>  > Implementing the whole WIND_TCB structure is out of scope. Most of
> the
>> fields
>>  > you attempt to access in your app are dependent on the VxWorks
> innards,
>> which is
>>  > meaningless in an emulation environment. You can emulate the others
> (or
>> their
>>  > meaning) fairly easily (e.g. pStackBase and status).
>>  >
>>  > > Here are extracts of Code.c:
>>  > >  #include <vxworks/vxworks.h>
>>  > >  WIND_TCB * pTcb;
>>  > >  pTcb->entry
>>  > >  pTcb->lockCnt
>>  > >  pTcb->pSignalInfo->sigt_blocked
>>
>> ... And you may access signal mask with the posix pthread_sigmask
>> service (if the first sigset_t pointer is NULL, the "how" argument is
>> ignored, and the only effect of the service is to copy the current
>> signal mask).
>>
>> --
>>
>>
>> 					    Gilles.
> 
> Thank you for your answers.
> First, in my investigation, I found out that in vxworks/vxworks.h there
> are
> different definitions of WIND_TCB while the compilation occur in kernel
> mode and xeno_sim or not. What does it mean ?
> I think I've understood what you say. The problem is how can I emulate
the
> fields I need since I don't know if they can be treated as standard
> threads
> with pthread.h and signal.h ? Do I need to use Xenomai specific
> implementation of such information to get the field value ?
> The field are
>  entry         (entry point of task)
>  lockCnt       (preemtion lock count)
>  pSignalInfo   (ptr to signal info for task)
>  pStackBase    (points to bottom of stack)
>  SafeCnt       (safe_from_delete count)
>  status        (status of task)
>  safetyQHead   (safe_from_delete q head)
>  ptaskVar      (ptr to task variable list)
>  options       (task option bits)
> 
> Matthieu
> 
> 

I still don't have any solution to emulate the fields above listed as I
don't know if I can use Linux posix services ?

Matthieu

> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

Re: [Xenomai-help] VxWorks skin problem concerning WIND_TCBstructure

[Gilles Chanteperdrix]

Matthie wrote:
> I still don't have any solution to emulate the fields above listed as I
> don't know if I can use Linux posix services ?

Yes, you can use Linux posix services, but they will cause any Xenomai
thread to switch from primary mode to secondary mode.

If you do not understand what I am talking about, you should probably
read the articles at:
http://www.xenomai.org/index.php/Publications

-- 


					    Gilles.

[Xenomai-help] Re: Re: Re: VxWorks skin problem concerning WIND_TCBstructure

[Matthieu]

On Wed, 14 May 2008 11:23:13 +0200, Matthieu
<matthieu.connaulte_xenomai@domain.hid> wrote:
> 
> 
> On Tue, 13 May 2008 11:16:56 +0200, Matthieu
> <matthieu.connaulte_xenomai@domain.hid> wrote:
>> On Sun, 11 May 2008 00:40:07 +0200, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>> Philippe Gerum wrote:
>>>  > Matthieu wrote:
>>>  > > Im currently porting a VxWorks Application in SuSE Linux patched
>> with
>>>  > > Xenomai. I encounter some problems with the taskLib.h emulation.
>>> Indeed,
>>>  > > Ive got an error concerning WIND_TCB structure. I think that not
>> the
>>>  > > whole structure is implemented or maybe its implemented by Xenomai
>>>  > > Native API and not VxWorks skin.
>>>  > >
>>>  >
>>>  > Implementing the whole WIND_TCB structure is out of scope. Most of
>> the
>>> fields
>>>  > you attempt to access in your app are dependent on the VxWorks
>> innards,
>>> which is
>>>  > meaningless in an emulation environment. You can emulate the others
>> (or
>>> their
>>>  > meaning) fairly easily (e.g. pStackBase and status).
>>>  >
>>>  > > Here are extracts of Code.c:
>>>  > >  #include <vxworks/vxworks.h>
>>>  > >  WIND_TCB * pTcb;
>>>  > >  pTcb->entry
>>>  > >  pTcb->lockCnt
>>>  > >  pTcb->pSignalInfo->sigt_blocked
>>>
>>> ... And you may access signal mask with the posix pthread_sigmask
>>> service (if the first sigset_t pointer is NULL, the "how" argument is
>>> ignored, and the only effect of the service is to copy the current
>>> signal mask).
>>>
>>> --
>>>
>>>
>>> 					    Gilles.
>>
>> Thank you for your answers.
>> First, in my investigation, I found out that in vxworks/vxworks.h there
>> are
>> different definitions of WIND_TCB while the compilation occur in kernel
>> mode and xeno_sim or not. What does it mean ?
>> I think I've understood what you say. The problem is how can I emulate
> the
>> fields I need since I don't know if they can be treated as standard
>> threads
>> with pthread.h and signal.h ? Do I need to use Xenomai specific
>> implementation of such information to get the field value ?
>> The field are
>>  entry         (entry point of task)
>>  lockCnt       (preemtion lock count)
>>  pSignalInfo   (ptr to signal info for task)
>>  pStackBase    (points to bottom of stack)
>>  SafeCnt       (safe_from_delete count)
>>  status        (status of task)
>>  safetyQHead   (safe_from_delete q head)
>>  ptaskVar      (ptr to task variable list)
>>  options       (task option bits)
>>
>> Matthieu
>>
>>
> 
> I still don't have any solution to emulate the fields above listed as I
> don't know if I can use Linux posix services ?
> 
> Matthieu

Does a Xenomai Task Control Block exist ?

Matthieu

> 
>>
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

[Xenomai-help] Re: Re: Re: VxWorks skin problem concerning WIND_TCBstructure

[Matthieu]

On Wed, 14 May 2008 20:31:08 +0200, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> Matthie wrote:
>> I still don't have any solution to emulate the fields above listed as I
>> don't know if I can use Linux posix services ?
> 
> Yes, you can use Linux posix services, but they will cause any Xenomai
> thread to switch from primary mode to secondary mode.
> 
> If you do not understand what I am talking about, you should probably
> read the articles at:
> http://www.xenomai.org/index.php/Publications
> 
> --
> 
> 
> 					    Gilles.

That's the point. Using posix services is pretty much easy, but if this
switches the thread to secondary mode, I'm not sure about using it. 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 ?

matthieu

Re: [Xenomai-help] VxWorks skin problem concerning WIND_TCBstructure

[Gilles Chanteperdrix]

On Thu, May 15, 2008 at 8:10 AM, Matthieu
<matthieu.connaulte_xenomai@domain.hid> wrote:
> On Wed, 14 May 2008 20:31:08 +0200, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> Matthie wrote:
>>> I still don't have any solution to emulate the fields above listed as I
>>> don't know if I can use Linux posix services ?
>>
>> Yes, you can use Linux posix services, but they will cause any Xenomai
>> thread to switch from primary mode to secondary mode.
>>
>> If you do not understand what I am talking about, you should probably
>> read the articles at:
>> http://www.xenomai.org/index.php/Publications
>>
>> --
>>
>>
>>                                           Gilles.
>
> That's the point. Using posix services is pretty much easy, but if this
> switches the thread to secondary mode, I'm not sure about using it.

I can not imagine code using WIND_TCB members for something else than debug.

 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.

-- 
 Gilles

Re: [Xenomai-help] VxWorks skin problem concerning WIND_TCBstructure

[Gilles Chanteperdrix]

On Thu, May 15, 2008 at 11:28 AM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On Thu, May 15, 2008 at 8:10 AM, Matthieu
> <matthieu.connaulte_xenomai@domain.hid> 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

[Xenomai-help] Re: Re: Re: Re: VxWorks skin problem concerning WIND_TCBstructure

[Matthieu]

On Thu, 15 May 2008 15:12:32 +0200, "Gilles Chanteperdrix"
<gilles.chanteperdrix@xenomai.org> wrote:
> On Thu, May 15, 2008 at 11:28 AM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> On Thu, May 15, 2008 at 8:10 AM, Matthieu
>> <matthieu.connaulte_xenomai@domain.hid> 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...

But can I use other API implements of such kind of Tasks information, as
it's possible to mix APIs ? I think about Task Status or Thread State Flags
?

Matthieu

Re: [Xenomai-help] VxWorks skin problem concerning WIND_TCBstructure

[Gilles Chanteperdrix]

On Thu, May 15, 2008 at 3:50 PM, Matthieu
<matthieu.connaulte_xenomai@domain.hid> wrote:
>
>
> On Thu, 15 May 2008 15:12:32 +0200, "Gilles Chanteperdrix"
> <gilles.chanteperdrix@xenomai.org> wrote:
>> On Thu, May 15, 2008 at 11:28 AM, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>> On Thu, May 15, 2008 at 8:10 AM, Matthieu
>>> <matthieu.connaulte_xenomai@domain.hid> 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...
>
> But can I use other API implements of such kind of Tasks information, as
> it's possible to mix APIs ? I think about Task Status or Thread State Flags
> ?

The native task has rt_task_inquire. But rt_task_inquire, though it
returns skin independent data, requires a native task pointer.

So what you are missing is really taskInfoGet.

-- 
 Gilles

Re: [Xenomai-help] VxWorks skin problem concerning WIND_TCBstructure

[Gilles Chanteperdrix]

On Thu, May 15, 2008 at 4:04 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On Thu, May 15, 2008 at 3:50 PM, Matthieu
> <matthieu.connaulte_xenomai@domain.hid> wrote:
>>
>>
>> On Thu, 15 May 2008 15:12:32 +0200, "Gilles Chanteperdrix"
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>> On Thu, May 15, 2008 at 11:28 AM, Gilles Chanteperdrix
>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>> On Thu, May 15, 2008 at 8:10 AM, Matthieu
>>>> <matthieu.connaulte_xenomai@domain.hid> 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...
>>
>> But can I use other API implements of such kind of Tasks information, as
>> it's possible to mix APIs ? I think about Task Status or Thread State Flags
>> ?
>
> The native task has rt_task_inquire. But rt_task_inquire, though it
> returns skin independent data, requires a native task pointer.
>
> So what you are missing is really taskInfoGet.

Note that if your need is debugging purposes, you can read the task
state at run time in /proc/xenomai/sched.

-- 
 Gilles

Re: [Xenomai-help] VxWorks skin problem concerning WIND_TCBstructure

[Philippe Gerum]

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

Matthieu wrote:
> 
> On Thu, 15 May 2008 15:12:32 +0200, "Gilles Chanteperdrix"
> <gilles.chanteperdrix@xenomai.org> wrote:
>> On Thu, May 15, 2008 at 11:28 AM, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>> On Thu, May 15, 2008 at 8:10 AM, Matthieu
>>> <matthieu.connaulte_xenomai@domain.hid> 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.

-- 
Philippe.

[-- Attachment #2: vxworks-taskinfoget.patch --]
[-- Type: text/x-diff, Size: 12599 bytes --]

Index: include/asm-ia64/system.h
===================================================================
--- include/asm-ia64/system.h	(revision 3786)
+++ include/asm-ia64/system.h	(working copy)
@@ -32,6 +32,8 @@
 #define XNARCH_THREAD_STACKSZ  KERNEL_STACK_SIZE
 
 #define xnarch_stack_size(tcb)  ((tcb)->stacksize)
+#define xnarch_stack_base(tcb)	((tcb)->stackbase)
+#define xnarch_stack_end(tcb)	((caddr_t)(tcb)->stackbase - (tcb)->stacksize)
 #define xnarch_user_task(tcb)   ((tcb)->user_task)
 #define xnarch_user_pid(tcb)    ((tcb)->user_task->pid)
 
Index: include/vxworks/syscall.h
===================================================================
--- include/vxworks/syscall.h	(revision 3786)
+++ include/vxworks/syscall.h	(working copy)
@@ -69,12 +69,14 @@
 #define __vxworks_wd_cancel        43
 #define __vxworks_wd_wait          44
 #define __vxworks_int_context      45
+#define __vxworks_taskinfo_get     46
 
 struct wind_arg_bulk {
 
     u_long a1;
     u_long a2;
     u_long a3;
+    u_long a4;
 };
 
 #ifdef __KERNEL__
Index: include/vxworks/vxworks.h
===================================================================
--- include/vxworks/vxworks.h	(revision 3786)
+++ include/vxworks/vxworks.h	(working copy)
@@ -127,6 +127,32 @@
     TASK_ID handle;
 } WIND_TCB_PLACEHOLDER;
 
+#define WIND_READY	0x0
+#define WIND_SUSPEND	0x1
+#define WIND_PEND	0x2
+#define WIND_DELAY	0x4
+#define WIND_DEAD	0x8
+#define WIND_STOP	0x10	/* Never reported. */
+
+typedef struct _TASK_DESC {
+
+	TASK_ID tid;
+	char    name[XNOBJECT_NAME_LEN];
+	int	priority;
+	int	status;
+	int	flags;
+	FUNCPTR	entry;
+	int	stacksize;
+	char	*pStackBase;
+	char	*pStackEnd;
+	char	*pExcStackBase;
+	char	*pExcStackEnd;
+	int	errorStatus;
+
+	unsigned long opaque;
+	
+} TASK_DESC;
+
 typedef void (*wind_timer_t)(long);
     
 typedef struct wind_wd_utarget {
@@ -156,6 +182,9 @@
     int status;
     int prio;
     FUNCPTR entry;
+#ifdef CONFIG_XENO_OPT_PERVASIVE
+    unsigned long ptid;
+#endif
 
     /* Xenomai specific: used by taskLib */
 
@@ -345,6 +374,9 @@
 
 BOOL taskIsSuspended (TASK_ID task_id);
          
+STATUS taskInfoGet(TASK_ID task_id,
+		   TASK_DESC *desc);
+
 STATUS semGive(SEM_ID sem_id);
 
 STATUS semTake(SEM_ID sem_id,
Index: include/asm-blackfin/system.h
===================================================================
--- include/asm-blackfin/system.h	(revision 3786)
+++ include/asm-blackfin/system.h	(working copy)
@@ -30,6 +30,8 @@
 #define XNARCH_THREAD_STACKSZ   8192
 
 #define xnarch_stack_size(tcb)  ((tcb)->stacksize)
+#define xnarch_stack_base(tcb)	((tcb)->stackbase)
+#define xnarch_stack_end(tcb)	((caddr_t)(tcb)->stackbase - (tcb)->stacksize)
 #define xnarch_user_task(tcb)   ((tcb)->user_task)
 #define xnarch_user_pid(tcb)    ((tcb)->user_task->pid)
 
Index: include/asm-powerpc/system.h
===================================================================
--- include/asm-powerpc/system.h	(revision 3786)
+++ include/asm-powerpc/system.h	(working copy)
@@ -35,6 +35,8 @@
 #endif
 
 #define xnarch_stack_size(tcb)  ((tcb)->stacksize)
+#define xnarch_stack_base(tcb)	((tcb)->stackbase)
+#define xnarch_stack_end(tcb)	((caddr_t)(tcb)->stackbase - (tcb)->stacksize)
 #define xnarch_user_task(tcb)   ((tcb)->user_task)
 #define xnarch_user_pid(tcb)    ((tcb)->user_task->pid)
 
Index: include/asm-arm/system.h
===================================================================
--- include/asm-arm/system.h	(revision 3786)
+++ include/asm-arm/system.h	(working copy)
@@ -32,6 +32,8 @@
 #define XNARCH_THREAD_STACKSZ   4096
 
 #define xnarch_stack_size(tcb)  ((tcb)->stacksize)
+#define xnarch_stack_base(tcb)	((tcb)->stackbase)
+#define xnarch_stack_end(tcb)	((caddr_t)(tcb)->stackbase - (tcb)->stacksize)
 #define xnarch_user_task(tcb)   ((tcb)->user_task)
 #define xnarch_user_pid(tcb)    ((tcb)->user_task->pid)
 
Index: include/asm-x86/system_64.h
===================================================================
--- include/asm-x86/system_64.h	(revision 3786)
+++ include/asm-x86/system_64.h	(working copy)
@@ -31,6 +31,8 @@
 #define XNARCH_THREAD_STACKSZ	4096
 
 #define xnarch_stack_size(tcb)  ((tcb)->stacksize)
+#define xnarch_stack_base(tcb)	((tcb)->stackbase)
+#define xnarch_stack_end(tcb)	((caddr_t)(tcb)->stackbase - (tcb)->stacksize)
 #define xnarch_fpu_ptr(tcb)     ((tcb)->fpup)
 #define xnarch_user_task(tcb)   ((tcb)->user_task)
 #define xnarch_user_pid(tcb)    ((tcb)->user_task->pid)
Index: include/asm-x86/system_32.h
===================================================================
--- include/asm-x86/system_32.h	(revision 3786)
+++ include/asm-x86/system_32.h	(working copy)
@@ -31,6 +31,8 @@
 #define XNARCH_THREAD_STACKSZ 4096
 
 #define xnarch_stack_size(tcb)  ((tcb)->stacksize)
+#define xnarch_stack_base(tcb)	((tcb)->stackbase)
+#define xnarch_stack_end(tcb)	((caddr_t)(tcb)->stackbase - (tcb)->stacksize)
 #define xnarch_fpu_ptr(tcb)     ((tcb)->fpup)
 #define xnarch_user_task(tcb)   ((tcb)->user_task)
 #define xnarch_user_pid(tcb)    ((tcb)->user_task->pid)
Index: include/asm-sim/system.h
===================================================================
--- include/asm-sim/system.h	(revision 3786)
+++ include/asm-sim/system.h	(working copy)
@@ -186,8 +186,10 @@
 }
 
 #define xnarch_stack_size(tcb)    0
-#define xnarch_fpu_ptr(tcb)       (NULL)
-#define xnarch_user_task(tcb)     (NULL)
+#define xnarch_stack_base(tcb)	  NULL
+#define xnarch_stack_end(tcb)	  NULL
+#define xnarch_fpu_ptr(tcb)       NULL
+#define xnarch_user_task(tcb)     NULL
 #define xnarch_user_pid(tcb)      0
 
 /* Under the MVM, preemption only occurs at the C-source line level,
Index: include/nucleus/thread.h
===================================================================
--- include/nucleus/thread.h	(revision 3786)
+++ include/nucleus/thread.h	(working copy)
@@ -277,6 +277,8 @@
 #define xnthread_pending_signals(thread)  ((thread)->signals)
 #define xnthread_timeout(thread)           xntimer_get_timeout(&(thread)->rtimer)
 #define xnthread_stack_size(thread)        xnarch_stack_size(xnthread_archtcb(thread))
+#define xnthread_stack_base(thread)        xnarch_stack_base(xnthread_archtcb(thread))
+#define xnthread_stack_end(thread)         xnarch_stack_end(xnthread_archtcb(thread))
 #define xnthread_handle(thread)            ((thread)->registry.handle)
 #ifdef CONFIG_XENO_OPT_TIMING_PERIODIC
 #define xnthread_time_base(thread)         ((thread)->rtimer.base)
Index: src/skins/vxworks/taskInfo.c
===================================================================
--- src/skins/vxworks/taskInfo.c	(revision 3786)
+++ src/skins/vxworks/taskInfo.c	(working copy)
@@ -18,6 +18,7 @@
 
 #include <stdlib.h>
 #include <errno.h>
+#include <pthread.h>
 #include <nucleus/thread.h>	/* For status bits. */
 #include <vxworks/vxworks.h>
 
@@ -72,3 +73,40 @@
 
 	return !!(status & XNSUSP);
 }
+
+STATUS taskInfoGet(TASK_ID task_id, TASK_DESC *desc)
+{
+	pthread_attr_t attr;
+	int probe1, probe2;
+	size_t stacksize;
+	void *stackbase;
+	int err;
+
+	err = XENOMAI_SKINCALL2(__vxworks_muxid,
+				__vxworks_taskinfo_get, task_id, desc);
+	if (err) {
+		errno = abs(err);
+		return ERROR;
+	}
+
+	if (pthread_getattr_np((pthread_t)desc->opaque, &attr)) {
+		errno = S_objLib_OBJ_ID_ERROR;
+		return ERROR;
+	}
+
+	pthread_attr_getstack(&attr, &stackbase, &stacksize);
+	desc->stacksize = stacksize;
+	desc->pStackBase = stackbase;
+
+	if (&probe1 < &probe2)
+		/* Stack grows upward. */
+		desc->pStackEnd = (caddr_t)stackbase + stacksize;
+	else
+		/* Stack grows downward. */
+		desc->pStackEnd = (caddr_t)stackbase - stacksize;
+
+	desc->pExcStackBase = desc->pStackBase;
+	desc->pExcStackEnd = desc->pStackEnd;
+
+	return OK;
+}
Index: src/skins/vxworks/taskLib.c
===================================================================
--- src/skins/vxworks/taskLib.c	(revision 3786)
+++ src/skins/vxworks/taskLib.c	(working copy)
@@ -108,6 +108,7 @@
 	bulk.a1 = (u_long)iargs->name;
 	bulk.a2 = (u_long)iargs->prio;
 	bulk.a3 = (u_long)iargs->flags;
+	bulk.a4 = (u_long)pthread_self();
 
 	err = XENOMAI_SKINCALL3(__vxworks_muxid,
 				__vxworks_task_init,
Index: ksrc/skins/vxworks/syscall.c
===================================================================
--- ksrc/skins/vxworks/syscall.c	(revision 3786)
+++ ksrc/skins/vxworks/syscall.c	(working copy)
@@ -60,6 +60,7 @@
  * a1: const char *name;
  * a2: int prio;
  * a3: int flags;
+ * a4: pthread_self();
  * }
  */
 
@@ -120,6 +121,7 @@
 		     0, 0, 0, 0, 0, 0, 0, 0, 0, 0) == OK) {
 		/* Let the skin discard the TCB memory upon exit. */
 		task->auto_delete = 1;
+		task->ptid = bulk.a4;
 		/* Copy back the registry handle to the ph struct. */
 		ph.handle = xnthread_handle(&task->threadbase);
 		__xn_copy_to_user(curr, (void __user *)__xn_reg_arg2(regs), &ph,
@@ -693,6 +695,34 @@
 }
 
 /*
+ * int __wind_taskinfo_get(TASK_ID task_id, TASK_DESC *desc)
+ */
+static int __wind_taskinfo_get(struct task_struct *curr, struct pt_regs *regs)
+{
+	xnhandle_t handle = __xn_reg_arg1(regs);
+	TASK_DESC desc;
+	WIND_TCB *pTcb;
+	int err;
+
+	if (!__xn_access_ok
+	    (curr, VERIFY_WRITE, __xn_reg_arg2(regs), sizeof(desc)))
+		return -EFAULT;
+
+	pTcb = (WIND_TCB *)xnregistry_fetch(handle);
+
+	if (!pTcb)
+		return S_objLib_OBJ_ID_ERROR;
+
+	err = taskInfoGet((TASK_ID)pTcb, &desc);
+
+	if (!err)
+		__xn_copy_to_user(curr, (void __user *)__xn_reg_arg2(regs), &desc,
+				  sizeof(desc));
+
+	return err;
+}
+
+/*
  * int __wind_errno_taskset(TASK_ID task_id, int errcode)
  */
 
@@ -1305,6 +1335,7 @@
 	[__vxworks_taskinfo_name] = {&__wind_taskinfo_name, __xn_exec_any},
 	[__vxworks_taskinfo_iddfl] = {&__wind_taskinfo_iddfl, __xn_exec_any},
 	[__vxworks_taskinfo_status] = {&__wind_taskinfo_status, __xn_exec_any},
+	[__vxworks_taskinfo_get] = {&__wind_taskinfo_get, __xn_exec_any},
 	[__vxworks_errno_taskset] = {&__wind_errno_taskset, __xn_exec_primary},
 	[__vxworks_errno_taskget] = {&__wind_errno_taskget, __xn_exec_primary},
 	[__vxworks_kernel_timeslice] =
Index: ksrc/skins/vxworks/taskInfo.c
===================================================================
--- ksrc/skins/vxworks/taskInfo.c	(revision 3786)
+++ ksrc/skins/vxworks/taskInfo.c	(working copy)
@@ -70,3 +70,63 @@
 
 	return testbits(xnthread_state_flags(&task->threadbase), XNSUSP);
 }
+
+STATUS taskInfoGet(TASK_ID task_id, TASK_DESC *desc)
+{
+	wind_task_t *task;
+	xnflags_t status;
+	spl_t s;
+
+	memset(desc, 0, sizeof(*desc));
+
+	xnlock_get_irqsave(&nklock, s);
+
+	check_OBJ_ID_ERROR(task_id, wind_task_t, task, WIND_TASK_MAGIC,
+			   goto error);
+
+	desc->tid = task_id;
+	xnobject_copy_name(desc->name, task->name);
+	desc->priority = wind_denormalized_prio(xnthread_current_priority
+						(&task->threadbase));
+
+	status = xnthread_state_flags(&task->threadbase);
+
+	if (xnpod_current_thread() == &task->threadbase || (status & XNREADY))
+		desc->status |= WIND_READY;
+	else if (status & XNDORMANT)
+		desc->status |= WIND_DEAD;
+	else {
+		if (status & XNSUSP)
+			desc->status |= WIND_SUSPEND;
+		if (status & XNPEND)
+			desc->status |= WIND_PEND;
+		if (status & XNDELAY)
+			desc->status |= WIND_DELAY;
+	}
+
+	desc->flags = task->flags;
+	desc->entry = task->entry;
+	desc->errorStatus = errnoOfTaskGet(task_id);
+
+#ifdef CONFIG_XENO_OPT_PERVASIVE
+	if (status & XNSHADOW)
+		desc->opaque = task->ptid;
+		/* Userland should fill in the stack information. */
+	else
+#endif
+	{
+		desc->stacksize = xnthread_stack_size(&task->threadbase);
+		desc->pStackBase = (char *)xnthread_stack_base(&task->threadbase);
+		desc->pStackEnd = (char *)xnthread_stack_end(&task->threadbase);
+		desc->pExcStackBase = desc->pStackBase;
+		desc->pExcStackEnd = desc->pStackEnd;
+	}
+
+	xnlock_put_irqrestore(&nklock, s);
+
+	return OK;
+
+      error:
+	xnlock_put_irqrestore(&nklock, s);
+	return ERROR;
+}
Index: ksrc/skins/vxworks/module.c
===================================================================
--- ksrc/skins/vxworks/module.c	(revision 3786)
+++ ksrc/skins/vxworks/module.c	(working copy)
@@ -180,3 +180,4 @@
 EXPORT_SYMBOL(tickSet);
 EXPORT_SYMBOL(kernelTimeSlice);
 EXPORT_SYMBOL(kernelVersion);
+EXPORT_SYMBOL(taskInfoGet);
Index: ksrc/skins/vxworks/taskLib.c
===================================================================
--- ksrc/skins/vxworks/taskLib.c	(revision 3786)
+++ ksrc/skins/vxworks/taskLib.c	(working copy)
@@ -104,6 +104,8 @@
 	   neither. */
 
 #ifdef CONFIG_XENO_OPT_PERVASIVE
+ 	/* Caller should fill in this field whenever applicable. */
+ 	pTcb->ptid = 0;
 	if (flags & VX_SHADOW)
 		bflags |= XNSHADOW;
 #else /* !CONFIG_XENO_OPT_PERVASIVE */

Re: [Xenomai-help] VxWorks skin problem concerning WIND_TCBstructure

[Gilles Chanteperdrix]

On Thu, May 15, 2008 at 4:14 PM, Philippe Gerum <rpm@xenomai.org> wrote:
> Matthieu wrote:
>>
>> On Thu, 15 May 2008 15:12:32 +0200, "Gilles Chanteperdrix"
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>> On Thu, May 15, 2008 at 11:28 AM, Gilles Chanteperdrix
>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>> On Thu, May 15, 2008 at 8:10 AM, Matthieu
>>>> <matthieu.connaulte_xenomai@domain.hid> 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. 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;


-- 
 Gilles

Re: [Xenomai-help] VxWorks skin problem concerning WIND_TCBstructure

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> On Thu, May 15, 2008 at 4:14 PM, Philippe Gerum <rpm@xenomai.org> wrote:
>> Matthieu wrote:
>>> On Thu, 15 May 2008 15:12:32 +0200, "Gilles Chanteperdrix"
>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>> On Thu, May 15, 2008 at 11:28 AM, Gilles Chanteperdrix
>>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>>> On Thu, May 15, 2008 at 8:10 AM, Matthieu
>>>>> <matthieu.connaulte_xenomai@domain.hid> 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.

Re: [Xenomai-help] VxWorks skin problem concerning WIND_TCBstructure

[Gilles Chanteperdrix]

On Thu, May 15, 2008 at 5:56 PM, Philippe Gerum <rpm@xenomai.org> wrote:
> Gilles Chanteperdrix wrote:
>> On Thu, May 15, 2008 at 4:14 PM, Philippe Gerum <rpm@xenomai.org> wrote:
>>> Matthieu wrote:
>>>> On Thu, 15 May 2008 15:12:32 +0200, "Gilles Chanteperdrix"
>>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>>> On Thu, May 15, 2008 at 11:28 AM, Gilles Chanteperdrix
>>>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>>>> On Thu, May 15, 2008 at 8:10 AM, Matthieu
>>>>>> <matthieu.connaulte_xenomai@domain.hid> 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

-- 
 Gilles

Re: [Xenomai-help] VxWorks skin problem concerning WIND_TCBstructure

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> On Thu, May 15, 2008 at 5:56 PM, Philippe Gerum <rpm@xenomai.org> wrote:
>> Gilles Chanteperdrix wrote:
>>> On Thu, May 15, 2008 at 4:14 PM, Philippe Gerum <rpm@xenomai.org> wrote:
>>>> Matthieu wrote:
>>>>> On Thu, 15 May 2008 15:12:32 +0200, "Gilles Chanteperdrix"
>>>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>>>> On Thu, May 15, 2008 at 11:28 AM, Gilles Chanteperdrix
>>>>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>>>>> On Thu, May 15, 2008 at 8:10 AM, Matthieu
>>>>>>> <matthieu.connaulte_xenomai@domain.hid> 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.

[Xenomai-help] Re: VxWorks skin problem concerning WIND_TCBstructure

[Matthieu]

On Thu, 15 May 2008 18:23:30 +0200, Philippe Gerum <rpm@xenomai.org> wrote:
> Gilles Chanteperdrix wrote:
>> On Thu, May 15, 2008 at 5:56 PM, Philippe Gerum <rpm@xenomai.org> wrote:
>>> Gilles Chanteperdrix wrote:
>>>> On Thu, May 15, 2008 at 4:14 PM, Philippe Gerum <rpm@xenomai.org>
> wrote:
>>>>> Matthieu wrote:
>>>>>> On Thu, 15 May 2008 15:12:32 +0200, "Gilles Chanteperdrix"
>>>>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>>>>> On Thu, May 15, 2008 at 11:28 AM, Gilles Chanteperdrix
>>>>>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>>>>>> On Thu, May 15, 2008 at 8:10 AM, Matthieu
>>>>>>>> <matthieu.connaulte_xenomai@domain.hid> 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

Re: [Xenomai-help] VxWorks skin problem concerning WIND_TCBstructure

[Gilles Chanteperdrix]

On Fri, May 16, 2008 at 8:30 AM, Matthieu
<matthieu.connaulte_xenomai@domain.hid> wrote:
> On Thu, 15 May 2008 18:23:30 +0200, Philippe Gerum <rpm@xenomai.org> wrote:
>> Gilles Chanteperdrix wrote:
>>> On Thu, May 15, 2008 at 5:56 PM, Philippe Gerum <rpm@xenomai.org> wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> On Thu, May 15, 2008 at 4:14 PM, Philippe Gerum <rpm@xenomai.org>
>> wrote:
>>>>>> Matthieu wrote:
>>>>>>> On Thu, 15 May 2008 15:12:32 +0200, "Gilles Chanteperdrix"
>>>>>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>>>>>> On Thu, May 15, 2008 at 11:28 AM, Gilles Chanteperdrix
>>>>>>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>>>>>>> On Thu, May 15, 2008 at 8:10 AM, Matthieu
>>>>>>>>> <matthieu.connaulte_xenomai@domain.hid> 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
> ?

I suggest you patch your kernel with the patch Philippe sent, adapt it
to suit your needs, maybe changing TASK_DESC as in vxworks taskLib.h,
test and debug it, then send us a patch which we will be happy to
merge.

-- 
 Gilles

[Xenomai-help] Re: Re: VxWorks skin problem concerning WIND_TCBstructure

[Matthieu]

> I suggest you patch your kernel with the patch Philippe sent, adapt it
> to suit your needs, maybe changing TASK_DESC as in vxworks taskLib.h,
> test and debug it, then send us a patch which we will be happy to
> merge.
> 
> --
>  Gilles

Ok, I was about doing it.

I still have some questions about the migration of my app, as I don't know
Xenomai in details.

Here is part of my code which aims at defining a procedure to restart a
task. If you have time to have a look on it, it would be helpful.


 /*****************************************************************************
*
* vx_t_restart -  task restart routine.
*
* Restart a task with its original priority and mode.
*
* RETURNS: 
* EOK if successful.
* ERR_OBJID if the task id is invalid.
* ERR_OBJDEL if the task is deleted by another task while in t_restart.
* ANAIS_ERROR if an unknown failure in taskRestart.
*/

UINT32 vx_t_restart ( UINT32 tid,		/* task ID of task to restart */
					  UINT32 args[4])	/* new arguments for task */
{

  WIND_TCB 		*pTcb;		/* the task's control block */
  P2V_SHADOW_TCB 	*pShadow;			/* the TCB extension */ 
  UINT32 		tmp1;
  UINT32 		i;
  UINT32 		vxArgs[10];     /* larger arg array for vxWorks */
  UINT32 		lock;
  struct sigtcb 	*pSigTcb;
  
  /* get the task's TCB, and check for validity */
  
  if  (tid == 0)
	tid = taskIdSelf();
  
  if( (pTcb = taskTcb(tid)) == NULL) 
   	return (ERR_OBJID);
  
  /* get the TCB extension and make sure it's a p2v task */
  
  if( (pShadow = taskExtTcb(tid)) == NULL ) 
	return (ERR_OBJID);
  
  if (tid == taskIdSelf())
	{
	  /* self restart not possible because we have we have no context
	   * from which to sucessfully terminate or reinitialize ourself.
	   * We defer all self restarts to the exception task.
	   * To self restart within a critical section, we must TASK_UNSAFE ()
	   * until the safeCnt == 0.  Otherwise, the excTask would block
	   * forever trying to terminate us.
	   */
	  
	  while (pTcb->safeCnt > 0)	/* make task unsafe */
	    TASK_UNSAFE ();
	  	  
	  taskSpawn ("t_restart", 0, 0,
				 6000, ( FUNCPTR)vx_t_restart, (int) tid,
				 0, 0, 0, 0, 0, 0, 0, 0, 0);
	  FOREVER
	    taskSuspend (0);			/* wait for restart */
	}
  
  /* The following loop allows the target task to run until
   * it gives up all critical resources and can be suspended
   * without causing an interlock.  The criteria for suspending
   * the task here are the same as deleting a task -- both the
   * safeCnt and the lockCnt must be 0.  Note:  this loop does
   * things which should never appear in user code, namely entering
   * kernel mode and directly manipulating task queues.
   */
  
  lock = intLock();
  while ((pTcb->safeCnt > 0) ||
		 ((pTcb->status == WIND_READY) && (pTcb->lockCnt > 0)))
	{
	  kernelState = TRUE;				/* KERNEL ENTER */
	  
	  intUnlock (lock);				/* UNLOCK INTERRUPTS */
	  
	  if (pTcb == taskIdCurrent)
	    {

		  pTcb->safeCnt = 0;				/* unprotect */
		  pTcb->lockCnt = 0;				/* unlock */
		  
		  if (Q_FIRST (&pTcb->safetyQHead) != NULL)	/* flush safe queue */
			windPendQFlush (&pTcb->safetyQHead);
		  
		  windExit ();				/* KERNEL EXIT */
	    }
	  else						/* wait to destroy */
	    {
		  if (windPendQPut (&pTcb->safetyQHead, WAIT_FOREVER) != OK)
			{
			  windExit ();				/* KERNEL EXIT */
			  return (ANAIS_ERROR);
			}
		  
		  switch (windExit())
			{
			  
			case ERROR :				/* timed out */
		    return (ANAIS_ERROR);
			
			default :				/* we were flushed */
			  break;
			}
		}
	  
	  /* Make sure target task didn't exit */
	  
	  lock = intLock ();				/* LOCK INTERRTUPTS */
	  
	  if (TASK_ID_VERIFY (pTcb) != OK)
		{
		  intUnlock (lock);				/* UNLOCK INTERRUPTS */
		  return (ERR_OBJDEL);
	    }
	}
  
  /* Suspend the task being restarted (this already happened above 
   * if the task is restarting itself.
   */
  
  taskSuspend (tid);
	
  TASK_SAFE();                                       /* protect deleter */
  
  /* At this point target task is suspended and can't be deleted
   * by anyone else.  If task is restarting itself, it is safe from
   * deletion.
   */
  /* Save the pointers to the TCB extension, since the VxWorks TCB will
   * be wiped clean by taskRestart.
   */
  /* Set reserved field to NULL because delete hook runs when a
   * task is restarted -- and we don't want that!
   */
  tmp1 = (UINT32) pTcb->pTaskVar;
  pTcb->pTaskVar = NULL;

  /* Reuse signal info structure in the task stack */
  
  pSigTcb = pTcb->pSignalInfo;
  
  intUnlock(lock);  				/* INT UNLOCK */
  
  /* Disarm all the task's timers.
   * Need to taskLock because we don't want timers expiring and
   * trying to update linked list while we are.
   */

  /* set the task's new arguments */

  if ( args == NULL )
	vxArgs[0] = vxArgs[1] = vxArgs[2] = vxArgs[3] = 0;
  else
	for ( i = 0; i < 4; i++ )
	  vxArgs[i] = args[i];
  
  taskArgsSet (pTcb, pTcb->pStackBase, (int *) vxArgs);

  /*
   *  Note:  vxWorks' taskRestart keeps the current stack, rather than
   *  reducing the stacksize to the original. 
   *  To keep the outermost stack frame intact, must modify
   *  the vxWorks option word -- otherwise the stack would be
   *  reinitialized to 0xee's
   */
  
  pTcb->options |= VX_NO_STACK_FILL;
  
  /* don't let restarted task run till its TCB is fixed */
  
  taskLock ();   				/* TASK LOCK */
  
  if (taskRestart (tid) == ERROR)
	{
	  taskUnlock ();				/* TASK UNLOCK */
	  if (errno == S_objLib_OBJ_DELETED) 
	    return (ERR_OBJDEL);
	  else
	    return (ANAIS_ERROR);
	}

  /* Reconnect TCB extension */
  pTcb->pTaskVar = (struct taskVar *) tmp1;

  /* reinitialize signal info */
  
  bzero ((char *) pSigTcb, sizeof (struct sigtcb));
  for (i = 0; i <= _NSIGS; i++)
	pSigTcb->sigt_qhead[i].sigq_next = pSigTcb->sigt_qhead[i].sigq_prev =
&pSigTcb->sigt_qhead[i];

  
  pTcb->pSignalInfo = pSigTcb;

  /*
   * restarting a task clears all pending signals and events and resets 
   * the signal handler.
   */

  taskUnlock ();   				/* TASK UNLOCK */
  taskUnsafe ();   				/* TASK UNSAFE */
  
  return (EOK);
}

There are still WIND_TCB members use in this part of code, and I thing it's
possible to simplify this routine...
What do you think about it ?

Matthieu

Re: [Xenomai-help] VxWorks skin problem concerning WIND_TCBstructure

[Gilles Chanteperdrix]

On Fri, May 16, 2008 at 12:11 PM, Matthieu
<matthieu.connaulte_xenomai@domain.hid> wrote:
>> I suggest you patch your kernel with the patch Philippe sent, adapt it
>> to suit your needs, maybe changing TASK_DESC as in vxworks taskLib.h,
>> test and debug it, then send us a patch which we will be happy to
>> merge.
>>
>> --
>>  Gilles
>
> Ok, I was about doing it.
>
> I still have some questions about the migration of my app, as I don't know
> Xenomai in details.
>
> Here is part of my code which aims at defining a procedure to restart a
> task. If you have time to have a look on it, it would be helpful.

taskRestart is not supported in user-space by the VxWorks skin. So,
the first thing to do is to check if your application really needs
this service, and if it does, implement taskRestart.

-- 
 Gilles

[Xenomai-help] Re: Re: VxWorks skin problem concerning WIND_TCBstructure

[Matthieu]

On Fri, 16 May 2008 18:09:58 +0200, "Gilles Chanteperdrix"
<gilles.chanteperdrix@xenomai.org> wrote:
> On Fri, May 16, 2008 at 12:11 PM, Matthieu
> <matthieu.connaulte_xenomai@domain.hid> wrote:
>>> I suggest you patch your kernel with the patch Philippe sent, adapt it
>>> to suit your needs, maybe changing TASK_DESC as in vxworks taskLib.h,
>>> test and debug it, then send us a patch which we will be happy to
>>> merge.
>>>
>>> --
>>>  Gilles
>>
>> Ok, I was about doing it.
>>
>> I still have some questions about the migration of my app, as I don't
> know
>> Xenomai in details.
>>
>> Here is part of my code which aims at defining a procedure to restart a
>> task. If you have time to have a look on it, it would be helpful.
> 
> taskRestart is not supported in user-space by the VxWorks skin. So,
> the first thing to do is to check if your application really needs
> this service, and if it does, implement taskRestart.
> 
> --
>  Gilles

I finally needn't taskRestart.
I'm about modifing the patch. When I finish it, I'll send you.

Matthieu

[Xenomai-help] Re: Re: Re: VxWorks skin problem concerning WIND_TCBstructure

[Matthieu]

[-- Attachment #1: Type: text/plain, Size: 229 bytes --]

Hi

I have modified the patch, I just renamed the TASK_DESC structure members
with "td_" prefix since I didn't have to implement something else. I just
simplify my code to the maximum.

I have attached the patch

Matthieu

[-- Attachment #2: vxworktaskinfoget.patch --]
[-- Type: application/octet-stream, Size: 13077 bytes --]

Index: include/asm-ia64/system.h
===================================================================
--- include/asm-ia64/system.h	(revision 3786)
+++ include/asm-ia64/system.h	(working copy)
@@ -32,6 +32,8 @@
 #define XNARCH_THREAD_STACKSZ  KERNEL_STACK_SIZE

 #define xnarch_stack_size(tcb)  ((tcb)->stacksize)
+#define xnarch_stack_base(tcb)	((tcb)->stackbase)
+#define xnarch_stack_end(tcb)	((caddr_t)(tcb)->stackbase - (tcb)->stacksize)
 #define xnarch_user_task(tcb)   ((tcb)->user_task)
 #define xnarch_user_pid(tcb)    ((tcb)->user_task->pid)

Index: include/vxworks/syscall.h
===================================================================
--- include/vxworks/syscall.h	(revision 3786)
+++ include/vxworks/syscall.h	(working copy)
@@ -69,12 +69,14 @@
 #define __vxworks_wd_cancel        43
 #define __vxworks_wd_wait          44
 #define __vxworks_int_context      45
+#define __vxworks_taskinfo_get     46

 struct wind_arg_bulk {

     u_long a1;
     u_long a2;
     u_long a3;
+    u_long a4;
 };

 #ifdef __KERNEL__
Index: include/vxworks/vxworks.h
===================================================================
--- include/vxworks/vxworks.h	(revision 3786)
+++ include/vxworks/vxworks.h	(working copy)
@@ -127,6 +127,32 @@
     TASK_ID handle;
 } WIND_TCB_PLACEHOLDER;

+#define WIND_READY	0x0
+#define WIND_SUSPEND	0x1
+#define WIND_PEND	0x2
+#define WIND_DELAY	0x4
+#define WIND_DEAD	0x8
+#define WIND_STOP	0x10	/* Never reported. */
+
+typedef struct _TASK_DESC {
+
+	TASK_ID td_tid;
+	char    td_name[XNOBJECT_NAME_LEN];
+	int	td_priority;
+	int	td_status;
+	int	td_flags;
+	FUNCPTR	td_entry;
+	int	td_stacksize;
+	char	*td_pStackBase;
+	char	*td_pStackEnd;
+	char	*td_pExcStackBase;
+	char	*td_pExcStackEnd;
+	int	td_errorStatus;
+
+	unsigned long td_opaque;
+
+} TASK_DESC;
+
 typedef void (*wind_timer_t)(long);

 typedef struct wind_wd_utarget {
@@ -156,6 +182,9 @@
     int status;
     int prio;
     FUNCPTR entry;
+#ifdef CONFIG_XENO_OPT_PERVASIVE
+    unsigned long ptid;
+#endif

     /* Xenomai specific: used by taskLib */

@@ -345,6 +374,9 @@

 BOOL taskIsSuspended (TASK_ID task_id);

+STATUS taskInfoGet(TASK_ID task_id,
+		   TASK_DESC *desc);
+
 STATUS semGive(SEM_ID sem_id);

 STATUS semTake(SEM_ID sem_id,
Index: include/asm-blackfin/system.h
===================================================================
--- include/asm-blackfin/system.h	(revision 3786)
+++ include/asm-blackfin/system.h	(working copy)
@@ -30,6 +30,8 @@
 #define XNARCH_THREAD_STACKSZ   8192

 #define xnarch_stack_size(tcb)  ((tcb)->stacksize)
+#define xnarch_stack_base(tcb)	((tcb)->stackbase)
+#define xnarch_stack_end(tcb)	((caddr_t)(tcb)->stackbase - (tcb)->stacksize)
 #define xnarch_user_task(tcb)   ((tcb)->user_task)
 #define xnarch_user_pid(tcb)    ((tcb)->user_task->pid)

Index: include/asm-powerpc/system.h
===================================================================
--- include/asm-powerpc/system.h	(revision 3786)
+++ include/asm-powerpc/system.h	(working copy)
@@ -35,6 +35,8 @@
 #endif

 #define xnarch_stack_size(tcb)  ((tcb)->stacksize)
+#define xnarch_stack_base(tcb)	((tcb)->stackbase)
+#define xnarch_stack_end(tcb)	((caddr_t)(tcb)->stackbase - (tcb)->stacksize)
 #define xnarch_user_task(tcb)   ((tcb)->user_task)
 #define xnarch_user_pid(tcb)    ((tcb)->user_task->pid)

Index: include/asm-arm/system.h
===================================================================
--- include/asm-arm/system.h	(revision 3786)
+++ include/asm-arm/system.h	(working copy)
@@ -32,6 +32,8 @@
 #define XNARCH_THREAD_STACKSZ   4096

 #define xnarch_stack_size(tcb)  ((tcb)->stacksize)
+#define xnarch_stack_base(tcb)	((tcb)->stackbase)
+#define xnarch_stack_end(tcb)	((caddr_t)(tcb)->stackbase - (tcb)->stacksize)
 #define xnarch_user_task(tcb)   ((tcb)->user_task)
 #define xnarch_user_pid(tcb)    ((tcb)->user_task->pid)

Index: include/asm-x86/system_64.h
===================================================================
--- include/asm-x86/system_64.h	(revision 3786)
+++ include/asm-x86/system_64.h	(working copy)
@@ -31,6 +31,8 @@
 #define XNARCH_THREAD_STACKSZ	4096

 #define xnarch_stack_size(tcb)  ((tcb)->stacksize)
+#define xnarch_stack_base(tcb)	((tcb)->stackbase)
+#define xnarch_stack_end(tcb)	((caddr_t)(tcb)->stackbase - (tcb)->stacksize)
 #define xnarch_fpu_ptr(tcb)     ((tcb)->fpup)
 #define xnarch_user_task(tcb)   ((tcb)->user_task)
 #define xnarch_user_pid(tcb)    ((tcb)->user_task->pid)
Index: include/asm-x86/system_32.h
===================================================================
--- include/asm-x86/system_32.h	(revision 3786)
+++ include/asm-x86/system_32.h	(working copy)
@@ -31,6 +31,8 @@
 #define XNARCH_THREAD_STACKSZ 4096

 #define xnarch_stack_size(tcb)  ((tcb)->stacksize)
+#define xnarch_stack_base(tcb)	((tcb)->stackbase)
+#define xnarch_stack_end(tcb)	((caddr_t)(tcb)->stackbase - (tcb)->stacksize)
 #define xnarch_fpu_ptr(tcb)     ((tcb)->fpup)
 #define xnarch_user_task(tcb)   ((tcb)->user_task)
 #define xnarch_user_pid(tcb)    ((tcb)->user_task->pid)
Index: include/asm-sim/system.h
===================================================================
--- include/asm-sim/system.h	(revision 3786)
+++ include/asm-sim/system.h	(working copy)
@@ -186,8 +186,10 @@
 }

 #define xnarch_stack_size(tcb)    0
-#define xnarch_fpu_ptr(tcb)       (NULL)
-#define xnarch_user_task(tcb)     (NULL)
+#define xnarch_stack_base(tcb)	  NULL
+#define xnarch_stack_end(tcb)	  NULL
+#define xnarch_fpu_ptr(tcb)       NULL
+#define xnarch_user_task(tcb)     NULL
 #define xnarch_user_pid(tcb)      0

 /* Under the MVM, preemption only occurs at the C-source line level,
Index: include/nucleus/thread.h
===================================================================
--- include/nucleus/thread.h	(revision 3786)
+++ include/nucleus/thread.h	(working copy)
@@ -277,6 +277,8 @@
 #define xnthread_pending_signals(thread)  ((thread)->signals)
 #define xnthread_timeout(thread)           xntimer_get_timeout(&(thread)->rtimer)
 #define xnthread_stack_size(thread)        xnarch_stack_size(xnthread_archtcb(thread))
+#define xnthread_stack_base(thread)        xnarch_stack_base(xnthread_archtcb(thread))
+#define xnthread_stack_end(thread)         xnarch_stack_end(xnthread_archtcb(thread))
 #define xnthread_handle(thread)            ((thread)->registry.handle)
 #ifdef CONFIG_XENO_OPT_TIMING_PERIODIC
 #define xnthread_time_base(thread)         ((thread)->rtimer.base)
Index: src/skins/vxworks/taskInfo.c
===================================================================
--- src/skins/vxworks/taskInfo.c	(revision 3786)
+++ src/skins/vxworks/taskInfo.c	(working copy)
@@ -18,6 +18,7 @@

 #include <stdlib.h>
 #include <errno.h>
+#include <pthread.h>
 #include <nucleus/thread.h>	/* For status bits. */
 #include <vxworks/vxworks.h>

@@ -72,3 +73,40 @@

 	return !!(status & XNSUSP);
 }
+
+STATUS taskInfoGet(TASK_ID task_id, TASK_DESC *desc)
+{
+	pthread_attr_t attr;
+	int probe1, probe2;
+	size_t stacksize;
+	void *stackbase;
+	int err;
+
+	err = XENOMAI_SKINCALL2(__vxworks_muxid,
+				__vxworks_taskinfo_get, task_id, desc);
+	if (err) {
+		errno = abs(err);
+		return ERROR;
+	}
+
+	if (pthread_getattr_np((pthread_t)desc->td_opaque, &attr)) {
+		errno = S_objLib_OBJ_ID_ERROR;
+		return ERROR;
+	}
+
+	pthread_attr_getstack(&attr, &stackbase, &stacksize);
+	desc->td_stacksize = stacksize;
+	desc->td_pStackBase = stackbase;
+
+	if (&probe1 < &probe2)
+		/* Stack grows upward. */
+		desc->td_pStackEnd = (caddr_t)stackbase + stacksize;
+	else
+		/* Stack grows downward. */
+		desc->td_pStackEnd = (caddr_t)stackbase - stacksize;
+
+	desc->td_pExcStackBase = desc->td_pStackBase;
+	desc->td_pExcStackEnd = desc->td_pStackEnd;
+
+	return OK;
+}
Index: src/skins/vxworks/taskLib.c
===================================================================
--- src/skins/vxworks/taskLib.c	(revision 3786)
+++ src/skins/vxworks/taskLib.c	(working copy)
@@ -108,6 +108,7 @@
 	bulk.a1 = (u_long)iargs->name;
 	bulk.a2 = (u_long)iargs->prio;
 	bulk.a3 = (u_long)iargs->flags;
+	bulk.a4 = (u_long)pthread_self();

 	err = XENOMAI_SKINCALL3(__vxworks_muxid,
 				__vxworks_task_init,
Index: ksrc/skins/vxworks/syscall.c
===================================================================
--- ksrc/skins/vxworks/syscall.c	(revision 3786)
+++ ksrc/skins/vxworks/syscall.c	(working copy)
@@ -60,6 +60,7 @@
  * a1: const char *name;
  * a2: int prio;
  * a3: int flags;
+ * a4: pthread_self();
  * }
  */

@@ -120,6 +121,7 @@
 		     0, 0, 0, 0, 0, 0, 0, 0, 0, 0) == OK) {
 		/* Let the skin discard the TCB memory upon exit. */
 		task->auto_delete = 1;
+		task->ptid = bulk.a4;
 		/* Copy back the registry handle to the ph struct. */
 		ph.handle = xnthread_handle(&task->threadbase);
 		__xn_copy_to_user(curr, (void __user *)__xn_reg_arg2(regs), &ph,
@@ -693,6 +695,34 @@
 }

 /*
+ * int __wind_taskinfo_get(TASK_ID task_id, TASK_DESC *desc)
+ */
+static int __wind_taskinfo_get(struct task_struct *curr, struct pt_regs *regs)
+{
+	xnhandle_t handle = __xn_reg_arg1(regs);
+	TASK_DESC desc;
+	WIND_TCB *pTcb;
+	int err;
+
+	if (!__xn_access_ok
+	    (curr, VERIFY_WRITE, __xn_reg_arg2(regs), sizeof(desc)))
+		return -EFAULT;
+
+	pTcb = (WIND_TCB *)xnregistry_fetch(handle);
+
+	if (!pTcb)
+		return S_objLib_OBJ_ID_ERROR;
+
+	err = taskInfoGet((TASK_ID)pTcb, &desc);
+
+	if (!err)
+		__xn_copy_to_user(curr, (void __user *)__xn_reg_arg2(regs), &desc,
+				  sizeof(desc));
+
+	return err;
+}
+
+/*
  * int __wind_errno_taskset(TASK_ID task_id, int errcode)
  */

@@ -1305,6 +1335,7 @@
 	[__vxworks_taskinfo_name] = {&__wind_taskinfo_name, __xn_exec_any},
 	[__vxworks_taskinfo_iddfl] = {&__wind_taskinfo_iddfl, __xn_exec_any},
 	[__vxworks_taskinfo_status] = {&__wind_taskinfo_status, __xn_exec_any},
+	[__vxworks_taskinfo_get] = {&__wind_taskinfo_get, __xn_exec_any},
 	[__vxworks_errno_taskset] = {&__wind_errno_taskset, __xn_exec_primary},
 	[__vxworks_errno_taskget] = {&__wind_errno_taskget, __xn_exec_primary},
 	[__vxworks_kernel_timeslice] =
Index: ksrc/skins/vxworks/taskInfo.c
===================================================================
--- ksrc/skins/vxworks/taskInfo.c	(revision 3786)
+++ ksrc/skins/vxworks/taskInfo.c	(working copy)
@@ -70,3 +70,63 @@

 	return testbits(xnthread_state_flags(&task->threadbase), XNSUSP);
 }
+
+STATUS taskInfoGet(TASK_ID task_id, TASK_DESC *desc)
+{
+	wind_task_t *task;
+	xnflags_t status;
+	spl_t s;
+
+	memset(desc, 0, sizeof(*desc));
+
+	xnlock_get_irqsave(&nklock, s);
+
+	check_OBJ_ID_ERROR(task_id, wind_task_t, task, WIND_TASK_MAGIC,
+			   goto error);
+
+	desc->td_tid = task_id;
+	xnobject_copy_name(desc->td_name, task->name);
+	desc->td_priority = wind_denormalized_prio(xnthread_current_priority
+						(&task->threadbase));
+
+	status = xnthread_state_flags(&task->threadbase);
+
+	if (xnpod_current_thread() == &task->threadbase || (status & XNREADY))
+		desc->td_status |= WIND_READY;
+	else if (status & XNDORMANT)
+		desc->td_status |= WIND_DEAD;
+	else {
+		if (status & XNSUSP)
+			desc->td_status |= WIND_SUSPEND;
+		if (status & XNPEND)
+			desc->td_status |= WIND_PEND;
+		if (status & XNDELAY)
+			desc->td_status |= WIND_DELAY;
+	}
+
+	desc->td_flags = task->flags;
+	desc->td_entry = task->entry;
+	desc->td_errorStatus = errnoOfTaskGet(task_id);
+
+#ifdef CONFIG_XENO_OPT_PERVASIVE
+	if (status & XNSHADOW)
+		desc->td_opaque = task->ptid;
+		/* Userland should fill in the stack information. */
+	else
+#endif
+	{
+		desc->td_stacksize = xnthread_stack_size(&task->threadbase);
+		desc->td_pStackBase = (char *)xnthread_stack_base(&task->threadbase);
+		desc->td_pStackEnd = (char *)xnthread_stack_end(&task->threadbase);
+		desc->td_pExcStackBase = desc->td_pStackBase;
+		desc->td_pExcStackEnd = desc->td_pStackEnd;
+	}
+
+	xnlock_put_irqrestore(&nklock, s);
+
+	return OK;
+
+      error:
+	xnlock_put_irqrestore(&nklock, s);
+	return ERROR;
+}
Index: ksrc/skins/vxworks/module.c
===================================================================
--- ksrc/skins/vxworks/module.c	(revision 3786)
+++ ksrc/skins/vxworks/module.c	(working copy)
@@ -180,3 +180,4 @@
 EXPORT_SYMBOL(tickSet);
 EXPORT_SYMBOL(kernelTimeSlice);
 EXPORT_SYMBOL(kernelVersion);
+EXPORT_SYMBOL(taskInfoGet);
Index: ksrc/skins/vxworks/taskLib.c
===================================================================
--- ksrc/skins/vxworks/taskLib.c	(revision 3786)
+++ ksrc/skins/vxworks/taskLib.c	(working copy)
@@ -104,6 +104,8 @@
 	   neither. */

 #ifdef CONFIG_XENO_OPT_PERVASIVE
+ 	/* Caller should fill in this field whenever applicable. */
+ 	pTcb->ptid = 0;
 	if (flags & VX_SHADOW)
 		bflags |= XNSHADOW;
 #else /* !CONFIG_XENO_OPT_PERVASIVE */