On Wed, Jan 14, 2037 at 03:30:16AM -0500, Dean W. Anneser wrote:
>
> > This would also be helpful for people who want to be able to run
> > multiple copies of the same RT task. At the recent RTLinux conference in
> > Orlando I ran into a guy who was running engine simulations. He wanted to
> > be able to run two copies of the same code at the same time and examine
> > variables in each. Obviously if they are global variables (and they are),
> > he will need some sort of namespace architecture to make this work. Has
> > anyone given this any thought?
I'm not sure what this means. Can you explain? It makes little
sense to me to have global variables that are not global.
> 1) run N number of user applications (simulations or control code
> written in C and/or Fortran) in real-time, at different rates
> (typically 5/10/20/50 msec), across multiple cpus (it would be nice if
Not a problem.
> Linux had a notion of real-time priorities, so the only component that
> would have to run as a kernel module would be the frequency based
> scheduler)
Use rtlinux_sigaction although I think this is not the best solution in
most cases.
> 2) provide the user "on the fly" r/w access to any statically defined
> parameter in any real-time user application, on any cpu for purposes
> of display, access from within test scripts, or binding to i/o channels
gbd, XDB, ...
> 3) need to provide a comprehensive namespace management scheme,
> whereby multiple copies of a single executable (with different process
> names like "left_engine" and "right_engine") may be run, and the user
That's easy.
pthread_create(&p1,f ...)
pthread_create(&p2,f, ... )
> is able to distinguish whether objects of the same name are one shared
> object, or different objects
This I don't understand.
> 4) define/delete/modify i/o channel attributes and bindings to
> parameters in simulation space, at any time
We don't have an i/o channel abstraction so this is an application
problem.
>
> 5) have a system that is self configuring at boot time -- i.e. no i/o
> process code needs to change when more i/o boards are added/removed
Easily solved in applications - I don't see how this involves the OS at all.
> 6) scale from small applications - where the number of simulation
> parameters are in the thousands, and the i/o channel counts are in the
> hundreds; to large applications - where the the parameter count can be
> greater than 100,000 and i/o points are greater than 2000
Application - the OS has no problem.
>
> 7) provide a utility to walk the elf/dwarf user applications and
> extract parameter attributes of only the user defined static
> parameters, such as program, module, common (f77) or C struct,
> parameter name, parameter type, logical address, number of dimensions,
> upper/lower bounds of each dimension, etc...
gdb, nm, ...
>
> 8) allow users to change their real-time applications without ever
> having to change or re-link the user interface or i/o process
> applications
Sure. This is done all the time on RTLinux now.
>
>
> We are doing all of this now on systems provided by Concurrent
> Computer Corp (formally Harris Computer Systems).
>
> One question I would like to ask for starters: Short of looking at
> gdb source, how could I extract parameter attribute information from
> executables (to build a symboltable) -- I don't seen any mention of
> dwarf info as being available in RedHat 6.2 or 7.0. The "nm" utility
> does not provide enough info.
see objdump.
>
> --
> 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
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com www.rtlinux.com
-- [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/
