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
well.
Merged, thanks.
Doesn't show up on
http://www.denx.de/cgi-bin/gitweb.cgi?p=xenomai-solo.git;a=summary
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
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
