Slashdot Mirror

← Back to Stories (view on slashdot.org)

Postcard From The Real-Time Linux Workshop

Posted by timothy on from the hardcore-vs.-softcore-oops dept.

Kenneth J. Hendrickson writes: "I attended the 2nd Real-Time Linux Workshop this year on November 27-28, 2000 in Orlando, FL. It was held in conjunction with the 21st IEEE Real-Time Systems Symposium. RMS was the Keynote speaker. It was a fantastic event. I have published a report on it at the site of the Melbourne (FL) Linux User's Group." Thanks, Kenneth! This is a well-linked, informative report, and it shows how nicely GNU/Linux (RMS was the keynote speaker) can seep into what has traditionally been a heavily proprietary, expensive field.

4 of 39 comments (clear)

  1. Re:OK, I'll bite: by revbob · · Score: 3
    This isn't exactly responsive to your question, but here's one of my favorite definitions, from the DoD Glossary of Modeling & Simulation Terms:
    Real-Time System: A system that computes its results as quickly as they are needed by a real-world system. Such a system responds quickly enough that there is no perceptible delay to the human observer. In general use, the term is often perverted to mean within the patience and tolerance of a human user.
    The Jargon File says:
    real time 1. [techspeak] adj. Describes an application which requires a program to respond to stimuli within some small upper limit of response time (typically milli- or microseconds). Process control at a chemical plant is the {canonical} example. Such applications often require special operating systems (because everything else must take a back seat to response time) and speed-tuned hardware. 2. adv. In jargon, refers to doing something while people are watching or waiting. "I asked her how to find the calling procedure's program counter on the stack and she came up with an algorithm in real time."
    Rev. Bob "Bob" Crispen
  2. Is RMS going soft?? by Reality+Master+101 · · Score: 3

    I attended the 2nd Real-Time Linux Workshop this year on November 27-28, 2000 in Orlando, FL...

    Wait, you're telling me that RMS attended an event with Linux in the name rather than GNU/Linux, and he didn't a) boycott the event, or b) demand they change the name before he would appear?

    Clearly this was NOT the real RMS, and was an alien imposter.


    --

    --
    Sometimes it's best to just let stupid people be stupid.
  3. The first RTOS to offer this capability? by revbob · · Score: 3
    A goal for the near-term future is to be able to run real-time tasks in userland with all of the memory protections provided by unix, on all real-time Linux variants. Emanuele Bianchi has already done this on RTAI! Real-time Linux (as far as I know) is the first real-time OS to offer this capability.

    Er, not exactly. I was accomplishing the same result in a TCP/IP driver for an FDDI board I wrote for VxWorks back in 1990.

    Basically, you do at real interrupt level what you need to do there and stuff the functions that don't need to be done at real interrupt level into a ring buffer which then feeds a high priority task that fetches the function calls off its ring buffer one by one and executes them. As you exit your driver you call for a scheduling event. Because you can set hard, non-degrading task priorities, your cleanup task inevitably runs immediately. Other arriving messages are pretty much a don't-care (they interrupt the high-priority task), so long as you don't swamp your CPU with messages.

    For example, suppose you get a device interrupt from your network board. At real interrupt level you check to see if a packet has arrived, and if it has, you stuff it into mbufs (actually, clusters). You queue the rest of the packet processing (e.g., the IP function table calls) for your high priority "cleanup" task, and you call high-level stuff like non-blocking select() in your application.

    If you start off with a BSD-style driver, it's pretty easy to figure out what absolutely has to happen at real interrupt level and what can be thrown to a high priority task.

    Being able to write our own driver came in very handy, because we used a broadcast message over FDDI as a synchronization event. All the applications signed up a function that did a taskResume on their main executive whenever that message arrived. The high priority task checked each incoming message to see if anybody had signed up to run something when it arrived, and if so, ran it (probably by sticking it into the ring buffer for the next-highest priority task -- can't remember any more -- maybe I just ran it then).

    On a later version we got rid of some of the overhead by making the resumer function give a semaphore and had the executive wait for the semaphore at the bottom of its main loop. Since semaphores were queued, even if an application overran its time slot, it wouldn't lose a frame (within reason).

    It's good to see that real time Linux seems to climbing up to where it can stand alongside the RTOSs, and, having had a source license for VxWorks, I can testify that having source on hand makes a real difference in a crunch, not only to fix bugs, but to figure out work-arounds. Nobody's documentation is ever good enough, and the source code never lies.

    Rev. Bob "Bob" Crispen

  4. Memory protection possible in a RTOS? by ActMatrix · · Score: 3

    The article states "The real-time portions of a system run in kernel space in real-time Linux. Therefore, no memory protection can be offered. ... (Note: this disadvantage also exists for all other real-time OSes as well...)

    Is this really true? I'm no expert on real time operating systems, but I do know that several claim to have some memory protection, including QNX (highly recommended, btw) and Integrity, which I haven't tried. Perhaps I'm missing something, or is this report over-generalizing?
    ---