> There are many levels of globallness (I may patent that word!).
> Right now, there does not appear to be any way to define a variable so that
> it is global to the module, but not global to the entire kernel. To make
> things even more difficult, it would be nice there were some mechanism to
> allow making variables global to a module and the kernel, but guaranteed
> (within reason) unique at the kernel level.
Victor /Steve --
Thanks for taking the time to reply to my email. I would like to
elaborate on Steve's clarifications...
Data Access Issues:
Our user's requirements are simple: they want read/write access to any
local or global static parameter in any simulation, at any time;
without having to define up-front what parameters they wish to
interface with, and without the target process (user's simulation)
having any notion of the fact that access to its data space is being
made externally.
The folks writing the simulation or control s/w like this because they
can focus on their task at hand, without having to be concerned about
"how to display or interface with the data", and "how to move data
in/out of various VME interfaces." It's all done for them, outside of
their application.
Namespace Issues:
We receive simulations and control code from many different groups.
These simulations can be hand coded Fortran, Fortran generated by
picture compilers, or hand coded C. It is a practical impossibility
to enforce any sort of parameter naming conventions to prevent name
collisions -- every group has their own naming standards. As Steve
had noted, a very real example is where we have real-time engine model
executable "engine", and make and run two copies of "engine"
concurrently.
cp engine left_engine
cp engine right_engine
In each engine simulation, there is a parameter p2 (inlet pressure).
We need (and currently have on a Concurrent platform) a mechanism
whereby we specifically address left_engine::p2 or right_engine::p2 .
Each of these engine models would have a shared memory area defined
with an airframe model and share, for example, a parameter called "alt".
Therefore we have three valid ways to reference what turns out to be a
single data object -- left_engine::alt, right_engine::alt, or
airframe::alt. The user interface s/w must recognize that "alt" is
one object, and not three.
I need a technique to "walk the executables" and extract user defined
parameters and parameter attributes, so I can present to the user
interface on startup, and concatenated, sorted-by-name symboltable of
all the parameters in all of the simulations to be run. Having a
sorted list makes things like parameter name completion and resolving
parameter unqiueness (are multiple parameters of the same name one or
more objects) easier. Thank you for the pointer to objdump -- with
enough options enabled, it appears we might be able to parse this to
generate a symboltable with all the info we need.
--
Dean W. Anneser
Software Engineering Fellow
Real-Time Test Systems
Pratt & Whitney Aircraft
400 Main St., m.s. 161-05
East Hartford, CT 06108
email: [EMAIL PROTECTED]
phone: 860.565.9372 fax: 860.557.3482
"One test result is worth one thousand expert opinions" - Wernher von Braun
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
