Victor / Dean,
I can't speak for Dean, but I can tell you what I think he is
looking for given our lunch together during the workshop. I can also tell
you what *I* would like to see.
> > > 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.
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.
For example, a system could be implemented such that all module
global symbols get registered to the kernel as <module>_name rather than
simply name. This namespace mechanism would allow data to be defined in a
module that is accessible to the entire kernel, but which would be distinct
from other modules variables of the same name. At that point, finding
particular variables (for whatever reason) is a trivial application of
tcl/perl/python/whatever to /proc/ksyms.
Such a mechanism would also be nice from a programming standpoint to
provide global symbols without risking them overlapping other modules
symbols. If we were writing all of our code in one huge file, we would
simply define all of our global data as static. Unfortunately, our code is
huge (to us at lest, several thousand lines) and we find that having
functions stored in distinct files vastly improves readability.
Such a segmentation, or namespace, mechanism would be desirable to
handle the cases that Dean (and I, for other reasons) encounter. If such a
mechanism existed, one could simply run two copies of the exact same RT code
simultaneously and they a) would not conflict and b) the global symbols
within each module would be available to the outside world.
Does this make more sense now?
Alternatively, I can mimic this type of behavior if there is some
mechanism in RTLinux or the kernel to allow me to register symbols to the
kernel.
> > 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.
But if you want determinism, you have to run everything as a kernel
module, don't you? Besides, there are advantages in terms of dealing with
the hardware and the globalness of data when using kernel code.
> gbd, XDB, ...
/proc/ksyms
> That's easy.
> pthread_create(&p1,f ...)
> pthread_create(&p2,f, ... )
Ummm... That isn't really what Dean wants to be able to do (as I
understand it). He wants to be able to do something like:
cp engine.o left_engine.o
cp engine.o right_engine.o
insmod left_engine.o
insmod right_engine.o
Then find the data for left_engine and right_engine from his I/O
task somehow. He also needs to protect the global data within the
individual simulations to prevent overwriting each other.
> > is able to distinguish whether objects of the same name are
> one shared
> > object, or different objects
>
> This I don't understand.
In other words, is something a kernel level shared object or a
module level shared object. Simulation time for example, would be a global
level shared object. When any module refers to simulation time they would
all want the same shared object. Thrust output, on the other hand, would be
a module level shared object. The thrust level for left_engine might be
different than the thrust level for right_engine. They both need to be
accessed from other routines, but they need some sort of name space
protection from each other.
> see objdump.
And /proc/ksyms will give you the addresses of the various kernel
symbols.
Regards,
Steve
-- [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/
