Evaluating port to VxWorks - for medical imaging application - C/C++
Larry D'Cunha
We are considering porting a commercial medical imaging application to
VxWorks. The code to be ported is primarily in C. We already build
our product on different flavours of Unix (incl Solaris).
We are interested in doing a size/effort estimate for the port to
VxWorks. I am wondering if it is possible for us to acquire manuals
(API references) for VxWorks system libraries before any purchase is
made.
I have found the VxWorks programmer's guide
www.windriver.com/pdf/vxworks_guide.pdf but don't know if that's all
there is out there.
We are most concerned with porting unix system function calls in our
code that may not be available in VxWorks. (for example, some of our
code uses sockets and DNS functions gethostbyname(), gethostname(),
recvfrom(), setsockopt(), select()etc.) We also use the standard C
functions like strcmp, sprintf, malloc, free, and other unix system
functions like getuid, getpid, ioctl and fcntl. I have no idea if all
these functions are available in VxWorks.
Can anyone enlighten me on the feasibility of porting C code to
VxWorks with these kinds of functions?
Thank you,
Larry
John
I don't believe that there is a downloadable version of the reference
manual available anymore unless you have an online support account,
but perhaps the easiest thing to do is simply to call Wind River and
ask for an evaluation copy of the product - that will come with online
docs at least, maybe even printed copies.
> We are most concerned with porting unix system function calls in our
> code that may not be available in VxWorks. (for example, some of our
> code uses sockets and DNS functions gethostbyname(), gethostname(),
DNS resolving is supported, though the API is a little different.
Porting from one to the other is generally easy.
> recvfrom(), setsockopt(), select()etc.) We also use the standard C
> functions like strcmp, sprintf, malloc, free, and other unix system
These should all be OK.
> functions like getuid, getpid,
These are not supported by VxWorks since it does not have a concept of
users and groups.
> ioctl and fcntl.
ioctl() is available, but whether the specific functions you are using
are supported will depend on (a) what those functions are and (b) what
kind of file descriptor you apply them to.
fcntl() is not part of the VxWorks API, but some of the operations
that it provides can be achieved by other means (usually an ioctl()
call IIRC).
HTH,
John...
Larry D'Cunha
> Hello,
>
> I don't believe that there is a downloadable version of the reference
> manual available anymore unless you have an online support account,
> but perhaps the easiest thing to do is simply to call Wind River and
> ask for an evaluation copy of the product - that will come with online
> docs at least, maybe even printed copies.
Thanks, I found the reference manual on some professor's website!
> > ioctl and fcntl.
>
> ioctl() is available, but whether the specific functions you are using
> are supported will depend on (a) what those functions are and (b) what
> kind of file descriptor you apply them to.
>
> fcntl() is not part of the VxWorks API, but some of the operations
> that it provides can be achieved by other means (usually an ioctl()
> call IIRC).
>
> HTH,
>
> John...
Thanks very much for this insight. I have narrowed my VxWorks pre-port
analysis down to 1 function in our code to be ported, fcntl(). It is
being called three times with these parameters.
fcntl(c->sfd, F_GETFL, 0)
fcntl(c->sfd, F_SETFL, flags | O_NDELAY)
fcntl(c->sfd, F_SETFL, flags)
But I've no real idea on what exactly it is doing. If the above can be
done with ioctl() I'd sure like to know how.
Thanks again.
Larry
Leonid Rosenboim
news:456de2c6.03010...@posting.google.com...
[snip]
> Thanks very much for this insight. I have narrowed my VxWorks pre-port
> analysis down to 1 function in our code to be ported, fcntl(). It is
> being called three times with these parameters.
>
> fcntl(c->sfd, F_GETFL, 0)
> fcntl(c->sfd, F_SETFL, flags | O_NDELAY)
> fcntl(c->sfd, F_SETFL, flags)
>
> But I've no real idea on what exactly it is doing. If the above can be
> done with ioctl() I'd sure like to know how.
>
in VxWorks this indeed can be done with ioctl(), but will only
work with sockets (both TCP and UDP), not with files.
On Unix, NBIO can be set on sockets and NFS files.
You'd need to find where the c->sfd is created to know
where your situated.
--
-----------------------------------------------------------------------
Leonid Rosenboim Visit: http://www.masada2000.org/historical.html
Consultant Email: my first name at consultant dot com
John
> Thanks, I found the reference manual on some professor's website!
Hmmm... that doesn't sound terribly legal since it is technically a
copyrighted work.
> Thanks very much for this insight. I have narrowed my VxWorks pre-port
> analysis down to 1 function in our code to be ported, fcntl(). It is
> being called three times with these parameters.
>
> fcntl(c->sfd, F_GETFL, 0)
This gets the current flag settings for c->sfd.
> fcntl(c->sfd, F_SETFL, flags | O_NDELAY)
Assuming that c->sfd is a file descriptor for something that supports
non-blocking operation (only a socket in VxWorks IIRC), then this will
set the I/O to non-blocking mode + whatever was in flags (I'm going to
guess that flags holds the return value from the previous call).
> fcntl(c->sfd, F_SETFL, flags)
If, as I assumed in the last case, flags holds the value returned by
the F_GETFL operation above, then this is probably being used to
return the file descriptor to blocking mode.
> But I've no real idea on what exactly it is doing. If the above can be
> done with ioctl() I'd sure like to know how.
Switching between non-blocking and blocking modes is simple:
on = TRUE; /* TRUE for non-blocking, FALSE for blocking */
status = ioctl (c->sfd, FIONBIO, &on);
Detecting which one is currently set is harder. I can't see a way to
get the current setting for an arbitrary socket descriptor. If you can
keep track of this in the application (or you know that it will always
be blocking mode when the routine is called), then the above two lines
will work for you.
HTH,
John...