Slashdot Mirror
Linux Gains Native RTOS Emulation Layer
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."
Not to troll or anything, but if you just do a very quick search on the subject you will see why this emulation is a poor idea.
- Lord Haw Haw
srsly now.
The benchmarks that are really expected by real time in my area are things like consistency. For example if we set a task/thread to execute every 125 milliseconds, the closer it hits the mark the better. Time lag in either direction puts that OS in the "No" category. Another important asset of an RTOS is well defined task preemption: No task gets preempted by one with worse priority. Time slicing might be enabled so that a task gets preempted by one of the same priority, and better priority tasks always preempt if they are ready to go. Also if a high priority task is waiting on a resource owned by a low priority task, that low priority task gets an elevated priority equal to the high priority task. As a last ditch effort to provide mutual exclusion / data protection, threads/tasks need to be able to disable system interrupts. Remember kids, in the RTOS world one task can take down the whole system.
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...
IIRC, the main goal of Xenomai was to provide a co-kernel approach (a RT kernel runs the RT tasks and the lower priority task is the Linux kernel). Now this Xenomai/SOLO seems something completely different: just a conversion layer between the VxWorks API and the POSIX RT API. If by chance you are running this layer on a kernel which has good RT properties (for instance Linux PREEMPT_RT) then it will behave more or less like VxWorks (and in addition you can run normal Linux app next to it). I wonder why they called their new things Xinomai/SOLA as it doesn't seem to have any technical relationship with Xinomai. Is it a purely commercial reason?
:-)
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
teh five fruits of create an account! score the i G^
V2L existed forever, but nobody used it simply because this is not needed. API porting (which is the problem that this kind of emulation solves) is one of the minor problems that one faces when porting code from RTOS to Linux. Code written for RTOS usually has very different architecture from what one would recommend for Linux. Once architecture re-design is done, porting the API is easy.
Why not just get a faster computer, 2ghz should do rather than some shit 200mhz crap with RTOS, you can get any 2ghz PC for peanuts these days.
Theres few things that need ultra accuracy, unless they are dependent on law of physics like water pumps or flight guidance systems. But through enough cpu power in and
it can be closer to RTOS than an expensive RTOS system I personally think.
Any NON RTOS system can be made to be close to RTOS if you code your stuff smartly to be aware of time and make sure it doesnt use too much. I mean any one can benchmark
array copies/sorts/inserts and then determine ahead of time if X operation will take more than 100ms. Oh yeah a little more work, but its just one cost.
Btw, if their IDE's are that bad, then it doesnt say much about their OS really... because if they had a clue, they would leverage Eclipse or even plugin to VS.
TEchnically even Amigas were RTOS, since you could hardware wise gurantee interrupts to be triggered.
Liberty freedom are no1, not dicks in suits.
Why would you ever need to emulate an RTOS in linux? Linux does not do what ThreadX, VxWorks, INTEGRITY, uVelocity, or any of the sort do- imagine you're an embedded device manufacturer and suddenly you need to bump your device up from 64k chip of ram to 8mb. This is completely retarded. In the embedded world, true RTOS are used for things that can never fail, lag, or be insecure in any way. Linux is generally used to fill in a cheap userland. Like on Sony TV's, the RTOS junk is handled by uVelocity, but they use linux for the OSD, etc. You DO NOT PUT LINUX in places you put VxWorks. Imagine having that ludicrous monolithic server OS in a PACE MAKER. Or a NUCLEAR MISSILE.
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?
My post has more replies than the rest of the article put together.
Awesome.
- Lord Haw Haw
aw man did i get here too late and the malware post got deleted?
can someone repost link?