Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software Linux

Linux Gains Native RTOS Emulation Layer 89

Posted by ScuttleMonkey 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."
This discussion has been archived. No new comments can be posted.

Linux Gains Native RTOS Emulation Layer More

Linux Gains Native RTOS Emulation Layer

Comments Filter:

  • Realtime, VxWorks, Dolla Dolla Bill Yall (Score:5, Interesting)

    by Epistax ( 544591 ) <epistax@gmail. c o m> on Saturday March 22, 2008 @06:54AM (#22828390) Journal
    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...

    • Re:Realtime, VxWorks, Dolla Dolla Bill Yall (Score:5, Informative)

      by JohnFluxx ( 413620 ) on Saturday March 22, 2008 @07:02AM (#22828416)
      > 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.

      Any normal distro Linux kernel can do this particular part. Just set the scheduler to round robin. (You can do this in KDE4 btw. Press ctrl-esc to bring up the task manager, right click a process, change priority, and chose round robin.)

    • Re:Realtime, VxWorks, Dolla Dolla Bill Yall (Score:5, Interesting)

      by pla ( 258480 ) on Saturday March 22, 2008 @08:00AM (#22828664) Journal
      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.

      • Re:Realtime, VxWorks, Dolla Dolla Bill Yall (Score:4, Informative)

        by Epistax ( 544591 ) <epistax@gmail. c o m> on Saturday March 22, 2008 @08:17AM (#22828724) Journal
        Oh yes I've coded for it. I'm on my second BSP and my third kernel. It's not as bad as it used to be in some respects. The Eclipse is the IDE now. The documentation is still horrendous though. WindRiver is working hard on their own RTOS Linux solution. I don't know if they are planning on eventually digging a hole and throwing VxWorks in it, or just trying to combat the free RTOS Linux market with something they can sell to managers.

        • Re: (Score:3, Informative)

          by PCM2 ( 4486 )
          I have asked Wind River representatives whether their Linux product is meant to replace VxWorks and they emphatically said no. (If that means anything.)
      • 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.

        Really? I guess vxWorks is an acquired taste then, because I'd be extremely happy to be given the opportunity to use vxWorks again.

        I would have liked to have my own copy, but since a single licence for vxWorks costs more then I can reasonably afford (well, it used to, I can't find the price no

        • Really? I guess vxWorks is an acquired taste then, because I'd be extremely happy to be given the opportunity to use vxWorks again.

          The last time I had to use it --- which, admittedly, was a while ago --- we had a requirement to do asynchronous I/O. VxWorks didn't support that, so we had to emulate it by using a pool of helper tasks each of which ran a blocking I/O operation. Unfortunately we had a further requirement that asynchronous I/O operations had to be cancellable, and the only way we could find of

      • How ironic, that Linux should now give it new life via emulation.

        Uh, no. Linux is going to give it a new lease on death this way. How many Windows users have been able to jump ship since Wine has actually become useful? If this delivers it will provide an upgrade path away from vxworks that allows a company to spend their time working on a port while using Linux as an interim band-aid.

      • They use Eclipse as their IDE now, so it's much better.

        They certainly much better than LynxOS (who also uses Eclipse as their IDE - but their plugin as not as well integrated by far)

      • Re: (Score:1)

        by Kilroy ( 2297 )
        The command line build tools are now headless Eclipse, which is eyegougingly frustrating. I just spend days trying to figure out why it was randomly giving Java Null Pointer exceptions while trying to do imports through the automated build system, but it won't fail while I'm running it manually or with debug tools attached. Flaming. Pile. Of. Poo.

        I can't wait to replace it with Linux, at least when that fails to compile code, it will probably do so every time and in the same place. Having the build sy

    • Re:Realtime, VxWorks, Dolla Dolla Bill Yall (Score:5, Informative)

      by Not Invented Here ( 30411 ) on Saturday March 22, 2008 @08:06AM (#22828682)
      The problem with VxWorks is that the scheduling accuracy is its only positive feature. Device drivers are rare and expensive, probably because it doesn't have a sensible hardware abstraction layer like Linux, Windows (NT family), and QNX. If you want to use the MMU on the processor you get charged again, and you get even more incompatibilities. The documentation doesn't go into much depth, and Google isn't very helpful, as hardly anybody talks about it on the Internet.

      Have you tried QNX or RTEMS? I don't have any data on their scheduling accuracy, but they claim to support the same real-time features. I've also found the QNX documentation much easier to follow, and I managed to turn out a BSP and a custom device driver within a week of first receiving the software.

      • Re: (Score:3, Insightful)

        by Epistax ( 544591 )
        I haven't had any experience with other systems yet really. VxWorks did add an abstraction layer for hardware drivers called "VxBus". So far the only advantage I've found is that.. Okay well I haven't found one but I did eventually get it to work. The advantage is they didn't break everything when they introduced it.

        I don't understand why WindRiver hates documentation to much. They actually have a policy of not sending hard copies of their manuals anymore. Their man pages are kind of half-assed. I us

    • Re: (Score:3, Insightful)

      by faragon ( 789704 )

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

      May be you need to play more :-) . LynxOS [wikipedia.org] is a full-fledged POSIX RTOS, with memory protection, far better than VxWorks if disk and network is involved (I was developing toll systems real time applications for 4 years). I hope someday Linux reach RTOS habilities without having to use "cokernels", as although I'm pretty happy with current kernel preemptiveness, I would love to get true RTOS Linux (echo 1 > /proc/rtos).

      • Re:Realtime, VxWorks, Dolla Dolla Bill Yall (Score:5, Informative)

        by joelsherrill ( 132624 ) on Saturday March 22, 2008 @08:58AM (#22828912) Homepage
        RTEMS [http] is a free, open source alternative to VxWorks that provides POSIX threads in addition to an API we call the "Classic API" that was based upon an old dead proposed VITA standard from pSOS+ folks. RTEMS is single process, multi-threaded in the POSIX sense and has almost every POSIX 1003.1b features that is possible without being able to exec a new process. We use GNU tools and maintain an APT/Yum repository so GNU/Linux users have an easy situation with the tools. Check out some of the places it has been used at http://www.rtems.org/flyers.html [rtems.org] and in the Wiki Applications page [rtems.org]. You can get predictable tasking and algorithmic behavior while still staying in the free software world.

        • Re: (Score:2)

          by faragon ( 789704 )
          Thank you.
        • There's also eCos [sourceware.org]:

          eCos is an open source, royalty-free, real-time operating system intended for embedded applications. The highly configurable nature of eCos allows the operating system to be customised to precise application requirements, delivering the best possible run-time performance and an optimised hardware resource footprint.

      • Re: (Score:2)

        by TheLink ( 130905 )
        There's also Tron, which is apparently quite popular in Japan and used in lots of embedded stuff.

        http://en.wikipedia.org/wiki/TRON_Project [wikipedia.org]

    • Re: (Score:3, Interesting)

      by K. S. Kyosuke ( 729550 )

      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 introduc

      • Re:Realtime, VxWorks, Dolla Dolla Bill Yall (Score:4, Interesting)

        by Epistax ( 544591 ) <epistax@gmail. c o m> on Saturday March 22, 2008 @08:34AM (#22828812) Journal
        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.
    • Have you tried QNX? I've found it really nice to use, though you still have to pay for commercial stuff. I've never worked with vxWorks but I've heard it's awful to work with in comparison.
      • IIRC, QNX is intel-only. At my company we like to use whatever chip is the best deal for the power we need. In 10 or so years, we've gone through 68030, 68040, 68060(?), PowerPC, and various Intel boards - all using VxWorks.

        • Re: (Score:2, Informative)

          by spaanoft ( 153535 )
          QNX used to be intel-only, but has been ported over to other chipsets. I know I've used it on an arm and some ppc before.

    • Re: (Score:1)

      by uwog ( 707498 )
      RTLinuxFree [rtlinuxfree.com] does this. The default scheduler is kinda lame (at least last time I hacked on it), but you can for example replace them with my DMI and EDFI [uwog.net] schedulers to get all the fancy features you describe, and more.

    • Re: (Score:3, Informative)

      by Esben ( 553245 )
      Linux with PREEMPT_RT is as predictable (but not as fast) as VxWorks in the mentioned categories, you just have to make sure that all the RT tasks have SCHED_FIFO or SCHED_RR to behave correctly. VxWorks doesn't have (or at least didn't in version 5.4-5.5 which I used to code for) SCHED_OTHER. And that is a huge drawback for VxWorks because very often you have a lot of application threads running with no hard deadlines and might fluctuate a lot in how much CPU they use (webserver and other user interfaces).

      • Otherwise one task suddenly taking a lot of CPU will starve all tasks with lower priority until it is done.

        I recently worked on a mobile phone platform (not based on VxWorks) which had a mechanism for sending messages to specific threads. There was a system wide 150-slot message queue. There was a background thread that ran at low priority that was supposed to do non-real-time things like UI work. This thread was a message receiver. The system did not support timeslicing.

        Can you see the problem yet?

        If

      • Re: (Score:2)

        by Animats ( 122034 )

        Good points. If you're doing an embedded hard real time system, you might need the small size and timing repeatability of VXworks. If not, you don't need VXworks at all. It's much easier to write to a POSIX interface. There's not much software for VXworks you'd want to port to Linux. So a VXworks wrapper for Linux doesn't meet any widespread need. Maybe someone needed it for a specific porting job, so it was worth doing once.

        I'd still like to see a real message passing system, like the one from QNX,

        • Re: (Score:2)

          by jmason ( 16123 )
          fwiw, I ported some QNX code to Linux a few years back, and wrote my own version of MsgSend()/MsgRecv() in a single .c file using UNIX-domain sockets. it's extremely simple, as long as you adopt the same limitations on portability (ie. writing raw C structs to the wire), lack of network support, and concurrency as the QNX message-passing has.

          QNX message-passing is nothing that can't be easily rewritten.
    • I've played with the Linux realtime extensions (preempt_rt) in a production environment and so far I've had good results. This is a very simple usleep test that shows how having the patch helps: http://wiki.freaks-unidos.net/weblogs/arhuaco/preempt_rt-test [freaks-unidos.net] You can use the SCHED_RR or the SCHED_FIFO scheduling algorithm for realtime applications.

  • What is the relationship with Xenomai? (Score:1, Interesting)

    by Anonymous Coward
    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 the
  • 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.

    • Re: (Score:1)

      by willgps ( 939538 )
      I guess that makes me a "nobody" then, since I have had the unfortunate pleasure of inheriting a project at work that attempts to shoehorn a vxworks project into linux via v2lin.

      Given enough time, I would love to chuck v2lin out altogether and access pthreads directly.

      Does anybody have any tips for surgically removing v2lin from legacy code?
  • 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 th

    • Why would you ever need to emulate an RTOS in linux?

      RTFA.

      imagine you're an embedded device manufacturer and suddenly you need to bump your device up from 64k chip of ram to 8mb.

      Imagine you've already got the 8 megs, and you still want things to happen in realtime. Oh, and you want to actually have drivers.

      Suddenly, things like VxWorks are going to cost you in licensing fees and development time, in return for... what, exactly?

      • Re: (Score:2, Insightful)

        by malevolentjelly ( 1057140 )
        Linux is not realtime. "Realtime linux" is a non-linux realtime OS with a non-realtime linux compatibility layer... emulating a REAL RTOS?... Why would you emulate a realtime system in a non-realtime system? Doesn't that defeat the purpose of a realtime OS?

        Do you have any idea why people use realtime systems?

        With VxWorks you pay license fees... FOR A REALTIME SYSTEM. You're also able to do a lot more with a lot less resources. In the embedded world, less is more! You save millions cutting kb's (or mb's) of

        • Do you have any idea why people use realtime systems?

          Yeah, pretty much.

          Software costs are just miniscule compared with the cost of making a bulky device with hardware that outclasses its functionality.

          ...aaaand it looks like you didn't read my post. Try again.

          • Imagine you've already got the 8 megs, and you still want things to happen in realtime. Oh, and you want to actually have drivers.

            But Linux is not realtime, so its drivers can't be realtime. Part of what makes a system realtime is the way its drivers are written. Realtime device manufacturers are generally expected to be writing their own drivers or using specifically realtime drivers for an RTOS.

            The moment anything passes through a linux kernel, it's no longer realtime. At best, it's "soft realtime" aka "realtime except for when it is not". For a realtime linux system to work, you'd have to run two kernels (linux and an RTOS) with t

            • I still don't see a hypervisor'd Linux being useless here -- or a Linux which has been modified such that certain parts of it are deterministically realtime (including drivers), and certain parts are not.

              Take a task which needs to be hard realtime, but for which you'd like to see reports. The task continues to operate at hard realtime, on whatever hard realtime layer is needed, throwing log messages into a ring buffer in a realtime-compliant, deterministic way.

              Another task, which doesn't need to be realtime

        • "Realtime linux" is a non-linux realtime OS with a non-realtime linux compatibility layer... emulating a REAL RTOS?...

          That was true in the past, but it is no longer true. The algorithms of the latest approaches to real-time Linux, when working together, actually do provide deterministic, hard real-time responses if the real-time parts of your application are coded appropriately. (By this, I mean that you don't expect a deterministic response when trying to use a service which isn't, such as a filesystem

          • Because the underlying Linux got better real-time properties since you last looked; the "non-realtime system" is now a mixed system with some real-time capabilities when requested.

            I see. With the understanding that this can't replace all applications where one might need an RTOS like VxWorks, I see where the VxWorks emulation could prove very helpful in porting applications to rich embedded systems like cell phones or set top boxes.

            In this case, the project must be very delicate in providing vxworks support while not stepping into any of these non-RT boundaries.

            Of course, I still come from the school of thought that recommends a re-write when switching from a true RTOS to a hybrid-R

            • In this case, the project must be very delicate in providing vxworks support while not stepping into any of these non-RT boundaries.

              You're right, and I will be very surprised if they get this right in all corner cases. The kernel is pretty complex, and the C library's threading implementation is also very complex. I expect by themselves these will have corner cases where RT properties are not maintained, without being clearly documented. So no matter how much effort the folks writing the vxworks layer

Slashdot Top Deals

To be is to program.

Close