Python and VxWorks

[Richard Wolff]

A-periodically, someone asks about how to embed/port Python to Vxworks.
As has been said before, it's not difficult.  However, details have
been somewhat lacking.  What follows are some of the details.  This same
information and the rest of the story can be found at
  http://daikon.tuc.noao.edu/python

As usual, no warranty for fitness nor merchantability nor freedom from
un-wanted side-effects of creeping featurism.

Richard

---------------------------------------------------------------------

Here's how I set up Python as an embedded task in VxWorks.  Note that
building the system for VxWorks is not going to be as nicely set up as
doing so for most systems.  We can't run configure for one thing.  So
there are a number of changes that you have to consider/make by hand.
Before getting to the details, a thank you to Paul Fernhout for some
helpful advice in a recent comp.lang.python posting.

Perhaps the best way to get started is to build Python on your workstation
and use that as the start of the port.  This way, many of the files you
need will be present.  For instance, the parser generator program will
be built and run, so it isn't needed for the cross-compile.  You'll also
have  config.h  file that might well serve as a useful starting point.

The files from the distribution that you need to modify are in Include,
Modules, Objects, Parser, and Python.  At the top level, you'll need to
change Makefile and config.h.  The diff file (pydiff) will make a lot
of changes for you, but you should probably take a look at what's going
on first.  There may well be better ways of doing things.  By the way,
the diff is against Python 1.5.2 and is for VxWorks 5.2 (pre-Tornado).

You'll need (or want) to do the following:
1) Edit the top level Makefile to reflect the correct definitions for
CC, RANLIB, LD, and AR.  Make the same edits in the Makefiles in
Objects, Parser, and Python directories.  Make the same edits in
Makefile.pre in Modules.

2) Edit config.h

3) Get a version of getopt.c and put it in the top level directory, along
with a suitable getopt.h, which can go in the Include directory.  Or put
getopt.c somewhere else and modify Makefiles suitably.

4) Edit Setup (and Setup.local, Setup.thread).

5) If you include modules that I didn't, you'll probably want to edit
that module's ".c" file.  If you have a different version of VxWorks,
look for the VXWORKS define and modify as needed.

6) Modify Modules/python.c as you will.  You probably will want to
modify the arg0 value.

7) Remove the buildno file if you want.

8) In Modules, run makesetup to build the Makefile and config.c.  If you
have used both Setup and Setup.local, run   makesetup Setup Setup.local

9) At the top level, run make.  The output will be "python.o" in this
directory.

10) Load that into your VxWorks system.  On my system, Python took too
much stack space to run under the shell, so I spawn the task, which is
what "sppy" ("spawn python") does.  If Python comes alive, but you get
lots of xxx:yyy: No such file or directory    and  xxx:yyy: File exists,
don't worry.  Those messages are from 'stat' as it probes the file
system on xxx looking for library files.  I don't know how to stop
this; it's both annoying and harmless.

10a) You should 'cd "python-top-level-directory"' before you load the
python.o file, or you should be sure that you have the Lib directory
in a standard place (or you have modified the Makefiles to reflect
suitable prefix and exec-prefix directories).  Or you might set
the PYTHONHOME environment variable in Modules/python.c before Python
goes through its initialization steps.

11) When the >>> prompt appears, it's likely that a carriage return will
bring back the shell prompt.  That's because the shell runs at much
higher priority than Python and it grabs all the characters.  It needs
to be demoted, which is what the "demoteShell" code in Modules/python.c
does (with a vengeance...there's probably no need to suspend the shell).
So run that routine from the shell, and then run Python as you will.

12) To exit, the usual command sequence (or sys.exit) will get you
back to the shell prompt, at which time, you should raise the shell
priority back to 1 (use "restoreShell").

13) You can make things more interesting by having Python code that
will allow you to run VxWorks routines.  You need a slight extension of
Python, to be found in my "Modules/vxmodule.c".  Modify Setup (or
Setup.local, rerun makesetup, and then the top level make).

14) A simple VxWorks class makes use of the vxmodule code.  See
VxWorks.py Thus, i = VxWorks.Vxw("i","") builds an 'i' such that 'i()'
gives the same task information table from the Python prompt as it does
from the VxWorks shell.  Or,  routeAdd = VxWorks.Vxw("routeAdd", "ss")
builds a routeAdd function that can be used to add a route to the
VxWorks routing table  (routeAdd("90.0.0.0, "gateway")), and so forth.

15) If you have the VxWorks module in place, you can then define
	rs = VxWorks.Vxw("restoreShell","")
and when you run rs(), you have, for interactive use, effectively
suspended Python, as the shell will get all the input characters.
"demoteShell" and 'rs' thus allows you to switch back and forth between
Python and the VxWorks shell.


Richard Wolff
May, 2000

P.S.  I did this work because I want to run various routines in the
VxWorks environment under the control of a "scripting" language.  There
are three approaches here...embed Python in VxWorks, which is what this
note is about, connect Python running on a workstation to the VxWorks
shell via telnet, or connect Python on the workstation to a process on
the VxWorks box via a socket connection.  Which way to go is nice
question.  The other question one ought to answer is, "why aren't you
using rt-linux?".

P.P.S.  All this code is released under the same terms and conditions
as the Python license.
-- 
Richard Wolff, National Optical Astronomy Observatories, Tucson, AZ
Internet: rwolff at noao.edu         Phonenet:     +1 520 318 8392