From: Philippe Gerum <rpm@xenomai.org>
To: Robert Schwebel <r.schwebel@domain.hid>
Cc: xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] [PATCH][SOLO] add more warnings
Date: Sat, 29 Mar 2008 09:32:36 +0100 [thread overview]
Message-ID: <47EDFEA4.2020701@domain.hid> (raw)
In-Reply-To: <20080328204631.GC9009@domain.hid>
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.
next prev parent reply other threads:[~2008-03-29 8:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-28 19:03 [Xenomai-core] [PATCH][SOLO] add more warnings Robert Schwebel
2008-03-28 19:52 ` Philippe Gerum
2008-03-28 20:26 ` Philippe Gerum
2008-03-28 20:46 ` Robert Schwebel
2008-03-28 23:06 ` Wolfgang Denk
2008-03-29 8:32 ` Philippe Gerum [this message]
2008-03-28 20:14 ` Philippe Gerum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47EDFEA4.2020701@domain.hid \
--to=rpm@xenomai.org \
--cc=r.schwebel@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.