Re: [rtl] RTAI and RTLinux
Karim, Of course, I can not prove it, but at the time I put in the tracer support, I was not aware of LTT's existence. I was trying to track down a timing problem with in beta15, so I wrote this trace program that did help to solve the problem. Apart of "similar code" (note, I never saw any of LTT's until your message about do_gettimeofday), these two tools, as I see now, solve different purposes. Michael. Karim Yaghmour ([EMAIL PROTECTED]) wrote: Few were convinced, but I thought that Micheal's code was amazing and that the idea was great, even though it seemed to be deja-vu. When I started working on the Linux Trace Toolkit, bringing LTT support for RTL was my ultimate dream. I thought that this would surely make it very clear that Linux could be used as an embedded/RT OS. Having been very busy developing LTT and attending every day obligations, I only got time to check LTT support for RTL in autumn '99, some time __after__ the first release. I went over to www.rtlinux.org and downloaded a copy of the latest RTL. To my dreadful surprise, someone had tried to instrument RTL. Not only that, but the code used to instrument RTL was severely familiar. No mention of my name could be found anywhere and no mention of the addition was made to any file. I only knew because I read the source code. This happened somewhere between beta 15 and beta 16 in September '99, clearly two months after LTT's first release. I was very disappointed by this. I thought to myself that if you take an idea from someone it would be the least of things to drop him an e-mail and tell him that you really liked what he did and that you might build on that. Least of things, you might ask him about what advice he might have about the problems he encountered so that you wouldn't fall in the same traps. You could even inquire about his desire to help out. It seems all of this was too much to ask. Therefore, there is no surprise that I find it very credible when someone states that they've been copied by RTL and that they received no credit for their work. In Paolo's HAL case, this was blatant. There is no surprise either when I state that I am firmly against including any RTL code into the Linux source code. You've misbehaved once, that's OK. RTAI will probably live on. Allowing such a mistake with Linux would be very harmfull to the open-source movement. This is not the first time I post my views on your methods and motivations. On the last occasion, I was very flamy (accusing you of M$ behavior). Ensued a private discussion were I agreed to publicly apologize for my flaming so that we might continue the discussion at a more productive level. As I said above, the discussion didn't lead anywhere and I eventually abandoned it. This time though, my previous posting did not warrant any of your flak. We probably will never agree on any of the things I'm pointing out and that's OK with me. One thing though, do refrain from spreading FUD about things you do not understand. If not for yourself, then for the negative image you are spreading about the open-source community. Sincerely Karim Yaghmour -- [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] RTAI and RTLinux
On Fri, 8 Sep 2000, Karim Yaghmour wrote: I'm sorry to say this, but you got this all upside down. Paolo and all the other RTAI developers, for that matter, have been very keen to recognize the contributions of RTL. The contrary, though, is not true. RTL developers have strived very hard to demonstrate that RTAI "features" are, at best, trivial to implement and, at worst, technically deficient. Now, these guys can go on believing what they wish, and so can you, but from where I stand, I don't see any reason why anyone would choose RTL over RTAI, because of the feature-rich nature of RTAI. By this I mean that there are things possible in RTAI which aren't possible in RTL, least of them enabling a normal Linux process to become hard-RT, which, for me at least, deserves a Nobel by itself. Well, let me try (as a _neutral_ observer) to make this clear: there is a trade-off between (i) adding features that people (think they) need, and (ii) offering a system that is and remains as predictable as possible. The former is the Microsoft/RTAI/... way, the latter is Linux(kernel)/RTL/... way. ( Don't flame me for being over-simplistic :-) ) There is a room for both parts of this spectrum. I applaud the wisdom of the RTAI guys for having recognized that RTL was a dead-end ??Mmmm. Strong claim you make here :-) -- [EMAIL PROTECTED] (Ph.D.)Fax: +32-(0)16-32 29 87 Dept. Mechanical Eng., Div. PMA, Katholieke Universiteit Leuven, Belgium Real Time and Embedded HOWTO: http://www.mech.kuleuven.ac.be/~bruyninc/rthowto -- [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] RTAI and RTLinux
Hello Herman, Don't worry, I'm not about to flame you :) I do disagree with your appreciation of the situation, but I do respect your point of view. I don't think there can be a comparison between MS and RTAI; their goals, dynamics and finalities are completely different. As for my "dead-end" claim, you are right, it is pretty strong, but then again, it does reflect my opinion about RTL in its current state. I don't pretend to be __neutral__ here, though I do think that there are misconceptions about how RTAI came to be, where it's going and how it's going there. By the way, thanks for your HOWTO, I think it's a great starting point for anyone wanting to do RT using open-source. Best regards Karim Herman Bruyninckx wrote: Well, let me try (as a _neutral_ observer) to make this clear: there is a trade-off between (i) adding features that people (think they) need, and (ii) offering a system that is and remains as predictable as possible. The former is the Microsoft/RTAI/... way, the latter is Linux(kernel)/RTL/... way. ( Don't flame me for being over-simplistic :-) ) There is a room for both parts of this spectrum. I applaud the wisdom of the RTAI guys for having recognized that RTL was a dead-end ??Mmmm. Strong claim you make here :-) -- [EMAIL PROTECTED] (Ph.D.)Fax: +32-(0)16-32 29 87 Dept. Mechanical Eng., Div. PMA, Katholieke Universiteit Leuven, Belgium Real Time and Embedded HOWTO: http://www.mech.kuleuven.ac.be/~bruyninc/rthowto -- [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/ -- === Karim Yaghmour [EMAIL PROTECTED] Operating System Consultant (Linux kernel, real-time and distributed systems) === -- [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] RTAI and RTLinux
Hmm... Very interesting remarks :) [EMAIL PROTECTED] wrote: Karim was also astounded to find that IBM had a remarkably similar product, and he apparently never looked at Oleg Subbotin's MS thesis in which he traced RTLinux threads or Ismail Rippoli's RTLinux graphing tool (http://bernia.disca.upv.es/~iripoll/), or read my 1996 paper on tracing Linux file system behavior or ... First I wasn't astounded by IBM's stuff, I've known for a long time that AIX has had a tracing facility and so does SUN. This is nothing new to me, FYI. As for Oleg Subbotin's and Ismail Rippoli's stuff, thank you for the pointer, but then again I see no relation between this and my remarks except trying to discredit me. As I've told you before, this is called sophism in philosphy 101. (By the way I'd really like to read Oleg's stuff, but I can't seem to find it, anyone have a valid pointer ... thanks.) I might also point out that LTT is not a product, it is a project. There is a big difference between those two concepts. A product is something you can sell, a project is something you contribute to. This actually goes to show that my analysis is right, you view open- source projects as something you can market, not something you can provide expertise for. This is the same mind-set most Linux vendors have. There is nothing wrong with it per-se, but there is something wrong in your misleading the community to believe that you are truly of open-source spirit. Shockingly, many of these projects use the same method of spooling data in a buffer and having a daemon empty the data -- in fact, somehow Linux has been doing this for syslog for many years. That has never been my claim ... Please do go to LTT's web site and go get the paper I presented at the last annual Usenix conference as part of the main refreed track on LTT. In it, you would see that I do not claim to have invented the data collection methods I use, rather I emphasize on the fact that this data had not been used in this manor before. I have read a couple of your papers, I think you ought to read some of mine. Especially since said paper was presented as part of one of the most important computer- science conferences in the world. Next month, when someone else from Lineo invents local variables or the letter "a", we will undoubtedly see yet another one of these strange episodes. I guess, my advice wasn't heard. In any case, it should be clear to any reader that your statement is very harmfull to the open-source community's image. But then again, you don't really care about that community, you care about the possible revenus. So be it. Best regards Karim Yaghmour === Karim Yaghmour [EMAIL PROTECTED] Operating System Consultant (Linux kernel, real-time and distributed systems) === -- [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] RTAI and RTLinux
[EMAIL PROTECTED] wrote: Next month, when someone else from Lineo invents local variables or the letter "a", we will undoubtedly see yet another one of these strange episodes. Bitch How about we all lighten up a little. Regards, Stuart -- [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] RTAI and RTLinux
RTL", but what Paolo really says is "Clearly RTAI has reinvented the wheel as it was already in use with DOS, using APIs found elswhere, but not in RTL". I wish I had saved old emails from when Paolo's memory was actually keen and he admitted the contributions from RTLinux. It seems that a few things in life do have the power to erase our memories. Again, I apologize for this non-technical outburst. Maybe I was too naive to believe that the unification was possible and RT people could do the same that was done to Linux itself. After all, humans cannot overcome human nature. ;-) Hats on for all of us. ;-) gnd From: Karim Yaghmour [EMAIL PROTECTED] Subject: Re: [rtl] RTAI and RTLinux Date: Fri, 8 Sep 2000 07:03:34 -0400 I'm sorry to say this, but you got this all upside down. Paolo and all the other RTAI developers, for that matter, have been very keen to recognize the contributions of RTL. The contrary, though, is not true. RTL developers have strived very hard to demonstrate that RTAI "features" are, at best, trivial to implement and, at worst, technically deficient. Now, these guys can go on believing what they which, and so can you, but from where I stand, I don't see any reason why anyone would choose RTL over RTAI, because of the feature-rich nature of RTAI. By this I mean that there are things possible in RTAI which aren't possible in RTL, least of them enabling a normal Linux process to become hard-RT, which, for me at least, deserves a Nobel by itself. Actually some of the contributions of RTAI are so fundemental that it doesn't make sense to see those as "small contributions". In that sense, having to state the name of RTL as a mantra every time one writes new features for RTAI would be like having to chant a song in recognition to the glories of Donald Knuth every time you wrote an algorithm. Seriously, I applaud the wisdom of the RTAI guys for having recognized that RTL was a dead-end and having the guts to go against the wind, as you so well put it, to answer their true calling, technical excellence. Hats off for the RTAI guys! Karim - G. N. DeSouza - - [EMAIL PROTECTED]- -- http://rvl1.ecn.purdue.edu/~gnelson -- -- === Karim Yaghmour [EMAIL PROTECTED] Operating System Consultant (Linux kernel, real-time and distributed systems) === -- [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] RTAI and RTLinux
[EMAIL PROTECTED] wrote: As usual, I will not reply to a completely untechnical post on the newsgroup. However, I should point out that I admire the consistency with which Lineo beneficiaries repeat the advertising slogan and forget to point out that they have a financial incentive. Your answer to my public posting was outright unwarranted, unjustified and completely unacceptable. Even your base assumption is completely inaccurate and goes to show that you are very much unaware of the personalities of the people your are referring to and their motivations. For the public record, I think it ought to be known that I have my opinions and motivations which are not for sale even though I do offer my expertise commercially. I accepted to develop LTT support for RTAI under Lineo sponsorship because we agreed on the way the project should be done and on it's ultimate goal. This included making sure the resulting code was available for everyone in the best quality it could be. Lineo's initiative showed that they were inclined to fund open-source projects and share their expertise while respecting the open-source movement. My duty, as an open-source contributor, was to make sure that the project remained free. Having secured this, I see no reason why I shouldn't offer my expertise to participate in my project's development as I would do to participate in any other consulting activity that I usually do. Ergo, your assumption is wrong. There was financial __compensation__, but the incentive was that of an open-source enthusiast who wanted to add new features to a project he very much enjoys working on. As for your constant desire to point out that Lineo is contributing to RTAI, the community should be aware that you yourself are very much a commercial entity making money around RTL. Your patent __and__ the fact that most RTL code is copyrighted to FSMLabs are the proof of this. I had privately raised questions about those two items, but you never answered fully. You even went to the point of ridiculing me and saying that I didn't have any weight to discuss such things since I hadn't contributed anything to the open-source movement. You were forced to drop that line when I pointed out that I was the author of the Linux Trace Toolkit, but you still weren't very interested in clarifying things. Today, I must say that only one of the four questions I asked remain unanswered. That is, I still have no explanation as to why you are now the lead RTL developer and not M. Barbanov. I also inquired about the reason of this switch, was it voluntary or "forced"? In a subquestion, I asked why Micheal's name wasn't on the patent. If nothing else, this really intrigues me. Isn't he the first to have implemented RTL? Doesn't he deserve to be on the patent. In any case, we might never know, but going back to the patent and copyright thing, I think some things should be made very clear to the open-source community. And in my opinion, these two items can't be viewed separately. Having copyrighted RTL code to FSMLabs, FSMLabs, as a commercial entity, and Victor Yodaiken, as the CEO, can decide to commercially sell the source code to any private entity. How is this? Well, they own the copyright (look at the file headers). This means they can choose to distribute this in as many licensees as they which. Why? Simple, RTL is under GPL and if any commercial entity wanted to patch their OS with it, they'd suffer GPL contamination. Of course, this isn't definitive and the GPL hasn't been tested enough to disprove this possibility, but it would be fair to say that no commercial entity would take such a risk. But then why couldn't they simply do their own simili-RTL for their own OS? Well, they can't ... Victor owns the patent to that idea. Case closed. This might be clear for you Victor, but very few people in the open-source community see this and I think that a lot of people in the community would be outraged by this. Frankly, I think your are doing a great disservice to the community by behaving so recklessly towards the freedoms and obligations the GPL embodies. Lineo is clearly a commercial entity, they've never tried to hide this. You, on the other hand, are dancing on both feet between the open-source world and the commercial world, trying to make everyone believe that you're the only reference and that all the others are bad guys. In the open-source world, you claim to be the RTL benevolent dictator leading the way for bringing real-time to Linux and in the commercial world, you trumpet your company's "possessions" (RTL) and "powers" (the patent). Acting as an open-source leader, you take the liberty to attack a commercial company on the grounds that they are coercing developers into adopting RTAI while you are yourself a commercial entity who's whole existence and financial future is based on the success of RTL. Don't get me wrong, I didn't jump into the RTAI bandwagon out of the blue for no reason. Actually, I have
Re: [rtl] RTAI and RTLinux
On Thu, Sep 07, 2000 at 06:58:48AM +0200, Paolo Mantegazza wrote: [EMAIL PROTECTED] wrote: - . do we want to bet how long will it take to see a real time memory manager in RTL? There is no such thing as a dynamic real time memory manager. It's been some years since RTL has been available and we have many times had this silly discussion. The code for a simple version is trivial. Step 1: write some module code: In Linux init: ask for a soft RTL interrupt install a handler handler: read from request queue (could be a fifo) v = kmalloc( requested.space) *requested.result = v; pthread_wakeup_np(requested.thread); Step 2: write some RTL thread code. In rtl periodic thread; queue request. pthread_kill(pthread_linux(),kmalloc_irq); while( !request.result) pthread_wait_np(); Step3 : receive Nobel Prize. -- - 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/
Re: [rtl] RTAI and RTLinux
[EMAIL PROTECTED] wrote: On Thu, Sep 07, 2000 at 06:58:48AM +0200, Paolo Mantegazza wrote: [EMAIL PROTECTED] wrote: - . do we want to bet how long will it take to see a real time memory manager in RTL? There is no such thing as a dynamic real time memory manager. In fact I was just betting there will be one in the future :-). It's been some years since RTL has been available and we have many times had this silly discussion. The code for a simple version is trivial. Step 1: write some module code: In Linux init: ask for a soft RTL interrupt install a handler handler: read from request queue (could be a fifo) v = kmalloc( requested.space) *requested.result = v; pthread_wakeup_np(requested.thread); Step 2: write some RTL thread code. In rtl periodic thread; queue request. pthread_kill(pthread_linux(),kmalloc_irq); while( !request.result) pthread_wait_np(); Step3 : receive Nobel Prize. Since you like joking, I feel invited to go on ;-). Once more RTAI has no problem in doing that. RTAI fifos were already based on the use of its srqs when RTL was still patching the kernel to protect Linux tasks queues to be used with fifos in real time. In fact we (I, Steve and Pierre) discussed a similar solution before they implemented theirs ideas, but they denied its usefulness because was too much not deterministic, and they needed a truly fast minimal latency dynamic memory manager for their applications. So I was just pleased to have them add, and copyright, what I think is an usefull service for RTAI. Recall that I support the idea that a reach toolbox of mechanisms enhances user politics implementation freedom. Note also that RTAI calls what you name soft interrupts as system requests and they are structured with two handlers, one for user and one for kernel space. So it could be simple for a supervisory user space process, acting as a user interface, to pre allocate memory in kernel space for a new stack of a to be launched rt_task, or a larger one onto which save an already in use stack, so that a real time task could be dynamically resumed on a larger stack if needed, and many other fancy things. However all those things were believed not satisfactory, because tightened to Linux, and thus miles away from a minimal latency memory management. Nonetheless RTAI exploits the idea of using an srq in relation to memory managment, but just for kfreeing kmalloced memory when tasks are deleted. Clearly I applied to have a Nobel Prize. They already promised me one when the euro will be worth .001 dollars, and it seems it will happen quite soon. Ciao, Paolo. -- [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] RTAI and RTLinux
On Thu, Sep 07, 2000 at 03:50:17PM -0400, Tony Mouawad wrote:
I'm new to the RT world, but I'm curious... what significant challenges are
there when working with dynamic memory and real time? Just the term
"dynamic" gives us an indication that the mechanism would be
undeterministic... but what's worse case here? Why is it impossible to have
a "real time" dynamic memory manager? At worst, nothing is "real time",
To illustrate:
Thread:
loop:
if(get_a_buffer){
wait for an interrupt
copy data to buffer
dispatch buffer
}
else try_to_recover();
goto loop
Case 1: "get_a_buffer" may sometimes stall the thread
Result: program may stop at any momement.
Case 2: "get_a_buffer" allocates from a pool that is used by other threads and
just returns failure if there is no free buffer.
Result: program may fail at any input load depending on who else
uses the buffer pool.
Case 3: "get_a_buffer" allocates data from a static pool used only by this thread
and freed by the destination.
Result: thread can handle sizeof(buffer_pool)/sizeof(buffer) outstanding
requests. If a dispatched buffer is known to be freed within K time
units and interrupts take less than K time units plus
jitter+interrupt dispatch
+ copy time ... then there will never be a out of buffer failure.
So it's a subtle difference with big implications. In the case of Steve
Papacharalambous
module, things are more complex since he essentially manages a cache of memory and
replenishes this cache from Linux when the system is not busy. I think this is an
especially dangerous method since it makes out-of-memory failures harder to find by
testing. I'm in favor of:
crank the input device up to full speed and see what happens
but to test our program above using a caching memory allocator we need
crank the input device up to full speed, make Linux busy and
also do something to exercise all other modules that may use
the memory allocator so that they use max memory.
All that said and done, however, since implementing a cache memory pool is the work of
maybe
an hour, at best, this discussion is more about philosophy of design than about
anything concrete.
-- [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] RTAI and RTLinux
Date: Thu, 07 Sep 2000 14:23:55 +0200 From: Paolo Mantegazza [EMAIL PROTECTED] Subject: Re: [rtl] RTAI and RTLinux ... Once more RTAI has no problem in doing that. RTAI fifos were already based on the use of its srqs when RTL was still patching the kernel to protect Linux tasks queues to be used with fifos in real time. Am I wrong, or RTAI was based on RTL? This sounds like someone here is spitting in the wind. (Or, assuming it will make as much sense in english as it does in portuguese: one is spitting on the plate that oneself's eating from) ... So I was just pleased to have them add, and copyright, what I think is an usefull service for RTAI. ... "COPYRIGHT"??!! What kind of copyright? A GPL, I presume. But then again, copyright what??!! These things (ideas) are older than the bible -- or maybe even older than the first draft of the book of Genesis. ;-) Now I remember why I unsubscribe this list a year ago. Isn't that about time we had one single RT-LINUX, or whatever you want to call it? A year went by, and there are still threads like this one. Titled "RTAI and RTLinux" or "RTAI vs. RTLinux". How about getting a Nobel Prize, a lot of people in this list will get a Nobel Prize, alright. But first, the Nobel Foundation have to start awarding people for re-inventing the wheel. gnd - G. N. DeSouza - - [EMAIL PROTECTED]- -- http://rvl1.ecn.purdue.edu/~gnelson -- -- [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] RTAI and RTLinux
[EMAIL PROTECTED] wrote: On Tue, Sep 05, 2000 at 10:18:25AM -0700, David Schleef wrote: I don't think that "running out of memory" and "running out of CPU time" are fundamentally different things. It's just that with a memory allocator, you are notified of a lack of resources and can do something graceful instead of locking the machine. Sure. But I think there is a significant difference between: 1. At startup time, allocate N buffers for a pool for a particular purpose and have an allocate/free routine. and 2. Maintain a general purpose buffer pool with unknown size and many users. Hi Victor, I think the big misunderstanding is that the pool of memory is only available to real-time tasks. This means that a design can be made based upon things you can control, whereas in a soft real-time system, you are subject to the interference of things you cannot control (such as a disk surge from an active web server for instance). In the same way you have to take care not to exceed the maximum frame time allocated per task (CPU budget), you must also take care that you understand the limitations of the memory allocator (e.g don't ask for too much too quickly). Remember also that people seem to be thinking here in terms of a task meeting its deadline with high precision every time. That is fine for the highest priority task, but if you have many task, the lower priority tasks will have significant jitter. Again, only a problem if you don't take this into account in the design. Regards, Stuart -- [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] RTAI and RTLinux
Tue, 05 Sep 2000 [EMAIL PROTECTED] wrote: On Tue, Sep 05, 2000 at 10:18:25AM -0700, David Schleef wrote: I don't think that "running out of memory" and "running out of CPU time" are fundamentally different things. It's just that with a memory allocator, you are notified of a lack of resources and can do something graceful instead of locking the machine. Sure. But I think there is a significant difference between: 1. At startup time, allocate N buffers for a pool for a particular purpose and have an allocate/free routine. and 2. Maintain a general purpose buffer pool with unknown size and many users. Exactly, and it's really all about defining what can happen in a system under any likely or unlikely conditions. For 1. this is (usually) very easy, while you have to take tons of code interacting in complex ways in account to figure out how 2. will behave. David Olofson Programmer Reologica Instruments AB [EMAIL PROTECTED] ..- M u C o S . .- David Olofson --. | A Free/Open Multimedia | | Audio Hacker | | Plugin and Integration Standard | |Linux Advocate| ` http://www.linuxdj.com/mucos -' | Open Source Advocate | ..- A u d i a l i t y . |Singer| | Rock Solid Low Latency Signal Processing | | Songwriter | `--- http://www.angelfire.com/or/audiality -' `- [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] RTAI and RTLinux
Tue, 05 Sep 2000 David Schleef wrote: On Tue, Sep 05, 2000 at 05:05:56PM +0200, David Olofson wrote: Tue, 05 Sep 2000 [EMAIL PROTECTED] wrote: Let's say I have N message buffers in a pool. What if there is no more free buffer? Then the design for your hard real time system was wrong :-) Or system reached its limits. Yep, and the only options are a) redesign and b) upgrading the hardware. It depends on your possibilities and intentions. What if amount of incoming data is unpredictable but you have to process at most as you can with a limited hardware? That's a kind of *soft* real time system, which is not really what RTL is intended for. (Although the input-"some kind of output" latency could have a hard RT requirement - but the memory allocation would still be soft RT.) You can't optimize a single API for both hard and soft RT, at least not without making it a major PITA to use if you want hard RT, so IMHO, it's a very good idea not to mix these two kinds of systems up when discussing APIs. I don't think that "running out of memory" and "running out of CPU time" are fundamentally different things. It's just that with a memory allocator, you are notified of a lack of resources and can do something graceful instead of locking the machine. Yes indeed; but still, if either of these things happen, you don't have a hard RT system. Hard RT systems shouldn't have to worry about missed deadlines OR running out of memory (or any other resources), as they have already failed if they ever get into that situation. Or; it's a good idea to handle every possible error condition nicely (within reasonable limits!) as that makes debugging a lot easier, and it *might* save a buggy hard RT system a few times, until the effect of the bug coincides with a critical situation. And, as hard RT actually isn't in real life, improving the statistics is a good thing. However, I believe *designing* around that philosophy will result in serious problems sooner or later. A general rule of all kinds of programming: Fix design problems as you find them - don't burry them in code. David Olofson Programmer Reologica Instruments AB [EMAIL PROTECTED] ..- M u C o S . .- David Olofson --. | A Free/Open Multimedia | | Audio Hacker | | Plugin and Integration Standard | |Linux Advocate| ` http://www.linuxdj.com/mucos -' | Open Source Advocate | ..- A u d i a l i t y . |Singer| | Rock Solid Low Latency Signal Processing | | Songwriter | `--- http://www.angelfire.com/or/audiality -' `- [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] RTAI and RTLinux
On Wed, Sep 06, 2000 at 07:49:45AM +0100, Stuart Hughes wrote: I think the big misunderstanding is that the pool of memory is only available to real-time tasks. This means that a design can be made I agree with David Olofson here. -- - 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/
Re: [rtl] RTAI and RTLinux
Wed, 06 Sep 2000 Stuart Hughes wrote: [EMAIL PROTECTED] wrote: On Tue, Sep 05, 2000 at 10:18:25AM -0700, David Schleef wrote: I don't think that "running out of memory" and "running out of CPU time" are fundamentally different things. It's just that with a memory allocator, you are notified of a lack of resources and can do something graceful instead of locking the machine. Sure. But I think there is a significant difference between: 1. At startup time, allocate N buffers for a pool for a particular purpose and have an allocate/free routine. and 2. Maintain a general purpose buffer pool with unknown size and many users. Hi Victor, I think the big misunderstanding is that the pool of memory is only available to real-time tasks. Well, I might have lost track somewhere, but if the pool is only available to RT tasks, and statically allocated, there is no resource balancing between RT and non RT - which would be one useful advantage if this could work. However, it cannot work, if the RT allocations are supposed to be hard RT. Anyway, even if the pool and allocator is RTL only, designing applications this way makes it a lot harder to figure out how much memory you really need not to ever run out of it. Then again, memory is rather cheap these days, and you can usually have lots of it if you need, even in embeded systems, so it might pay off if it simplifies the rest of the design to great extent... Remember also that people seem to be thinking here in terms of a task meeting its deadline with high precision every time. That is fine for the highest priority task, but if you have many task, the lower priority tasks will have significant jitter. Again, only a problem if you don't take this into account in the design. Indeed, but the lower prio tasks (if any at all!) usually don't deal with that critical stuff - having the output data ready before the deadline is all that matters, since the actual timing is managed by the highest prio task, or in hardware. That is, jitter is not a big and complex problem in a correct design. Running out of memory OTOH, being forced to wait until some other task releases some, may well stall your task long enough to miss the deadline several times over. And if you have more than two or three tasks doing dynamic allocation, there's no realistic way of defining the worst case latency. David Olofson Programmer Reologica Instruments AB [EMAIL PROTECTED] ..- M u C o S . .- David Olofson --. | A Free/Open Multimedia | | Audio Hacker | | Plugin and Integration Standard | |Linux Advocate| ` http://www.linuxdj.com/mucos -' | Open Source Advocate | ..- A u d i a l i t y . |Singer| | Rock Solid Low Latency Signal Processing | | Songwriter | `--- http://www.angelfire.com/or/audiality -' `- [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] RTAI and RTLinux
Even though some of your points are quite interesting, to me the real question is whether the RT subsystem should decide a policy or provide a capability. From what I see, some think that rt-mem-management is a bad policy, whereas others think that rt-mem-management is a very interesting capability. Given the applications of RT systems and the underlying responsibilities of their designers, both legal and moral, the system designers better know what they are doing. This we will surely agree on. In that sense, there should be very strict policies regarding possible behavior when designing and RT-based system. That said, I'm not sure that limiting the capabilities of an RT system designer will help make him/her a responsible human-being. Actually, it is likely that if he/she feels limited, he/she will attempt to bypass/hack the current capabilities to obtain the results he/she desires. In fact, chances are that by providing a capability that has been designed and implemented by pros will make RTL-systems safer since even though the designer might be inexperienced/ irresponsible, the system will know better. To sum up, I assume we all are mature adults. Nobody needs to be told how he/she should or should not design/program. Given the lead of an RTL-based system that has rt-mem-management capability, I would very likely set a policy by which rt-mem-management usage would require __Pontifical__ approval, but I'd nonetheless appreciate the fact that it's available just in case ... My 2 cents David Olofson wrote: Well, I might have lost track somewhere, but if the pool is only available to RT tasks, and statically allocated, there is no resource balancing between RT and non RT - which would be one useful advantage if this could work. However, it cannot work, if the RT allocations are supposed to be hard RT. Anyway, even if the pool and allocator is RTL only, designing applications this way makes it a lot harder to figure out how much memory you really need not to ever run out of it. Then again, memory is rather cheap these days, and you can usually have lots of it if you need, even in embeded systems, so it might pay off if it simplifies the rest of the design to great extent... Remember also that people seem to be thinking here in terms of a task meeting its deadline with high precision every time. That is fine for the highest priority task, but if you have many task, the lower priority tasks will have significant jitter. Again, only a problem if you don't take this into account in the design. Indeed, but the lower prio tasks (if any at all!) usually don't deal with that critical stuff - having the output data ready before the deadline is all that matters, since the actual timing is managed by the highest prio task, or in hardware. That is, jitter is not a big and complex problem in a correct design. Running out of memory OTOH, being forced to wait until some other task releases some, may well stall your task long enough to miss the deadline several times over. And if you have more than two or three tasks doing dynamic allocation, there's no realistic way of defining the worst case latency. David Olofson Programmer Reologica Instruments AB [EMAIL PROTECTED] ..- M u C o S . .- David Olofson --. | A Free/Open Multimedia | | Audio Hacker | | Plugin and Integration Standard | |Linux Advocate| ` http://www.linuxdj.com/mucos -' | Open Source Advocate | ..- A u d i a l i t y . |Singer| | Rock Solid Low Latency Signal Processing | | Songwriter | `--- http://www.angelfire.com/or/audiality -' `- [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/ -- === Karim Yaghmour [EMAIL PROTECTED] Operating System Consultant (Linux kernel, real-time and distributed systems) === -- [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] RTAI and RTLinux
Tue, 05 Sep 2000 [EMAIL PROTECTED] wrote: Let's say I have N message buffers in a pool. What if there is no more free buffer? Then the design for your hard real time system was wrong :-) Or system reached its limits. Yep, and the only options are a) redesign and b) upgrading the hardware. It depends on your possibilities and intentions. What if amount of incoming data is unpredictable but you have to process at most as you can with a limited hardware? That's a kind of *soft* real time system, which is not really what RTL is intended for. (Although the input-"some kind of output" latency could have a hard RT requirement - but the memory allocation would still be soft RT.) You can't optimize a single API for both hard and soft RT, at least not without making it a major PITA to use if you want hard RT, so IMHO, it's a very good idea not to mix these two kinds of systems up when discussing APIs. (The general problem of soft RT capable systems is that the dynamic allocation and other stuff they provide makes it virtually impossible to write hard RT applications, even if the kernel theoretically could provide the required timing guarantees.) Then one can choice a stragegy of survival: throw away unprocessable data and do some clever. (Plan B: crash and reboot. ;-) Well, with some systems, plan B and the "stragegy of survival" both actually give the same result as plan C: miss a deadline and wreck some very expensive machinery... This basically applies to all control systems dealing with powerful and/or sensitive machines, and particularly in situations where people may get hurt or killed if the machines freak out. I'd say that a thoroughly tested RTL solution could be appropriate at least for the less critical systems in this range, but that doesn't go for *any* kind of soft RT system - and anything that shares resources with non RT tasks in a similar way to a shared memory pool is actually a soft RT system. David Olofson Programmer Reologica Instruments AB [EMAIL PROTECTED] ..- M u C o S . .- David Olofson --. | A Free/Open Multimedia | | Audio Hacker | | Plugin and Integration Standard | |Linux Advocate| ` http://www.linuxdj.com/mucos -' | Open Source Advocate | ..- A u d i a l i t y . |Singer| | Rock Solid Low Latency Signal Processing | | Songwriter | `--- http://www.angelfire.com/or/audiality -' `- [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] RTAI and RTLinux
On Tue, Sep 05, 2000 at 05:05:56PM +0200, David Olofson wrote: Tue, 05 Sep 2000 [EMAIL PROTECTED] wrote: Let's say I have N message buffers in a pool. What if there is no more free buffer? Then the design for your hard real time system was wrong :-) Or system reached its limits. Yep, and the only options are a) redesign and b) upgrading the hardware. It depends on your possibilities and intentions. What if amount of incoming data is unpredictable but you have to process at most as you can with a limited hardware? That's a kind of *soft* real time system, which is not really what RTL is intended for. (Although the input-"some kind of output" latency could have a hard RT requirement - but the memory allocation would still be soft RT.) You can't optimize a single API for both hard and soft RT, at least not without making it a major PITA to use if you want hard RT, so IMHO, it's a very good idea not to mix these two kinds of systems up when discussing APIs. I don't think that "running out of memory" and "running out of CPU time" are fundamentally different things. It's just that with a memory allocator, you are notified of a lack of resources and can do something graceful instead of locking the machine. dave... -- [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] RTAI and RTLinux
On Tue, Sep 05, 2000 at 10:18:25AM -0700, David Schleef wrote: I don't think that "running out of memory" and "running out of CPU time" are fundamentally different things. It's just that with a memory allocator, you are notified of a lack of resources and can do something graceful instead of locking the machine. Sure. But I think there is a significant difference between: 1. At startup time, allocate N buffers for a pool for a particular purpose and have an allocate/free routine. and 2. Maintain a general purpose buffer pool with unknown size and many users. -- - 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/
Re: [rtl] RTAI and RTLinux
On Fri, Sep 01, 2000 at 04:35:26PM +0200, [EMAIL PROTECTED] wrote: I don't agree. The world - where the program runs - is undeterministic. Program must adapt itself to various circumstances including lack of resources. Let's say I have N message buffers in a pool. What if there is no more free buffer? Running out of memory is just a situation what the task must handle if necessary. This is their problem, not yours. For me, there is a critical difference between: Spec 1: If there are no more than N events every K time units the system will never drop data. and Spec 2: If total system memory demands allows, the system will never drop data ... If you allocate memory from a shared dynamic pool with open access to that pool, then any user of system resources, or any shifts in even the timing of the the non-RT portion of your total system may cause failures. Running out of memory is tough enough in the non-RT domain. Linux kernel list features endless discussions on how to keep the Linux kernel floating when there is no more space. I think it all comes down to the specification of the system. If non-deterministic failures are ok, then dynamic memory allocation is ok. But if non-deterministic failures are ok, why not run in the Linux domain anyways? -- - 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/
RE: [rtl] RTAI and RTLinux
-Original Message- From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] Sent: Thursday, August 31, 2000 9:38 PM To: Herman Bruyninckx Cc: Paolo Mantegazza; [EMAIL PROTECTED] Subject:Re: [rtl] RTAI and RTLinux On Thu, Aug 31, 2000 at 05:18:35PM +0200, Herman Bruyninckx wrote: Another thing: if Victor is right about the fact that POSIX doesn't specify which signals can or should be used, then (i) we cannot blame him for using this option, (ii) the ``error'' lies with the POSIX This is not an error -- it would be an error to fix a set of signals that would be presumed to all that are needed in any systems. POSIX defines a core set of signals that must be implemented and an API. BTW the RT signals are merely defined by a range. The implementation is required to provide MAX and MIN definitions but POSIX at least does not presume to tell us how big this range must be. But POSIX does require that the range is at least 8. How big is the range in RTLinux and RTAI? Chris -oOo- Chris Clark LynuxWorks SA email : [EMAIL PROTECTED] web: www.lynuxworks.com -oOo- -- [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] RTAI and RTLinux
For what it is worth. Steve P. sent me a perfectly polite and useful explanation of how his memory allocator works and how it returns a failure instead of suspending when memory is exhausted. I do continue to think that RT software should be simple and not rely on dynamic allocation of resources -- since this is not compatible with determinism. I don't agree. The world - where the program runs - is undeterministic. Program must adapt itself to various circumstances including lack of resources. Let's say I have N message buffers in a pool. What if there is no more free buffer? Running out of memory is just a situation what the task must handle if necessary. This is their problem, not yours. Regards Gabor -- [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] RTAI and RTLinux
[EMAIL PROTECTED] wrote: Let's say I have N message buffers in a pool. What if there is no more free buffer? Then the design for your hard real time system was wrong :-) Bernhard -- [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] RTAI and RTLinux
On Thu, 31 Aug 2000, Pierre Cloutier wrote: : I switched to RTAI many moons ago when I finally understood Victor's ego : was bigger than everest. Time to read Carlos Castaneda. : : Rus -- [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] RTAI and RTLinux
Stuart Hughes ([EMAIL PROTECTED]) wrote: [EMAIL PROTECTED] wrote: As I have pointed out before, the purpose of Steve Papacharalambous' POSIX package is very much different from the purpose of our PSE51 API -- even though we draw from the same base spec. Steve's package is great for people who want to port code from Chorus or Lynx or something to RTLinux. Indeed, very good for people porting real applications to RTAI. I guess from the late addition of pthread_mutex_xxx and pthread_cond_xxx to RTLinux that you agree with his philosophy of using the Linuxthreads package as a template. No, our philosophy is different, and we are not using Linuxthreads as a template. Rather than starting with Linuxthreads, we build our own implementation. We feel that this leaves us more freedom in choosing correct (performance- and otherwise) design decisions. 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] RTAI and RTLinux
[EMAIL PROTECTED] wrote: On Wed, Aug 30, 2000 at 03:18:23PM +0100, Trevor Woolven wrote: BTW, can anyone *really* explain the point of non-portable extensions in a (supposedly) portable standard? I'm not saying they're wrong but they don't make sense (to me). We follow POSIX PSE51 for reasons of simplicity, coherence, programmer familiarity, and because there is a real standard, not a creature of any company. POSIX is specified so that implementation extensions can be accomodated. For example, to reserve a RTLinux only processor in an SMP system, we have pthread_kill(pthread_linuxthread(),RTL_SIG_SUSPEND_LINUX ); Of course, there is no signal RTL_SIG_SUSPEND_LINUX in the POSIX specifications and this code will fail on Chorus -- but our goal is to make RTLinux programming easy, not to make RTLinux as slow and clumsy as Chorus. And the POSIX standard is designed to allow for such extensions. This is also an illustration of why we moved past the very simple V1 API. In order to add this functionality to V1 we would have had to extend V1 and we decided that after a while V1-extended would be a horrible mess. So between the choice of extending V1 and adopting a flexible, Pthreads API, we chose Pthreads. The existence of PSE51, a POSIX standard that allowed us to do Pthreads without e.g. unix file system, made it possible. As I have pointed out before, the purpose of Steve Papacharalambous' POSIX package is very much different from the purpose of our PSE51 API -- even though we draw from the same base spec. Steve's package is great for people who want to port code from Chorus or Lynx or something to RTLinux. But RTLinux is based on fundamentally different design than those systems and we are trying to make a convenient API for that design. So it misses the point to critique Steve's package for lack of speed/determinism or our work for exposing the RTLinux design. I wasn't being critical just asking for information but I have to echo Stuart here, if you have some speed/determinism problems with Steve's pThreads package then I'd like to take a look at them if you don't mind. I personally seem to be a bit out of date here - how does PSE51 differ from 1003.1x ? Thanks for your help Trevor -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com -- Zentropix Inc - a Lineo company Tel: +44 (0)1273 234 647 Fax: +44 (0)1273 704 482 Visit http://www.zentropix.com/ for Real Time Linux Tools Visit http://www.realtimelinux.org/ for Real Time Linux Information -- [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] RTAI and RTLinux
On Thu, Aug 31, 2000 at 11:18:34AM +0100, Trevor Woolven wrote: [EMAIL PROTECTED] wrote: I wasn't being critical just asking for information but I have to echo Stuart here, if you have some speed/determinism problems with Steve's pThreads package then I'd like to take a look at them if you don't mind. My understanding is that, for example, there is dynamic memory allocation in Steve's package. I personally seem to be a bit out of date here - how does PSE51 differ from 1003.1x ? The POSIX 1003.13 standard defines 4 "environments" ranging from PSE51 (minimal realtime system) to PSE54 (multipurpose) Linux itself is essentially PSE54 compliant -- with all the usual POSIX file system facilities etc. PSE51 defines a multi-threaded "single process" environment. So RTLinux defines a PSE51 system where one of the threads, Linux, is a PSE54 system. The enormous advantage of PSE51 is that it provides an accepted standard API that is compatible with the RTLinux model and that can be adapted to our programming environment without requiring us to add features that compromise the model and/or performance. We have found that the pthreads model fits RTL surprisingly well: "pthread_kill(pthread_linux_thread(), RTL_LINUX_IRQ_SIG+irq) " to send an interrupt to Linux and pthread_create to create a new thread, and etc. IEEE standards can be purchased online from ieee.org. -- - 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/
Re: [rtl] RTAI and RTLinux
[EMAIL PROTECTED] wrote: We follow POSIX PSE51 for reasons of simplicity, coherence, programmer familiarity, and because there is a real standard, not a creature of any company. POSIX is specified so that implementation extensions can be accomodated. For example, to reserve a RTLinux only processor in an SMP system, we have pthread_kill(pthread_linuxthread(),RTL_SIG_SUSPEND_LINUX ); Of course, there is no signal RTL_SIG_SUSPEND_LINUX in the POSIX specifications and this code will fail on Chorus -- but our goal is to make RTLinux programming easy, not to make RTLinux as slow and clumsy as Chorus. And the POSIX standard is designed to allow for such extensions. In any case it remains not portable. Standards are a good things and often people have to adhere to them, but IMHO saying that POSIX is simple is wrong. As I have pointed out before, the purpose of Steve Papacharalambous' POSIX package is very much different from the purpose of our PSE51 API -- even though we draw from the same base spec. Steve's package is great for people who want to port code from Chorus or Lynx or something to RTLinux. But RTLinux is based on fundamentally different design than those systems and we are trying to make a convenient API for that design. So it misses the point to critique Steve's package for lack of speed/determinism Apart from the fact that Steve's package cannot run with RTL, but only with RTAI, from my limited tests experience with Steve's POSIX the above seems a quite unfair statement. In fact thank to Steve's package RTAI has POSIX, for those that needs and wants to use it, with as much determinism as RTL, along with "simplicity, coherence, programmer familiarity", to say the least. Ciao, Paolo. -- [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] RTAI and RTLinux
On Thu, Aug 31, 2000 at 12:52:58PM +0200, Paolo Mantegazza wrote: Apart from the fact that Steve's package cannot run with RTL, but only with RTAI, from my limited tests experience with Steve's POSIX the above Stuart? | |From: Stuart Hughes [EMAIL PROTECTED] |Organization: zentropix |X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.3.99-pre8 i686) |X-Accept-Language: en |MIME-Version: 1.0 |To: [EMAIL PROTECTED] |CC: Gusa [EMAIL PROTECTED], RTL [EMAIL PROTECTED] |Subject: Re: [rtl] SEMAPHORE MODULE =?iso-8859-1?Q?DON=B4T?= COMPILE |References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] |Content-Type: text/plain; charset=iso-8859-1 |Content-Transfer-Encoding: 8bit |Sender: [EMAIL PROTECTED] |Precedence: bulk |Status: RO |Content-Length: 2970 |Lines: 88 | |Hi Victor, | |That's correct, the portable fifos/semaphores/mailboxes can be found at |http://www.zentropix.com/products/download.html by selecting |rtai_rtl_fifos-04.tar.gz |Please note that I have not tested this since RTLinux 2.0 or RTAI 1.0. |Please let me know if you have any changes you want to go in. | |Regards, Stuart | | | | |-- |- |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/
Re: [rtl] RTAI and RTLinux
[EMAIL PROTECTED] wrote: On Thu, Aug 31, 2000 at 11:18:34AM +0100, Trevor Woolven wrote: [EMAIL PROTECTED] wrote: I wasn't being critical just asking for information but I have to echo Stuart here, if you have some speed/determinism problems with Steve's pThreads package then I'd like to take a look at them if you don't mind. My understanding is that, for example, there is dynamic memory allocation in Steve's package. Hi Victor, You're correct, there is dynamic memory allocation in the pthreads package, but it makes use of pre-allocated chunks of memory during the real time phases. These chunks of memory are replenished and/or released when the real time components are inactive, and so the impact on speed and determinism is minimal. There are no calls made to allocate or deallocate memory from the Linux kernel during real time operation, Best regards, Steve -- Lineo Industrial Solutions Group Visit http://www.lineo.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/
Re: [rtl] RTAI and RTLinux
[EMAIL PROTECTED] wrote: [ about RTLinux's POSIX compliance...] On Thu, 31 Aug 2000, Paolo Mantegazza wrote: [ about RTAI's POSIX compliance...] Apart from the fact that Steve's package cannot run with RTL, but only with RTAI, from my limited tests experience with Steve's POSIX the above seems a quite unfair statement. In fact thank to Steve's package RTAI has POSIX, for those that needs and wants to use it, with as much determinism as RTL, along with "simplicity, coherence, programmer familiarity", to say the least. This thread is very interesting: under ``pressure'' of the news group both Victor and Paolo seem to release much more information than I could find on the webpages or in the source of both real-time Linux forks :-) However, the discussion reminds me of some other holy wars (KDE-GNOME; NT-Linux; vi(m)-emacs; ...), which means that they focus on the differences, instead of on the commonalities. I would say the current POSIX-efforts of both projects bring them closer together again. After all, the major aim of POSIX was to bring ``simplicity, coherence, programmer familiarity'', wasn't it? :-) But do these POSIX efforts achieve what the common API initiative wanted to achieve in the first place, or is this something completely different? Another thing: if Victor is right about the fact that POSIX doesn't specify which signals can or should be used, then (i) we cannot blame him for using this option, (ii) the ``error'' lies with the POSIX organisation, (iii) both RTAI and RTLinux are POSIX compliant. Or am I overlooking some facts here... -- [EMAIL PROTECTED] (Ph.D.)Fax: +32-(0)16-32 29 87 Dept. Mechanical Eng., Div. PMA, Katholieke Universiteit Leuven, Belgium Real Time and Embedded HOWTO: http://www.mech.kuleuven.ac.be/~bruyninc/rthowto -- [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] RTAI and RTLinux
On Thu, Aug 31, 2000 at 05:18:35PM +0200, Herman Bruyninckx wrote: Another thing: if Victor is right about the fact that POSIX doesn't specify which signals can or should be used, then (i) we cannot blame him for using this option, (ii) the ``error'' lies with the POSIX This is not an error -- it would be an error to fix a set of signals that would be presumed to all that are needed in any systems. POSIX defines a core set of signals that must be implemented and an API. BTW the RT signals are merely defined by a range. The implementation is required to provide MAX and MIN definitions but POSIX at least does not presume to tell us how big this range must be. -- - 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/
OT: RE: [rtl] RTAI and RTLinux
Gang, This is horribly and completely off topic, but I simply can not resist. However, the discussion reminds me of some other holy wars (KDE-GNOME; NT-Linux; vi(m)-emacs; ...), which means that they focus on the differences, instead of on the commonalities. I would say the current POSIX-efforts of both projects bring them closer together again. After all, the major aim of POSIX was to bring ``simplicity, coherence, programmer familiarity'', wasn't it? :-) What holy wars? KDE, Linux and emacs: anything less would be uncivilized. Was there ever any question? Regards, Steve P.S. I like RTL as well, but then I haven't spent that much time with RTAI. -- [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] RTAI and RTLinux
At 06:18 AM 31-08-00 -0600, [EMAIL PROTECTED] wrote: On Thu, Aug 31, 2000 at 11:18:34AM +0100, Trevor Woolven wrote: [EMAIL PROTECTED] wrote: I wasn't being critical just asking for information but I have to echo Stuart here, if you have some speed/determinism problems with Steve's pThreads package then I'd like to take a look at them if you don't mind. My understanding is that, for example, there is dynamic memory allocation in Steve's package. There goes Victor again. Dynamic memory allocation must be bad, and, of course it is bad because Victor says so. Never mind how efficient the algorithm is. Don't even waist time to read the code. Real time programmers should allocate all resources in init_module() and reboot their computers when things go wrong. I switched to RTAI many moons ago when I finally understood Victor's ego was bigger than everest. Regards Pierre Cloutier ___ Pierre Cloutier Tel: (450)-659-9186 Fax: (450)-659-0014 POSEIDON CONTROLS INC ___ -- [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] RTAI and RTLinux
On Thu, Aug 31, 2000 at 11:13:54PM -0400, Pierre Cloutier wrote: I switched to RTAI many moons ago when I finally understood Victor's ego was bigger than everest. Yet your website advertises a RTLinux project. How curious. In any event, despite my vast ego, I really would appreciate it if we could forgo another round of these ill-mannered and rather peculiar discussions of my personality. If you have a question, if you have a critique of how RTLinux works, if you have a technical comment, if you have a suggestion about anything from API to business model to proper compiler, that's fine. Otherwise, please go away. --- For what it is worth. Steve P. sent me a perfectly polite and useful explanation of how his memory allocator works and how it returns a failure instead of suspending when memory is exhausted. I do continue to think that RT software should be simple and not rely on dynamic allocation of resources -- since this is not compatible with determinism. This is an interesting and important technical topic and one that would benefit from real data and cases. Todays contest: Who wrote ? In a world of enormous and intricate interfaces, constantly changing tools and languages and systems, and relentless pressure for more of everything, one can lose sight of the basic principles -- simplicity, clarity, generality -- that form the bedrock of good software. - best regards Victor -- - 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/
Re: [rtl] RTAI and RTLinux
Karim Yaghmour wrote: This is actually quite interesting and goes to show that not all is clear about what RTAI is (no offence to Ivan, I'm just raising concerns). As others will fast point out, RTAI is an RT extension to Linux on it's own. It has very little to do with RTL in it's current form and doesn't have a pretence to it, in any case, even though it might have started from the same source. Therefore, RTAI features are RTAI features and RTL features are RTL features, no effort is made to "be compatible". Exception made of different independant projects who make an effort to be compatible with both (comedi is an example to this). In other words, your first assumption is wrong: RTAI is __NOT__ a compatible extension to RTL with extra features. However, LineoISG (for whom I work - formerly called Zentropix) have developed a Common API compatibility layer (it's actually a header file) which allows users to write one set of code that can then be used to run either RTAI or RTL. This was produced after the Real-Time Linux workshop held in Vienna last December as most of the delegates seemed to want one. The general idea is that users can now take the same application code and use whichever underlying Real-Time Linux they want. They can also migrate between them as functionality and features change/improve etc. We would like to see a *real* common API but that starts to get far too political, so for the forseeable future we will maintain our compatibility header and try to keep up with the changes. The Common API is available for free but you have to go to our website to get it, (I hope that's not too much to ask :-) http://www.lineoisg.com We use the Common API internally to support our customer base on both 'flavours' of Real-Time Linux. Hope this helps Trev Hope this clear things a little for you (Ivan) and other readers out there. Karim Ivan Martinez wrote: Hello all: I'm comparing RTAI to RTLinux and I just want to make you a couple of questions. Please don't start fighting about which sytems is best!. It's not about that. I understood RTAI is a compatible extension of RTLinux with extra features, right?. Is the extension made from every RTLinux version or it's a different project-branch now?. If it's an extension, how is compatibility kept?. Let's say RTLinux guys decide to implement their own semaphores after RTAI. Because of being the original project, they don't care about how things are already implemented in RTAI, do they?. What happens then in RTAI?. Does it keep both its original implementation and the new RTLinux one?. Thank you, and please stay as friends ;-) -- Ivan Martinez (Rodriguez) Bch in Software Engineering - MSc student http://www.geocities.com/ivan_m_r2/ "Got fabes?" -- [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/ -- === Karim Yaghmour [EMAIL PROTECTED] Operating System Consultant (Linux kernel, real-time and distributed systems) === -- [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/ -- Zentropix Inc - a Lineo company Tel: +44 (0)1273 234 647 Fax: +44 (0)1273 704 482 Visit http://www.zentropix.com/ for Real Time Linux Tools Visit http://www.realtimelinux.org/ for Real Time Linux Information -- [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] RTAI and RTLinux
Herman Bruyninckx wrote: On Wed, 30 Aug 2000, Trevor Woolven wrote: [... (in)compatibilities between RTL and RTAI...] However, LineoISG (for whom I work - formerly called Zentropix) have developed a Common API compatibility layer (it's actually a header file) which allows users to write one set of code that can then be used to run either RTAI or RTL. The general idea is that users can now take the same application code and use whichever underlying Real-Time Linux they want. They can also migrate between them as functionality and features change/improve etc. How well does this common API follows the evolution of both forks? I mean, if RTL comes out with version 3.0, how fast will the common API follow this new version? Or will it, by definition, be a greatest common divisor of the functionality of both forks? The Common API will be updated once we're happy that a release has stabilized enough for us to do the work without wasting too much of it. Obviously, we're susceptible to commercial pressure if customers want the updates early. We would like to see a *real* common API but that starts to get far too political, so for the forseeable future we will maintain our compatibility header and try to keep up with the changes. Shouldn't this *real* API be the POSIX-compliant one that RTL is trying hard to follow as far as reasonably possible? Or am I stating things a bit too simply here... Well, if you look at the Common API it's very simple and the beauty of both RTL and RTAI is that their 'core' APIs are so similar (for very good reasons) and simple. The idea behind the Common API is to provide a small, functional core to allow users to get the maximum, hard real-time performance from their chosen Real-Time Linux without having to learn a huge and unwieldy API. A small, well-chosen API that provides all the necessary real time functionality is what we're after. Unfortunately, there are subtle differences that (we thought) needed to be covered. Life would be easier for all of us if the core APIs of RTAI and RTL could be merged (yes, I know we've been here before!). 'Nuff said... As to POSIX, we'd need to get a consensus from the providers of RTL and RTAI on which POSIX calls to implement and which to ignore. I think it's going to be extremely difficult for anyone to be fully POSIX-compliant (in this area) due to the size and complexity of the standards (plus you have to pay for them!). I understand that the standards do not mandate everything in them (but I don't know which bits as I haven't read the entire set). To my mind you are either compliant or you're not and filling-up the grey area with a list of areas of non-compliance just muddies the water further (and taxes my brain :-). BTW, can anyone *really* explain the point of non-portable extensions in a (supposedly) portable standard? I'm not saying they're wrong but they don't make sense (to me). -- [EMAIL PROTECTED] (Ph.D.)Fax: +32-(0)16-32 29 87 Dept. Mechanical Eng., Div. PMA, Katholieke Universiteit Leuven, Belgium Real Time and Embedded HOWTO: http://www.mech.kuleuven.ac.be/~bruyninc/rthowto/index.html -- Zentropix Inc - a Lineo company Tel: +44 (0)1273 234 647 Fax: +44 (0)1273 704 482 Visit http://www.zentropix.com/ for Real Time Linux Tools Visit http://www.realtimelinux.org/ for Real Time Linux Information -- [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] RTAI and RTLinux
On Wed, Aug 30, 2000 at 03:18:23PM +0100, Trevor Woolven wrote: BTW, can anyone *really* explain the point of non-portable extensions in a (supposedly) portable standard? I'm not saying they're wrong but they don't make sense (to me). We follow POSIX PSE51 for reasons of simplicity, coherence, programmer familiarity, and because there is a real standard, not a creature of any company. POSIX is specified so that implementation extensions can be accomodated. For example, to reserve a RTLinux only processor in an SMP system, we have pthread_kill(pthread_linuxthread(),RTL_SIG_SUSPEND_LINUX ); Of course, there is no signal RTL_SIG_SUSPEND_LINUX in the POSIX specifications and this code will fail on Chorus -- but our goal is to make RTLinux programming easy, not to make RTLinux as slow and clumsy as Chorus. And the POSIX standard is designed to allow for such extensions. This is also an illustration of why we moved past the very simple V1 API. In order to add this functionality to V1 we would have had to extend V1 and we decided that after a while V1-extended would be a horrible mess. So between the choice of extending V1 and adopting a flexible, Pthreads API, we chose Pthreads. The existence of PSE51, a POSIX standard that allowed us to do Pthreads without e.g. unix file system, made it possible. As I have pointed out before, the purpose of Steve Papacharalambous' POSIX package is very much different from the purpose of our PSE51 API -- even though we draw from the same base spec. Steve's package is great for people who want to port code from Chorus or Lynx or something to RTLinux. But RTLinux is based on fundamentally different design than those systems and we are trying to make a convenient API for that design. So it misses the point to critique Steve's package for lack of speed/determinism or our work for exposing the RTLinux design. -- - 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/
Re: [rtl] RTAI Vs RTLinux
Jeff Studer wrote: I think the point you missed, Karim, was that a function pointer is no big deal. The fact someone makes out like it was, is sort of silly. So I was a silly guy from the very beginning, the good guys became such afterwards only afterwards. BTW: then all PPC Linux is a silly code as most basic mach dep functions, including sti/cli equivalents, are pointers natively. Clearly I do not think so, in fact all Linux versions should be structured that way. Note that I'm not supporting that specific implementation but just the idea behind it, i.e. a complete HAL, which despite someone's claim is not present yet in i386 Linux. Torvalds likely does not like it and is accepting such a solution for other archs just because that helps in promoting his creature and, being almost god but not completly, cannot do everything by himself. The truth is that pointers are not so silly as they affect only Linux and ease making real time simpler, without any real time loss of performace since real time does use those machine instructions that are forbidden to Linux. As I said many times people that want to enter this discussion should read the code and know the whole story from its beginning. If they have no time they should stay shut up. It makes no sense to take excerpts of the whole story only because they can be bent to your own deceiving aims. So I suggest you just go to www.rtlinux.org, browse their March 1999 archives for: Subject: [rtl] Real Time Application Interfaces/ From: Paolo Mantegazza [EMAIL PROTECTED] Date: Tue, 09 Mar 1999 11:34:44 + It is a rather long and annoying one, but you should read it to get an hystorical perspective for my claims. Then look at the following mails and check the, deceiving, debate that went on at that time against the present one on the subject. Even better, dowload all the RTL and myrtlinux/RTAI versions from the very beginning and cross check them. Maybe you can end in writing a book paralling Pulitzer prize winners "The Making of the atomic/H bomb", but it should be called "the making of real time Linux, how to smuggle business as OSS ethos" Ciao, Paolo. -- [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] RTAI Vs RTLinux
I think the point you missed, Karim, was that a function pointer is no big deal. The fact someone makes out like it was, is sort of silly. There is no reason for this mailing list to turn into a mud slinging fest that it has been for the past few weeks. This is supposed to be a constructive helpful group, not a flaming 'mine is better than yours' debate group. I'm rather appalled at the juvenile behavior and comments coming out of here. I think every developer wants to improve their product, and that is the point of this list. Arrogance, on anyone's part, is not going to help. Lets bring this list back on topic. My feeble attempt at mediating, Jeff - Original Message - From: "Karim Yaghmour" [EMAIL PROTECTED] To: "Michael Barabanov" [EMAIL PROTECTED] Cc: "Paolo Mantegazza" [EMAIL PROTECTED]; "Zdenek Kabelac" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, June 29, 2000 11:48 AM Subject: Re: [rtl] RTAI Vs RTLinux Michael Barabanov wrote: For you, not being a computer scientist -- like you acknowledged so many times before -- using function pointers may be something of an innovation; for me at least this is an obvious thing to do. To me, the position like "here! he used a function pointer like a I did a year ago!!!" seems quite strange. Regardless of the current context of discussion, I would like to point out that this is a cheap shot. The fact that Paolo isn't a computer scientist doesn't mean he can't make the difference between what is an innovation and what isn't. I've seen electrical and civil engineers become the best of programmers and invent quite very usefull pieces of software because they recognized the need to innovate, I don't see why a mechanical engineer couldn't. Being a computer engineer myself, I do see quite a difference between the way hooking onto Linux is done in RTAI and in RTL. === Karim Yaghmour [EMAIL PROTECTED] Operating System Consultant (Linux kernel, real-time and distributed systems) === -- [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/ -- [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] RTAI Vs RTLinux
Following my first posting on this thread, Victor and I have exchanged quite a heated discussion (off the list). I can't say that we reached any agreement on anything and I still do have my concerns, but I would like to publicly apologize for flaming Victor. My intent was to spark a fruitful discussion and it wasn't necessarily the best way to start. That said, I still do think that there are serious issues that need to be resolved (which means that the discussion is still ongoing). I have my concerns, so does Victor and so do others, but as Jeff has just pointed out: "Arrogance, on anyone's part, is not going to help". So here, this is an attempt to push things on a more reasonable track. === Karim Yaghmour [EMAIL PROTECTED] Operating System Consultant (Linux kernel, real-time and distributed systems) === -- [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] RTAI Vs RTLinux
We noticed and appreciated it. Mike Cravens Paolo Mantegazza wrote: Hi, BTW, there is one thing I forgot to acknowledge to Victor along this heated debate of "ideas", his attitude in keeping this list unmoderated and open also to this kinds of exchanges. Ciao, Paolo. -- [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/ -- Alcatel USA Internet: [EMAIL PROTECTED] 1000 Coit Road Plano, Texas 75075 The opinions expressed are not those of DSC Communications, Inc "Keep things as simple as possible, but no simpler". A. Einstein begin:vcard n:cravens;mike tel;home:(972) 423-9463 tel;work:(972) 477-7077 x-mozilla-html:TRUE adr:;;1000 Coit Rd;Plano;Tx;75075;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Senior Software Engineer x-mozilla-cpt:;-10560 fn:[EMAIL PROTECTED] end:vcard
Re: [rtl] RTAI Vs RTLinux
Hello Cort, Thank you for your informative reply. Victor's quote is indeed misleading compared to the statement you make. The "unfortunate" nature of the inclusion of RTL stuff into the mainstream kernel has to do with the way the project is being developed, not because of the technical advantages of having RT support in Linux. I agree with you fully on this, having RT support in Linux would be a very good thing for everyone. What I would find very unfortunate would be to include the RTL form of doing RT in Linux rather than the RTAI way. This brings me to the Microsoft-part of my comment which is directly linked to the comment made by Paolo in this thread regarding Victor's claims about RTL. In fact, my mail is seriously misleading if read without the context established by Paolo's remarks. What I mean by Microsoft-like way of innovating is the fact that Victor has taken a lot of ideas, that had been put forward by Paolo, and put them into RTL without __explicit__ recognition of the source of inspiration. The reason RTAI ever started (or, at least, what I make of it) is that Paolo kept sending good ideas to Victor and Victor kept ignoring Paolo. Having had enough of this, Paolo went on his way and started RTAI. It seems now that someone somewhere realized that the Paolo's ideas were good after all and that they should be part of RTL. Of course no one can stop any open-source contributor from taking inspiration from another project, but I think that there is a bare minimum of social decency and scientific honesty to give back the merit where it belongs. I might be very wrong about Victor (and I hope I am), but the record has shown that recognizing that others can have good ideas, if not better, has been late to come. (and this is where my comments fit in) As for authority regarding inclusion or exclusion of RT in Linux, this of course goes to Linus and he has done quite a good job until now of sorting the good ideas from the bad ones. I usually tend to agree with what he decides. Your are right, objecting would put me at the end of the queue, but if it is worth, I'll wait in that queue. Keep up the good work and thank you for the information. Best regards, Karim Cort Dougan wrote: How is this unfortunate? Making any form of real-time Linux available on PowerPC (and Alpha, which we've done as well) is a good thing in my opinion. To make what Victor wrote more accurate: "...RTLinux _works_ with the default PowerPC Linux kernel...". We have not put RTLinux into the main kernel tree nor would Linus allow that. I don't understand how you see that any Microsoft tricks have been used. Linus is the final authority on what goes into the kernel. If he merged in changes that you don't approve of then take that up with him (you'll be a the tail end of a very very large line) but that isn't something you should be unhappy with us about. That goes doubly so if no other candidate patches have been sent. I'm the Linux/PPC maintainer and I haven't seen any patches from anyone else for giving real-time performance on Linux/PPC. } [EMAIL PROTECTED] wrote: } RTLinux is in the default PowerPC Linux kernel in development versions. } } Given your previous record, I must admit that this is quite an } unfortunate event! I'm siding with Paolo on this one and hope } that most people reading this do take a very serious look at } RTAI. In my opinion, it far outdoes anything RTLinux can ever } do (plus, it doesn't need to employ Microsoft-like tricks to } innovate). } } My 2$ -- [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/ -- === Karim Yaghmour [EMAIL PROTECTED] Operating System Consultant (Linux kernel, real-time and distributed systems) === -- [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] RTAI Vs RTLinux
Hi all, Just a short end-user observation : With rtlinux v2.3, I crashed the computer about 50 times for the developpement of various programs whose total length is about 1000 lines. I never got any explanation about these crashes (see the thread "rt-linux:strange random system hang using FP" in this list). With rtai 1.3, I never crashed the computer while developping a project (a robot controller) of 1 lines with a lot of FP operations. Best regards, Jacques -- _ ( ) Jacques GANGLOFF ( Associate Professor ) LSIIT / GRAViR ( Bd Sébastien Brant ) 67400 Illkirch ( Tel : +33 (0)3 88 65 50 84 ) Fax : +33 (0)3 88 65 54 89 ( http://gravir.u-strasbg.fr )_ -- [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] RTAI Vs RTLinux
Zdenek Kabelac wrote:
there are no kernel modification - CLI/STI are the enemies and I would
like to know how they are handled in RTAI. What happens when
SBLive driver calls spinlock_irq_safe ??
One of the main advantages of RTAI (but my understanding is that RTL
has included this now ... see what I mean) is that it doesn't take RT
control over from Linux right away. RTAI inserts generalized hooks
into Linux which are not used right away. These hooks end up calling
on the normal Linux functions as long as RTAI isn't installed. Once
installed, RTAI uses those hooks to take the control of the system.
Therefore, if SBLive calls on spinlock_irq_safe, it is caught by RTAI.
Meanwhile RTAI uses true locking facilities to further it's ends.
I don't understand this - you mean when CPU executes CLI/STI its being catch
by some trap - I could imagine that Linux kernel runs on
different level of protection (i386 has four of them if I remember this
correctly), but this exception handling takes quite a lot of CPU cycles.
Is there any explanation/article I could learn more about this "magic" ??
(Basicaly how RTAI could hold with timelimit if the linux-driver calls CLI
and wait in busy-loop for 1ms)
(I still suppose there are no internal kernel modifications and I could
use RT just with module insert of RTAI modules)
--
There are three types of people in the world:
those who can count, and those who can't.
Zdenek Kabelac http://i.am/kabi/ [EMAIL PROTECTED] {debian.org; fi.muni.cz}
-- [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] RTAI Vs RTLinux
[EMAIL PROTECTED] wrote: RTLinux is in the default PowerPC Linux kernel in development versions. Given your previous record, I must admit that this is quite an unfortunate event! I'm siding with Paolo on this one and hope that most people reading this do take a very serious look at RTAI. In my opinion, it far outdoes anything RTLinux can ever do (plus, it doesn't need to employ Microsoft-like tricks to innovate). My 2$ === Karim Yaghmour [EMAIL PROTECTED] Operating System Consultant (Linux kernel, real-time and distributed systems) === -- [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] RTAI Vs RTLinux
[EMAIL PROTECTED] wrote: To be honest, I've never understand what Paolo means by the concept of a hardware abstraction layer beyond some renaming and use of indirect pointers to implement the redirection. Yes it is just that. But see the following part of my answer, In V2 RTLinux uses a technique in which Linux "cli" is redefined to be a static call to a rtl function, in V3 x86 uses a indirect jump. In later versions, we will get rid of this jump again -- it was easy to implement but it does have a cost that is more noticeable in lower end processors. So from my point of view: cli compiles to "jsr rtl_cli" or cli compiles to "movl rtl_table,%eax; movl CLIOFFSET(%eax),%eax; jsr *%eax" is conceptually the same with only a performance/ease_of_programming tradeoff. The above is just the confession that in V3 you are now using the HAL concept, i.e. instead of patching the kernel use pointers. You are really a nice chap, when I proposed it you refused it, now, as usual, you are doing it and is OK, even dare to claim nothing changed. The fact is that at the beginning RTL V2 patches were 1.8 K-lines now V3 is just 600 and it is in fact RTHAL-RTAI in disguise. People reading this message should have the patience of getting RTAI-0.1 (April 1999) and check it against the old versions of RTL-V2 and the newest V3. Just some samples about V3: - you use pointers for interrupt menagements (RTAI native); - now RTL is mounted at rtl_core insmod, you call it arch_something, (RTAI native); - in MP now you can direct interrupts to specific CPUS (RTAI native), but the concept is now also in vanilla Linux; - and so on and so on.. You know very well that users do not mind about and never check the basic items. So you hope that they end in thinking that I'm just a boring old man, while Yodaiken is the master. Ciao, Paolo. -- [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] RTAI Vs RTLinux
Linux provides a informal hardware abstraction layer, otherwise RTLinux would be impossible -- and Linux itself would be painful to port. That is, Linux makes use of calls to "cli" and "sti" etc. which RTLinux converts into calls to the emulator code. To be honest, I've never understand what Paolo means by the concept of a hardware abstraction layer beyond some renaming and use of indirect pointers to implement the redirection. In V2 RTLinux uses a technique in which Linux "cli" is redefined to be a static call to a rtl function, in V3 x86 uses a indirect jump. In later versions, we will get rid of this jump again -- it was easy to implement but it does have a cost that is more noticeable in lower end processors. So from my point of view: cli compiles to "jsr rtl_cli" or cli compiles to "movl rtl_table,%eax; movl CLIOFFSET(%eax),%eax; jsr *%eax" is conceptually the same with only a performance/ease_of_programming tradeoff. On Mon, Jun 19, 2000 at 08:40:27AM -0700, roux jean-denis wrote: Hi guys, I would like to know how RTLinux works. I know that both RTAI and RTL turn Linux to a task running when no real-time activity occurs and that RTAI use the concept of the Hardware Abstraction Layer (RT HAL) but not RTL. That's why I would like to know what concept use RTLinux. Jean-Denis ROUX __ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.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/ -- - Victor Yodaiken FSMLabs: www.fsmlabs.com www.rtlinux.com FSMLabs is a servicemark and a service of VJY Associates L.L.C, New Mexico. -- [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] RTAI and rtlinux
They're both very similar and use the same mechanism to achieve real time performance. However, there are differences between them, so I suggest you visit the two websites, download the latest versions and take a look. http://www.rtai.org/ http://www.rtlinux.org/rtlinux/ Regards Trevor. Zhixu Liu wrote: What's the difference between RTAI and rtlinux (FSM Lab.)? Zhixu -- [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/ -- Trevor Woolven - Director of Customer Applications Engineering Zentropix Inc - a Lineo company Tel: +44 (0)1273 234 647 Fax: +44 (0)1273 704 482 Visit http://www.zentropix.com/ for Real Time Linux Tools Visit http://www.realtimelinux.org/ for Real Time Linux Information -- [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/
