Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux Gains Native RTOS Emulation Layer

Posted by ScuttleMonkey on from the still-waiting-on-the-developer's-flyback-time dept.

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."

7 of 89 comments (clear)

  1. Realtime, VxWorks, Dolla Dolla Bill Yall by Epistax · · Score: 5, Interesting

    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...

    1. Re:Realtime, VxWorks, Dolla Dolla Bill Yall by pla · · Score: 5, Interesting

      VxWorks is.. shall we say... NOT CHEAP.

      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.

    2. Re:Realtime, VxWorks, Dolla Dolla Bill Yall by K.+S.+Kyosuke · · Score: 2, Interesting

      VxWorks is the only OS I've played with so far that allows this

      and god help you if you aren't using off the shelf hardware
      Well, and what does happen if you do use off-the-shelf hardware? I am not exactly "well educated" in this area, but I am not quite sure whether the current typical OTS hardware is suitable for RTOS at all. Well, maybe some soft real time apps may run just fine...but I once spoke after-hours with Vojtech Pavlik (of the linux-joystick-drivers-and-other-input-devices fame) and he introduced me to the wonders of the System Management Mode, a wonderful creation of Intel capable of destroying any precise timing in ordinary PC hardware that just cannot be overridden by any normal means. Does industrial hardware that does not exhibit such features and is designed for RTOS and time-sensitive applications still qualify for the designation "off-the-shelf"?
      --
      Ezekiel 23:20
    3. Re:Realtime, VxWorks, Dolla Dolla Bill Yall by Epistax · · Score: 3, Interesting

      Well, you can change to see if there is processor time being stolen from the OS by toggling a pin on a fast cycle and watching it with an oscilloscope, or perhaps polling the internal pentium timer. Someone before me had checked with our specific setup to see if this was happening (specifically we were concerned if USB hookups caused the BIOS to inject work) but nothing was detected. We use custom PC boards that could have had it disabled at the BIOS level, but I'm just not sure,

      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.

  2. What is the relationship with Xenomai? by Anonymous Coward · · Score: 1, Interesting

    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 :-)

  3. Oh dear god no! by malevolentjelly · · Score: 2, Interesting

    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?

  4. Re:POS needs realtime? hahahahhaha by Anonymous Coward · · 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.