Slashdot Mirror
Realtime OS Jaluna
rkgmd writes "Jaluna-1, a software component suite based on the
respected chorus realtime os is now available in opensource (MPL-derived license) form. Jaluna, the company behind this, is a spin-off from sun to promote and develop chorus, and consists of many developers from the original chorus team before it was acquired by Sun. Chorus developed one of the earliest successful microkernel-based rtos's (could even run parallel, distributed unix in realtime on inkos transputers in 1992). Lots of good research papers here, and a link to the original newsgroup announcement."
Another notch for opensource, sounds like a useful thing to have lying around for all your real-time os needs. "Jaluna-1 supports POSIX Real-Time standard applications, and includes state of the art tools for developing, deploying, configuring, and managing embedded systems. Jaluna-1 is being offered as open source, royalty-free software. Jaluna complements its open source software offering with technology and services enabling customers to easily migrate from proprietary Real-Time Operating System (RTOS) based projects to royalty-free Jaluna-1"
Last.fm - join the social music revolution
It should probably be mentioned that LOT's of commercial RTOS's provide source. For a lot of applications this is pretty much a requirement. The real distinction here is the royalty-free license, although RT-Linux (which I know almost nothing about) obviously doesn't require royalties.
Roving Web-Teleoperated Robot
I'm a student at the University of Waterloo. I recently took their real-time course. You would apparently be dismayed to learn that even after taking that course, and spending an average of about 35 hours a week outside of class working on it, I don't know a thing specifically about Jaluna or any other real-life real-time OS.
Instead of teaching us how to code for Jaluna they taught us enough about the inner workings of RTOS's that we could write a limited one on our own. In fact, we did - hence the incredibly large (yet rewarding) workload.
Atheism is a religion to the same extent that not collecting stamps is a hobby.
VxWorks' and QNX's advantage over ChorusOS was a combination of wider BSP support and very mature toolchains. ChorusOS big advantage was that it was specifically targetted at distributed applications - this is a issue for applications that combine real-time performance with data-centre-like reliablility (particularly telco).
## W.Finlay McWalter ## http://www.mcwalter.org ##
Whoever marked the parent as a troll is obviously ignorant, and I hope it gets fixed in meta.
91degrees is correct. Inmos was a British company that released the transputer around 1985, and was specifically designed to be used in a network of interconnected processors. These chips were 32 bits and were programmed in the Occam programming language. Data transfer between nearest neighbors was over a 10-20 megabit serial connection. Each processor had 2K of memory onboard, and the entire transputer array was meant to be controlled from another computer. Typically that meant that a transputer array was implemented as a daughter card that fit into a computer such as a PC.
Don't mod me up, mod the parent post up.
If tits were wings it'd be flying around.
Actually Windows 3.1 is closer to an RTOS than you think. In most RTOS's, a task can starve any other task running at the same priority (or lower). Same as the cooperative multitasking model in Windows 3.1.
You can learn C++ for years and then open a good book about it and understand that you still don't know SHIT. Don't agree? Buy yourself the following books:
Effective C++
More Effective C++
Exceptional C++
I read these books to humiliate myself, and other people when I pull something that I read in them from my head and even the "experts" start talking crap.
The more you know, the better you understand how much more you don't know.
*
I don't know what you are talking about. How could one starve another in a RTOS? Hard deadlines are set. Most of the time, the process with the closest deadline is selected (some have time estimates and do other optimizations). If a task doesn't complete by it's deadline, it can get preempted because completing the task was just not possible. In effect, you overloaded the system therefore it is unresponsive. AFAIK, any system that is that overloaded will be unresponsive and concentrate on the higher priority tasks. You make this out to be a bad thing (or at least to a casual observer), when in all actuallity it's a great thing. If delivering the next frame to the GPU is more important to you than compiling the kernel, the kernel will get starved. In Linux and other non-RTOS's, you will run out of time slices because they are being "fair".
This reminds me of the whole VM issue. If you don't have enough memory to complete a job, no VM you have is gonna help you. Likewise, if you don't have enough CPU to complete the job, no schedular is going to help. Where the new VM and RTOS's help is when you are playing your FPS game, you can schedule regular intervals to fill the audio buffer and calculate the next frame as well as do physics calculations. If you don't have enough CPU to do them all, pick the ones that matter most. Linux can pick them in the wrong order and miss a more important calculation getting done on time. No one has actually tested if linux can do more overall because of this, but most of us have a select few tasks actively interacting with us that we would really like to not be interrupted. RTOS can guarantee this at the sake of other processes, but that's a good thing. Win3.1 on the other hand, one unimportant process can not relenquish the CPU.
Karma Clown
The basic difference is that the kernel in a microkernel system is just that, micro. It includes functionality only for the concepts of tasks, the memory they use, the CPU time they get, and the messages they pass to each other.
This is rather different than, say, Linux. Here the kernel includes all sorts of things, like networking stacks, device drivers, file systems, etc. These are basic parts of the kernel itself, along with everything in the microkernel too.
So how does one use a microkernel if it doesn't have all this (required) stuff? Basically all of these things are compiled into modules known as "servers", and run as separate tasks -- just like any other program. So if your web browser needs to send a request to a web server, it does so by (essentially) saying "hey microkernel, could you tell the networking program to send this to this address? Thanks!". In a traditional kernel your web browser would do a local "method call".
This might sound piquane, and for the end user it often is. However, in theory at least, microkernels offer the ability to help development. That's because you can load up or ditch any of these little "servers" without any effect on anyone else -- that's why they're so useful for RTOSs, because you can ditch what you don't need -- and even do so while the computer continues working. No reboots to fix a bug in your ethernet card driver...
Yes, the poster means Inmos. Still have my copy of the "Communicating Process Architecture" and "Transputer Instruction set." As you'll remember, the Transputer was the ultimate RISC machine - 16 instructions, including one that allow you to 'extend' the instructions. I first saw them F2F in 1989 at the 3rd Int'l Conference on Hypercubes and Concurrent Computers, which was held in Pasadena. Welch and other Inmos lumes were there. Each transputer had 4 communication channels, which mapped nicely to the channel construct in Occam, which was the language of choice for them in those days. Occam folks were big into 'proving' the software was correct. AIRC, the Floating point unit for the later model Transputers was written as an Occam program, proved correct, and then translated into hardware that matched said program. (T4XXs? T8XX?)
There were standalone Transputer boxes, but there were also several folks demonstrating PCI cards that were meant to plug into a standard pc. I recall that one vendor had a 4 cpu card.
Later, there was a C compiler for the processor, since so many folks rebelled against Occam.