Re: Re[2]: [rtl] Re: c++ and rtl / posix_types.h
OP = PTHREAD_MUTEX_INITIALIZER;
OP rtl-3.0preX ??
i dont't think that rtl has influence on the stl? why should rtl
define a macro which is used only by the c++ stl?
The RTL posix interface I guess. As I remember the STL of libstdc++/gcc-2.95.2
isn't thread save and I wonder to find the above statements. Maybee only some
container are thread save.
The problem relays to:
# grep PTHREAD_MUTEX_INITIALIZER /usr/include/rtlinux/*
[...]
/usr/include/rtlinux/rtl_mutex.h:#define PTHREAD_MUTEX_INITIALIZER { 0,0,1,
SPIN_LOCK_UNLOCKED, PTHREAD_MUTEX_DEFAULT, RTL_WAIT_INITIALIZER, PTHREAD_PRIO_NONE }
I've no idea wher the include come from. It occours only by mixing kernel and
stl includes using
g++ -I/usr/include/linux @RTL_INC@
OP rtti needs typeinfo's which are compiler spezific as I assume.
OP You can use an overlaoded int type() whih returns an unique id of each class.
OP Than you can compare a-type() == b-type(). dynamic_cast throws as well - here
does it? i thought that it will return a null pointer if there is no
cast possible ...
I agree, but Stroustrup "The Std C++ Language" De/4.Ed pg 410: bad_cast throws
by dynamic_cast, or Chapter 15.4.1. Dynamic cast of references. Summary:
bad_cast will only be thrown on wrong arguments.
OP Only of interest ist __do_global_dtors_aux __do_global_ctors_aux for
OP globals imo. No idea about the rest like _register_frame_info yet.
do you link against the stdlibs or against nothing at all (means no
startup code)?
No startup code, I've need it not yet. At moment I write a small libkcpp for me
(there is only strerror, perror, new/delete und a errno class- which will be
replaced by a normal int maybee later). The only lib I link is the libm.a
OP but when i use c-style casts like the following:
SomeDerivedClass* pDC = new SomeDerivedClass;
void* pv = (void*) (pDC);
SomeBaseClass* pBC = (SomeBaseClass*) pv;
same for downcasts:
SomeBaseClass *pBC; // assuming that pBC stores a
// link to some derived class of
// SomeBaseClass!
...
void* pv = (void*) pBC;
(SomeDerivedClass*) (pBC)-DoSomething();
this perfectly works even with the -fno-rtti flag set ...
OP C-cast ... you know what you do - they are not type safe, so if you cast wrong
OP and use it, you can reboot (maybee).
probably it will reboot the machine by itself |*7 ... but i have got
some experience with rebooting and locking up my system now ... ;-)
Me too 8)
Olaf
-- [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/
Re: [rtl] RTL: Lost 2 Jiffies ---
Hi Michael, On Thu, Dec 07, 2000 at 07:35:42PM +0300, Michael Barabanov wrote: "lost NNN jiffies" is some old debugging output. You can comment the printf out in rtl_time.c. Even better, upgrade to 3.0pre9 on 2.2.17. Really only an old debugging output???!! After getting messages about, say, thousands of lost jiffies, I noticed that Linux clock were several minutes late. This is about kernel 2.2.14-RTL2.3. Regards, pa -- .. Pavel Andris | tel: +421 7 5941 2167 Institute of Control Theory and Robotics | fax: +421 7 5477 6045 Slovak Academy of Sciences | Dubravska cesta 9 | e-mail: [EMAIL PROTECTED] SK - 842 37 Bratislava | Slovakia | .. "The hardest thing is to take something people don't need and make it part of their lives." Sheila Hewett, vice-president for marketing and advertising .. -- [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/
Re: [rtl] RTL: Lost 2 Jiffies ---
On Thu, Dec 07, 2000 at 07:35:42PM +0300, Michael Barabanov wrote: "lost NNN jiffies" is some old debugging output. You can comment the printf out in rtl_time.c. Even better, upgrade to 3.0pre9 on 2.2.17. Really only an old debugging output???!! After getting messages about, say, thousands of lost jiffies, I noticed that Linux clock were several minutes late. This is about kernel 2.2.14-RTL2.3. Yes. I'm not sure if it's a bug or a feature. Michael. -- [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/
RE: [rtl] RE: Problems with Examples in RTLinux V3.0-pre9
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/
Re: [rtl] graphics?
Fri, 08 Dec 2000 Bill Simpson wrote: I went through the mailing list archive and I saw one recent thread on this. The info I needed wasn't really there. I am doing vision research where I present a visual display (drifting grating embedded in Gaussian white noise) and get a response (button press) from a human observer. The timing is important: for the graphics I would like to present at some frame rate (e.g. 100 Hz) and know that is No problem - use fbdev and hack a suitable modeline. the true value with no frames displayed twice or skipped; for the There is an ioctl for that, and you should be able to get 100% reliability using the Linux/lowlatency patch for user space SCHED_FIFO RT - we're using it for critical audio stuff relying on sub ms worst case latency, so video at 100 Hz should be totally safe. OTOH, if you're hacking around in kernel space anyway, you could just hook the retrace sync code from the fbdev driver into your RTL/RTAI code in some way - how depends on what video card you're using. (Some cards don't have a retrace IRQ, so you need to do some tricks unless you're going to poll. The retrace is usually polled by looking at a bit that's only set during the actual retrace, so polling is no fun...) response, I want ms resolution or better. You *could* probably get away with Linux/lowlatency for that as well, but RTL/RTAI gives you lots of headroom to guarantee that every measured result is really better than one ms in accuracy. (Better stay on the safe side when you *can* - it's more problematic when coding for normal workstations.) I would like to get the response via a telegraph key hooked up to the parallel port (debounced in software). Why? A telegraph key usually has one "down" switch and one "up" switch - just hook a flip-flop onto those, and you should be fine. (Of course, you could do that in software as well, provided you connect both switches - perhaps that's what you had in mind?) I think using rtlinux for the response would be pretty trivial. But the graphics? I am currently using MSDOS with djgpp/Allegro for making my displays. I have no worries about the graphics on this platform. But I do have worries about the response collection. I am wondering if rtlinux would be a solution. (Otherwise I have to read a lot more about disabling interrupts under DOS so I can rely on the timing). The big snag is the graphics. Certainly X would not be the way to go. Probably not, at least not if you also need to update the screen at specific frames. (You can't guarantee that with X, as you can't get it to do RT properly, even on lowlatency kernels - it's a design problem of X.) Does anyone know how to go about doing double-buffered realtime animation under rtlinux? I think you should be able to get away with user space + lowlatency for the animation. However, do note that there is no system RAM-VRAM DMA transfer support in any Linux graphics architecture, and acessing VRAM directly with the CPU is painfully slow, even with the hottest AGP cards. We have discussed this on the SDL list, tried various methods on different hardware and different driver architectures and so on, but it's just impossible to get anywhere near the transfer rate of the video card bus using the CPU. It has been the law of game programming for ages never to read VRAM, but now it seems that you should never write it either... Busmaster DMA is the only way. Now, if you're dealing with 320x240 256 color modes or something like that, this is no issue, but you hit the wall before you get to 640x480 16 bit color on the average machine. I can *barely* handle 640x480 24 bit color on my P-III 933 w/ Matrox G400 MAX, and that's about as fast as it gets with consumer video cards... I've been thinking about hacking sysRAM-VRAM DMA into some drivers, but I don't have the time, and I don't even know if it fits into the driver architectures without extending the APIs. Besides, for what I'm doing now in the graphics field, hardware accelerated OpenGL on X is by far the best looking, most powerful and fastest method for average and better systems - logical, as that's what the cards and drivers are designed for. This seems to be the conclusion of anyone who really cares about performance, so consequently, no one seems to be going to hack the DMA support any time soon. Sorry. :-/ //David ..- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `-- http://www.linuxaudiodev.com/maia -' ..- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-- [EMAIL PROTECTED] -' -- [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
Re: [rtl] booting the kernel
Thu, 07 Dec 2000 Karim Yaghmour wrote: [...] Although, I must admit that the above idea might be usefull for whoever would like to use RTL or RTAI without using Linux at all. In that case, one could strip the kernel options to a bare minimum and use it only as a host for the RT parasite ... Hmm... Sounds interesting to me (coming from a guy who used to code directly to the hardware of the Amiga, of course :-), but I don't know if it's realy feasible to do it that way... How about just hacking a custom init, which does the things you mentioned, and put that on a ramdisk/romfs image or something? It might be possible to hack the imagi into the kernel image if desired, but I don't really see the point, as you can load a kernel + ramdisk image directly from the boot loader, and pass the ramdisk to the kernel when starting it. (No disk file systems required, that is.) Of course, you can move any amount of setup/application code into one or more modules that are inserted by the init replacement. //David ..- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `-- http://www.linuxaudiodev.com/maia -' ..- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-- [EMAIL PROTECTED] -' -- [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/
Re: [rtl] timer ints
Cort Dougan wrote: } I was just wondering if programming the timer in one-shot mode might cause the } normal system timer interrupt to be called at an unusual interval (thus } affecting the jiffie count, etc). Seems that the linux layer will get its fake } timer interrupt when (and only when) the one-shot fires. We make certain that the Linux timer is monotonically increasing. If you take a look at arch/i386/kernel/time.c you'll see changes to gettimeofday that cooperate with RTLinux. I looked. You patch do_gettimeoffset at runtime. So anybody who accesses the Linux timer via this interface will see the timer monotonically increasing. Ok. But I don't think it answers my question. For example, assume the linux timer interrupt fires 100 times a second (every 10msec). An RT task programs the one-shot timer to go off in 20 msec. The timer interrupt fires at the programmed time. The RT interrupt handler calls the kernel timer interrupt handler 10 msec later than normal. Normally, the linux timer interrupt updates the jiffie count (among other things). So we effectively lose a jiffie increment. I'm not sure what other side effects might occur. Is this untrue or does it just not matter? --Gordon -- [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/
Re: [rtl] RE: Problems with Examples in RTLinux V3.0-pre9
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.9372fax: 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/
Re: [rtl] timer ints
Are you seeing that happen? If so, you shouldn't. It won't happen on ppc/mips/alpha. We take into account the Linux task when setting the next tick. If we can give Linux its tick on-time without affecting RT tasks we do. In your example what should happens is linux gets its tick at 10ms from now, the RT task gets its tick 20ms from now and Linux gets its tick after the RT task has finished running. } I looked. You patch do_gettimeoffset at runtime. So anybody who accesses the Linux } timer via this interface will see the timer monotonically increasing. Ok. } } But I don't think it answers my question. } } For example, assume the linux timer interrupt fires 100 times a second (every } 10msec). An RT task programs the one-shot timer to go off in 20 msec. The timer } interrupt fires at the programmed time. The RT interrupt handler calls the kernel } timer interrupt handler 10 msec later than normal. Normally, the linux timer } interrupt updates the jiffie count (among other things). So we effectively lose a } jiffie increment. I'm not sure what other side effects might occur. } } Is this untrue or does it just not matter? -- [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/
