Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linus Pooh-Pooh's Real-Time Patch

Posted by timothy on from the standoffish dept.

An anonymous reader submits "Speaking with CNet via email, Linus Torvalds appears to be in no hurry to accept the latest real-time patches from embedded specialist MontaVista into the mainstream kernel, at least not "at this time." Nontheless, MontaVista's new open-source real-time Linux project could broadly expand commercial opportunities for the open source OS, especially in telecom initially, where real-time Linux will likely play on "both ends of the wire." For example, Linux is already making progress in smartphones."

10 of 262 comments (clear)

  1. Patents ? by Anonymous Coward · · Score: 2, Interesting

    Wouldn't a real time patch violate software update patents

    1. Re:Patents ? by ryanmfw · · Score: 2, Interesting

      It's not a *real time patch*, it's a *real time* patch. It doesn't change the kernel while running, it changes the behavior of the kernel to be a real time one. I'm a little hazy on the difference, but I think it mainly has to do with scheduling, and that it will give high priority tasks all the time they need.

      --
      Hurricane Ivan: A 17th century prison collapsed. All of the inmates escaped.
    2. Re:Patents ? by Rosco+P.+Coltrane · · Score: 3, Interesting

      Perhaps Victor Yodaiken might want to pull another one of his lame patent stunts on Montavista. That'd be rather amusing actually...

      --
      "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
  2. Re:Better link by Anonymous Coward · · Score: 2, Interesting

    And a link to the Slashdot story where we discussed the real-time patches on Saturday.

  3. There are TONS of non-mainstream things there by MoralHazard · · Score: 2, Interesting

    Has anyone ever taken a look at some of the stuff available in the 2.6 configuration options? Do a 'make menuconfig' and browse through the "General Setup" and "Processor Type and Features" submenus. A bunch of it is wholly useless to 99.9% of the installations out there.

    But it's there as an option, if you want it, like most everything else. Have a tulip ethernet card? Include the driver. If you don't, leave it out. Old BIOS doesn't do ACPI? Leave it out. Don't need a keyboard driver because it's an appliance system? Leave it out.

    Why the hell not just include the real-time business as options? Is the maintenance really that much more challenging?

  4. Anyone finding this suspicious? by swordboy · · Score: 2, Interesting

    Here's something that Montavista has contributed to the Linux kernel - PRAMFS. A quote (emphasis mine):

    Many embedded systems have a block of non-volatile RAM seperate from normal system memory, i.e. of which the kernel maintains no memory page descriptors. For such systems it would be beneficial to mount a fast read/write filesystem over this "I/O memory", for storing frequently accessed data that must survive system reboots and power cycles. An example usage might be system logs under /var/log, or a user address book in a cell phone or PDA.

    [...]

    2. If the backing-store RAM is comparable in access speed to system memory, there's really no point in caching the file I/O data in the page cache. Better to move file data directly between the user buffers and the backing store RAM, i.e. use direct I/O.

    They've described that they want to use this stuff in a cell phone or PDA, yet have described an NVRAM technology that does not exist (as fast as system memory?). Methinks that they're working with Intel on some new fangled NVRAM, (hint, look for Ovonic). Samsung appears to be working with PRAM as well.

    So this MontaVista file system is a PRAM-File System, maybe...

    --

    Life is the leading cause of death in America.
  5. Alternatives? by Tellalian · · Score: 3, Interesting

    At the risk of sounding redundant, how is MontaVista's implementation significantly better or different from pre-existing real-time Linux interfaces, such as FSMLabs' RT Linux or DIAPM's RTAI?

  6. What is it needed for? by El · · Score: 2, Interesting

    What can an RTOS do that Linux can't that wouldn't be better handled in hardware? If responding to a given event is really THAT time critical, then perhaps you shouldn't be handing the event all the way up to your systems software for a response... In my experience, most problems that people claimed demanded "real time" to solve could be more easily solved by adding more buffers.

    --

    "Freedom means freedom for everybody" -- Dick Cheney

  7. Re:Can this be a config parameter? by ceswiedler · · Score: 2, Interesting

    The existence of the code in the main kernel, regardless of whether it is enabled at compile time, affects everybody. It's not like you're going to have a single place with

    #ifdef REAL_TIME_KERNEL

    ...lots of code

    #endif

    It's going to change a lot of things in a lot of places. Ideally, it will make infrastructure changes which benefit everyone, by abstracting certain elements of the code, which then makes its own specific features fit in nicely. Unfortunately, this is very difficult to do with real-time scheduling.

  8. Re:Barely a story. by SnowZero · · Score: 2, Interesting

    His job is to say no a few times, so that developers create better and better versions of the feature, until one is good enough and he says "yes".

    Kernel cleanly done kernel-preemption patch went in, but the "lock-break" patch which predated it did not . That's because the latter peppered "reschedule me" calls all over the code tree. If he hadn't said "no" the first time, the later clean solution probably would not have come.