Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Real-Time Linux Developers Unite On API 57

Posted by Hemos from the agreement-is-good dept.
Markar writes "Developers and programers decided to support EL/IX by Cygnus Solutions as the API for Real-time Linux. Only one dissenter was counted after the vote was taken. The lone dissenter wanted to wait for further developements. PlanetIT is carrying more information. " You can also check out more information about the conference as well.
This discussion has been archived. No new comments can be posted.

Real-Time Linux Developers Unite On API More

Real-Time Linux Developers Unite On API

Comments Filter:

  • Re:Real Time System definition (Score:1)

    by Anonymous Coward
    Thank you. Could you also explain the difference/similarity between systems that are called fault tolerant and real time. As you know they have many similarities but different names.

    I got to be anonymous because I'm using up my moderator points on trolls.

  • Cygnus hype, really a power grab (Score:1)

    by Anonymous Coward
    The guys doing the actual RT Linux work are in New Mexico. Now that there is money involved the Cygnus people are putting out press releases trying to convince everyone that they are the center of development, when they are latecomers.

    I can assure you that the "concensus" about the Cygnus API was done behind closed doors, by people that already have an financial investment in the Cygnus approach. It is marketing over substance.

  • Right tool for the job. That's like using the top of a screwdriver to pound in nails.

  • Developers and programmers decided? (Score:1)

    by Anonymous Coward
    Then how come Slashdot doesn't know about this till now?

  • Re:Maybe I'm Crazy, But. . . (Score:1)

    by Anonymous Coward
    A real-time operating system is one that has to respond very quickly to incoming hardware events, usually with a constraint on the maximum time alloted to complete the response

    Minor correction. Realtime systems do not necessarily have to respond very quickly to a event. That just have to respond in time. If could be they have a hour to respond... but(especially hard realtime) but they must respond within the time.
  • So there's really nothing wrong with my system except that it's been programmed to ignore me?
  • It sounds as though you're describing tolerance of faults in hardware, but isn't software fault tolerance an important something that has to be anticipated and designed for as well? So that one failing program doesn't freeze or crash the entire system?
  • This story has a date March 13, and yet quotes last Wednesday as Dec 15, 1999.

    On the Real-Time Linux mailing list, this entire load of piffle was discussed in February, when EETimes ran an article [eetimes.com]. I'm sure you can find archives somewhere around http://www.rtlinux.org/ [rtlinux.org].

    Poor Mr. Wilshire was misquoted in the original article, and if you search for his emails in the archives, you will see the thread. Well, since I can't be bothered finding the URL, I'll post his message to the list verbatim.

    I have not asked permission to post this, so I hope that Mr. Wilshire will accept my apologies.

    Date: Tue, 15 Feb 2000 11:05:25 -0800
    From: Phil Wilshire
    To: Nicholas Mc Guire , "rtl@rtlinux.cs.nmt.edu"
    Subject: [rtl] Re: article on the Workshop

    Nicholas Mc Guire wrote:
    >
    > Hi All !
    >
    >http://www.eetimes.com/story/OEG19991220S0029
    >
    > VIENNA, Austria - Developers of embedded-Linux systems
    > ...
    > also decided to back Cygnus Solutions' EL/IX as a common applications
    > programming interface (API) for embedded Linux.
    >
    > Nearly 100 developers and programmers attended the grass-roots Real
    > Time Linux Workshop here last week, and all but one voted to proceed
    > with the use of EL/IX as their API.
    >
    > ...the other non-sense sniped...
    >
    > I conclude that there where two workshops in vienna
    > on that peter and me organized and obviously a second one
    > that we did not know of...
    > It is simply stupid to belive that puting fals information
    > out on the net will help push EL/IX as a standard API .
    > I guess a view people out there did not understand the
    > ideas of open source and even less the intent and spirit of the
    > realtime linux workshop in Vienna.
    >
    > since the article claims to be based on information from
    > phil whilshire maby he could comment on it .
    >
    > D'ehre
    > Der Herr Hofrat

    Willingly I will comment. There was some consderable misunderstanding in the way this article was presented.
    I was NOT allowed to see the results of a brief telephone interview and much that was printed was a shock to me.
    I do think that the statements about adopting EL/IX unchanged were inferred from another source.
    My statement was that we would work together with CYGNUS to help develop EL/IX into something we all could use.

    This is a warning to all of us not to accept telephone interviews and publication without prior approval of the result.

    I have been waiting for this backlash in the community and hope that my true motives in all this are clear. If one of us make a mistake we are, in general, merciless.


    I want Linux to succeed and I want Real Time Linux to succeed.
    i have devoted many man hours in my own time to helping the community in many ways.
    I want the Real Time Community to grow stronger and develop the way forward for this technology rather than leave it in the hands of commercial entities.
    This includes Cygnus.
    If they push EL/IX as the "Open Source" API and it bears no relationship at all to what is really needed then we all loose. We need to work together with everyone, Cygnus included, and produce what we need as an API. We also cannot present to the waiting users out there a confusing variety of API's. The Real Time Linux community is a very strong force we have what it takes to make this happen.

    I apologise to the community for any misrepresentation . Those that know me will confirm that I am VERY careful in making any such statements. I will continue to be even more careful in the future.

    I hope that we can resolve this with a simple public flogging.

    regards
    Phil Wilshire
    --- [rtl] ---
    To unsubscribe:
    echo "unsubscribe rtl" | mail majordomo@rtlinux.cs.nmt.edu OR
    echo "unsubscribe rtl " | mail majordomo@rtlinux.cs.nmt.edu
    ----
    For more information on Real-Time Linux see:
    http://www.rtlinux.org/~rtlinux/

  • Wow, that explaination seemed a lot shorter than the word count, because it turned out to be so informative. Thanks!...
  • ... that other standardized API's will be elected. If that's one thing we can learn about M$ is the easy app development. Except we benefit from the Open Source: no hidden API calls.
  • Sounds like a good enough excuse to me. :)
  • Of course. A 'system' consists of both hardware and software, and both have to work properly. Some systems even go a bit farther and try to compensate for 'wetware' failures -- that is, if the human who is controlling the system gives an order that the system decides must be a mistake, it will disregard it.

  • The way they do it is to implement a small real-time kernel, then run the linux kernel as a real-time process under that kernel. Then, userspace, non-RT linux process can communicate with the RT processes via either a mem-locked shared memory segment or a FIFO.
  • Ummm, the Lone Dissenter... err maybe not =P

    Seriously, though, it's really good to see developers that can actually agree on standards, even at later stages in Linux development. Unlike certain commercial projects I can think of.

    An API for embedded Linux will certainly help foster growth in the number of programmers that are willing to commit to it, for both OSS and commercial endeavors.

    How is progress coming on the Real-Time aspect? I've been a little curious to see how that's implemented. It seems that it would require some serious revamping of the kernel.

  • It's not VMS. VMS is in ALOT of places and has been for a LONG time.
    OS/9 or Concurrent maybe?
  • A real time OS is one in which every event is guarenteed to (responding to a signal, etc.) occur within a time constraint.

    Now there is hard-real-time and soft-real-time. A hard real time system guarantees
    When you deal with streaming video, you would like real-time performance, but it is not critical if a few frames are dropped here and there, so usually a soft real time sys is good enough. However, the system which deploys the airbag on your car, or guides cruise missiles, should probably guarantee to work within time bounds.
  • I should have previewed, multiple errors. Here is the fixed version.


    A real time OS is one in which every event (responding to a signal, etc.) is supposed to occur within a time constraint.

    Now there is hard-real-time and soft-real-time. A hard real time system guarantees that the event will occur in no more than x time (and no less than y) unless the system is down. A soft-real time system tries to meet those constraints, but it is not critical if it does and it might not meet them (soft is much easier to implement).

    When you deal with streaming video, you would like real-time performance, but it is not critical if a few frames are dropped here and there, so usually a soft real time sys is good enough. However, the system which deploys the airbag on your car, or guides cruise missiles, should probably guarantee to work within the time bounds.
  • You could look at http://www.rtlinux.com or at http://www.fsmlabs.com. EL/IX does not currently feature as part of our API roadmap. Tip: In the Linux world, one way to find out about Linux projects is to look in the MAINTAINERS file in the Linux source.
  • I suppose that the big question is, is this really a good move...

    I think that they really have a lot to offer each other... but I wonder if real time linux won't just sort of be eaten as an entity by cygnus.
  • > It's not VMS. VMS is in ALOT of places and has
    > been for a LONG time.

    But not for much longer - VMS is dead in the water and NT is taking over its workload fast.

    This is one gaping hole that Linux should be targeting but doesn't seem to be.

    > OS/9 or Concurrent maybe?

    He was probably thinking of VxWorks, which is rather cool but can hardly be described as unix (as it often is).

  • I seem to remember some other attempt at a real-time version of an OS that crashed and burned pretty bad...I can't remember the name. May have been VMS, I don't know...anybody else?
  • what is the current state of real-time extensions in Linus's kernel source? Any Alan Cox diffs?
  • I have recently started playing around with an operating system called Amoeba. Originally developed in the Netherlands, Amoeba has some amazing features. Amoeba has all the right seeds to start up a new kind of distributed operatin system. It's ability to be implemented on multiple machines pooling CPU power sounds like an advantage in server clustering problems. Why run software to cluster when you can have an OS which has kernel supports clustering right away.. in a terrific fashion... Amoeba... check it out.
  • This really sounds like marketting hype from RedHat/Cygnus. I've heard nothing from Lineo and the other embeded Linuxes. What about Bluecat/Lynx? Where are the others? We should also remember that EL/IX was not developed as a standard Linux embeded API, but as a eCos/Linux API, eCos being Cygnus's own Free embeded OS.
  • Great. The realtime Linux world has settled on the EL/IX API. But what does it actually do? How does it affect the Linux kernel? Is EL/IX a library that sits on top of the kernel, or is it part of the kernel itself? Does it replace the standard system calls, or merely augment them (perhaps with calls for controlling the realtime-ness of a process)? From the point of view of an application writer, how different will an EL/IX Linux system be from regular Linux?
  • Soft realtime (the announcement in the article regards hard realtime; see other comments for the distiction) generally does good enough. I'm in the habit of running my X server and window manager with realtime priority on slower machines (when I'm not doing anything else compute-intensive that I care about). It does make a big difference in that regard -- where the problem actually is CPU contention, anyway...

    So, it's not a matter of starting over, just a matter of selecting another one of the existing Linux schedulers. (this operation is NOT, I repeat NOT synonymous with nice(2) -- see sched_setscheduler(2) and friends)

    I actually wrote a set of tools that allow you to manipulate the realtime schedulers under Linux (soft realtime was introduced in Linux 1.3.something, if I remember correctly), and they're on freshmeat as rt-utils.

    The homepage, and download links are out-of-date, but I'll get around to dealing with that soon. In the meantime, if you want a copy, drop a line to mental@rydia.net

  • There must be an IPO involved. Every time there's an IPO involved stories disappear from Slashdot without a trace or an explanation.
  • > I keep seeing stuff about Real-Time
    > Linux/programming/OSes etc. - but I still
    > ahve no clue what the heck it is. Could
    > someone please explain, in simple terms,
    > what it is that all these articles are
    > refering to?

    A real-time operating system is one that has to respond very quickly to incoming hardware events, usually with a constraint on the maximum time alloted to complete the response. While a conventional OS (like Linux in normal operation) offers no guarantees on how quickly it will respond to requests (usually very quickly, but under high load a request could be deferred quite a while), a real-time OS usually offers guarantees on performance.

    Real-time is subdivided into "hard" real-time (an absolute guarantee on system response, usually harder to accomplish) and "soft" real-time (an average-case guarantee with a certain degree of variance.)

    Real-time processing is most common in things like embedded systems ("fly-by-wire" computers on airplanes, for instance, had better not take too long to process requests!), but occasionally real-time shows up in a userland/PC environment (audio processing, scientific equipment monitoring, etc.)

    Hope this helps...

  • I keep seeing stuff about Real-Time Linux/programming/OSes etc. - but I still ahve no clue what the heck it is. Could someone please explain, in simple terms, what it is that all these articles are refering to?
  • it's too late for this kind of crap... I can't even make sense of your bullish hokey-pokey at this hour.

    -----------

    "You can't shake the Devil's hand and say you're only kidding."

  • A realtime system is one where you have a fixed amount of time to deal with an event, after which the data is either useless, or something has goon wrong. For instance if you are doing audio signal processing in real time (ie, live) if you cannot generate the next output sample by the time the DAC wants it, you have to punt on that sample. In that case, losing an occasional sample is tolerable, in others, you must do *something*. An OS designed for these applications needs to have properties of bounded + known latency on every operation, and be able to guarantee that each process will be scheduled in time.
  • A real-time system is one that guarantees certain processes a certain amount of computation per unit of time, or that a certain process will finish by a certain time. This can be used to guarantee that a sound gets played without skipping, or that a video gets played without any pauses. People doing embedded stuff can use it to guarentee that their device does what it needs to do at the right time. Bad things can happen if an embedded system doesn't do something fast enough because of processor load. Basically, it is a system that is aware that somethings need to be done in a certain amount of time to be correct.

  • Re:Real Time System definition (Score:3)

    by sec ( 20916 ) on Monday March 13, 2000 @07:50PM (#1205081)
    Fault tolerance is actually a much simpler concept than realtime, but just as hard to implement. :P

    A fault tolerant system is a system in which the designers have anticipated some of the ways in which a system can fail, and designed the system to keep on functioning, at least at some level, in spite. An example of this would be redundant hardware -- if, for example, one power supply fails, the system has a backup power supply that will take over.

    Fault tolerant systems are not necessarily realtime -- for example, a lot of servers have some degree of fault tolerance built in. Real time systems are not necessarily fault tolerant either, but in practice, since realtime systems are often used in places where a failure would be catastrophic (ie. the control system of an airplane) it would be a very wise idea to design some fault tolerance into them.

  • Re:What is... (Score:4)

    by Mark J Tilford ( 186 ) on Monday March 13, 2000 @06:49PM (#1205082)
    Well, if you're using a text-editor, it doesn't matter whether the editor gets 10ms CPU time every 100 ms or 20 ms every 200 ms, it's the same average, as long as it can keep up with your typing. If some other program has a sudden surge of CPU usage and it doesn't get any CPU time for a few seconds, it doesn't matter.

    Now, say, that program is controlling the flight of an airplane, and the computer has to make 10 ms of corrections every second or the plane crashes.

    Now, there is a big difference between getting 14 ms every second and 50 ms every 2 seconds; in the latter case it will crash, even though it gets better average CPU time. If a program other than the flight control has a burst of CPU usage....

    In other words, it's more important to have a guaranteed rate of computation than a high average rate.

    A real-time OS is one where a program can be started and told "Make sure this program gets at least -- CPU time every -- real time", and the OS will only run it if the program if it can guarantee giving it that much CPU time.


    -----------

  • Don't forget... (Score:4)

    by Shotgun ( 30919 ) on Tuesday March 14, 2000 @04:10AM (#1205083)
    Real-time doesn't just mean guaranteed processor bandwith. The response time is bounded. This is important.

    Consider an automated assembly line application such as a sorter. A reader reads a bar code and sends a package down 1 of 10 lines. If a timer is used to control when an actuator will push the box off the line, the timer better not pop too early or the box won't be there yet.

    I know this example is contrived, but it is the best I could think of in a short time. The basic point is that in a real-time OS the computer not only has to respond within a specified time, but that time is bounded so that the computer can't respond before the specified time either.
  • This seems to be a warmed-over version of the POSIX real-time extensions, circa 1995. Interprocess message-passing operations (a classic weak point in UNIX variants) aren't taken as seriously as they are in QNX or L4. The architecture encourages putting the entire real-time application in one address space, with multiple threads. And device drivers are still part of the kernel.

    It's reminiscent of MERT, the first UNIX real-time variant, from the 1970s.

  • Real Time System definition (Score:5)

    by sec ( 20916 ) on Monday March 13, 2000 @06:53PM (#1205085)
    Since some people are asking what a realtime system/OS is, here goes:

    A realtime system is a system in which the response time of the system to an external event is predictable and bounded. That is, if a user presses a button, a realtime system will guarantee that the system takes whatever action is associated with that button press in a given time, or less.

    This does not necessarily mean that the system is fast or responsive. For example, the design spec could say that if the user presses the button, the system must respond in 5 seconds or less. As long as the system always responds within 5 seconds, it is still a realtime system, even though most people wouldn't think of it as such.

    If the system fails to respond within the specified time frame, it is considered a design failure. As such, it is used mainly in things like industrial or vehicle control systems, where failing to respond within the specified time can have catastrophic consequences.

    A realtime OS is simply an operating system designed for use in realtime systems. Because of strict constraints on response times, some harsh tradeoffs must be made -- ones that users of desktop and server operating systems would find hard to fathom.

    For example, a realtime filesystem is very difficult, if not impossible, to design, because some filesystem operations can have a potentially unbounded completion time. Usually, any processor cache is disabled, because, although the cache greatly decreases the average execution time, it can actually _increase_ the worst-case execution time, and it makes it very difficult to determine how long a piece of code is going to take to execute.

Slashdot Top Deals

"Sometimes insanity is the only alternative" -- button at a Science Fiction convention.

Close