Linux Gains Native RTOS Emulation Layer 89
nerdyH writes to tell us that the Xenomai/SOLO project is attempting to deliver VxWorks and other RTOS emulation for any Linux kernel. "Some weeks ago, I started laying the groundwork for porting the Xenomai emulators natively over the PREEMPT_RT kernel. Unlike the co-kernel based Xenomai version, SOLO does not require any kernel support from additional modules or patches. It is fully based on the standard POSIX library, and runs as a regular process controlled by a single image Linux kernel. As a first step, a VxWorks emulator has just been rebuilt over this new framework."
Realtime, VxWorks, Dolla Dolla Bill Yall (Score:5, Interesting)
VxWorks is the only OS I've played with so far that allows this, but I'm VERY curious to see what people can inject into the Linux kernel. VxWorks is.. shall we say... NOT CHEAP. And inter-version migration is a pain... and god help you if you aren't using off the shelf hardware...
What is the relationship with Xenomai? (Score:1, Interesting)
Anyway, so far the reason for having the co-kernel approach was that Linux was not able to provide low latency, so I guess it's good news: some knowledgeable people consider that the latest Linux version (with PREEMPT_RT) is up to the task
Re:Realtime, VxWorks, Dolla Dolla Bill Yall (Score:5, Interesting)
Have you ever actually had to code for Vx?
You couldn't pay me enough (literally - I've turned down jobs that wanted me to work with it... I should probably take it off my resume) to deal with that POS (by which I don't mean "Point Of Sale") on a regular basis.
Actually, in fairness, as an OS, it doesn't suck too much. But the build tools... Let's just say WindRiver clearly subscribes to the "firmware should hurt" coding paradigm. The IDE made OutLook look stable and friendly, the command line build tools simply didn't work (literally - WR couldn't even have tested them, because they failed phenomenally even on a clean install and a "hello world" module), the revision control had no objection to overwriting parent revisions without forcing a new fork... Ugh. I'll probably have nightmares tonight just from thinking about it.
Oddly enough, it surprises me to see it still talked about. When I suffered with it nearly a decade ago, it looked like a near-certainty that Linux would tap that last nail in its coffin. How ironic, that Linux should now give it new life via emulation.
Re:Realtime, VxWorks, Dolla Dolla Bill Yall (Score:3, Interesting)
Re:Realtime, VxWorks, Dolla Dolla Bill Yall (Score:4, Interesting)
Off-the-shelf is where BSP's and drivers come in. The BSP (board support package) needs to be configured for the specific board. WindRiver provides a kajillion default packages, and if you use a off-the-shelf-board, the BSP and driver set should require little or no modification at all so you can just go straight to customizing your OS. The more customized your board is, the more you might have to do, such as writing VME, clock, PCI, or Ethernet drivers, do custom memory management, etc. I guess it's not fair to peg this complication on WindRiver. I haven't tried a Linux kernel on a custom board, but just as much configuring must go on at some point.
Oh dear god no! (Score:2, Interesting)
I could see people wanting to hypervise linux in a secure RTOS but emulate an RTOS in linux? Please tell me this is for development purposes... further still- are they completely insane?
Re:POS needs realtime? hahahahhaha (Score:2, Interesting)
A RTOS isn't about speed, it is about predictability. It is about guaranteed response.
There are some things that a 200MHz machine with the right software can do quicker and more accurately than a 4GHz machine with a standard OS.
What it comes down to is they built an expensive mansion, but built it on sand. Doesn't matter how expensive or big the house is, if it is built on a poor foundation, the house will be unstable.
I have seen process control applications where an 8MHz 8086 was fine. No OS, just application coded in ROM. Fast enough, stable. When newer, faster processors came available, the bosses decided, "We have power to burn, let give the application a GUI." So now they run with dual processor motherboards. But... motherboards today are not as fully debugged as the old days. Some companies never kills the bugs, they just release a new Motherboard with a new (buggy) chipset. Same for the OS. A well written application becomes unstable.
If you drop a scratched DVD in you DVD drive, does your windows machine kind of hang while windows tried to decide what is there? I've experienced that quite a few times.
BTW, this is similar to Linus' exchange with Tannenbaum on monolithic v.s. microkernel.