Robert Schwebel wrote:
> On Fri, Mar 28, 2008 at 08:52:26PM +0100, Philippe Gerum wrote:
>>> I've looked into the first ones only yet and it looks to me like the
>>> type definitions have to be reviewed carefully. For example, TASK_ID is
>>> defined to be unsigned long, whereas the vxworks documentation [1] looks
>>> more like if we need 'int' there. Which also makes me wonder if vxworks
>>> has a special idea about what 'int' is;
>> VxWorks assumes 32bit and sizeof(void *) == sizeof(int), unfortunately. See
>> taskSpawn() for instance.
> Yes, which probably means that using 'int' and friends is not a good
> idea.
>> Did you mean stdint.h?
> Probably better, yes.
>> What we need is an integer type which is able to carry a pointer on
>> 32/64bit platforms, so we should rather use intptr_t I guess, as per
>> C99, which expands as a long type. Object ids as unsigned long is a
>> left over from the co-kernel version, where we use actual integer
>> handles returned from kernel space, and not pointers in disguise. Will
>> fix, thanks.
> Hmm, if vxworks assumes "int" to be 32 bit, couldn't it lead to problems
> if the pointer size itself isn't 32 bit as well?

VxWorks only documents that one may assume TASK_ID == pointer to TCB, which
implies sizeof(int) == sizeof(struct WIND_TCB *) as per the taskInit
documentation and the original taskSpawn prototype. But using a different scalar
type than int to underlay TASK_ID, which would guarantee sizeof(TASK_ID) ==
sizeof(struct WIND_TCB *) is logically ok (and actually always worked so far in
actual ports of legacy apps over the VxWorks skin).

Said differently, any application assuming that a task identifier must be 32bit
wide would only work in a 32bit environment anyway, as implied by the initial
VxWorks assumption that sizeof(TASK_ID) == sizeof(struct WIND_TCB *). Given that
sizeof(intptr_t) is 32bit in such environment, we would be fine in this case as

>> Merged, thanks.
> Doesn't show up on 

My GIT tree is mirrored by a cron job to the public repo. You will see the
changes after the next refresh has taken place.

> ?
> Robert


Xenomai-core mailing list

Reply via email to