Slashdot Mirror


Linus Pooh-Pooh's Real-Time Patch

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

12 of 262 comments (clear)

  1. Better link by Anonymous Coward · · Score: 5, Informative

    Direct link to they story.

  2. Re:Patents ? by d_jedi · · Score: 5, Informative

    RTFA.

    A hard realtime operating system is one where calls to the operating system are guaranteed to be executed within a certain timeframe.

    --
    I am the maverick of Slashdot
  3. Re:Might not be in a hurry.... by Elwood+P+Dowd · · Score: 5, Informative
    He might not be in a hurry, but I'd be surprised if he doesn't realize how this could help Linux.

    I'd be shocked if he didn't realize exactly how this patch would impact Linux. From the article:
    "Almost nobody wants hard real-time, even in embedded devices," Torvalds said in an e-mail interview. Adding the feature makes the operating system more complex and burdens the process of "locking," in which the operating system assures that different processes don't step on each others' toes when vying for the same resources.

    Asked whether MontaVista's proposed software could be accepted into the main kernel, he said, "I personally think it's too intrusive, at least at this point," though it might be possible to merge the patch into the kernel in smaller pieces.
    Iduno what else there is to discuss...
    --

    There are no trails. There are no trees out here.
  4. Real Time enhancements as a fork by Anonymous Coward · · Score: 5, Insightful

    I believe that it's appropriate to have a fork for realtime enhancements. I remember HP's philosophy in the 80's was to have a Real Time OS and a Business OS. They have competing goals. No need to blend them and end up with a compromise!

  5. Re:Linus is right. by Rosco+P.+Coltrane · · Score: 5, Insightful

    Come on, MontaVista, don't try to cock things up for the rest of Linux just because you're too lazy to patch the kernel yourself.

    There are many good reasons for contributors to merge their patches into the kernel. For one thing, it means you don't have to play catch-up with the kernel releases and manage the patch on top of it, and also you get to offer your code for free review and testing.

    As for why Linus is always reluctant to accept new code in the kernel? simple: Firstly, if he accepted all (good or less good) ideas into the kernel, the damn thing would make coffee already, and I don't blame him to want to narrow the kernel's focus. But most importantly, just look at the size of the flippin' tarball already and you'll see why he doesn't want to include forever code that'll serve less than 0.5% of all Linux users.

    --
    "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
  6. Re:Might not be in a hurry.... by skraps · · Score: 5, Funny
    Maybe he's just waiting for the right time, not the earliest time.

    Sooo.. Linus is real-time, but Linux is not.

    (yes, my jokes are that lame.)

    --
    Karma: -2147483648 (Mostly affected by integer overflow)
  7. It is the scope and magnitude of the patch by dmaxwell · · Score: 5, Insightful

    Historically, Linus has never liked merging in great glops of code that touch the kernel in many places. It is disruptive to his maintenance of the kernel and it is disruptive to his lieutenants and their sub projects. The article even hinted at how Linus expects those with a major patch like this to handle things. Montavista needs to break this up into bite size chunks that can be slowly merged into the kernel and gives everybody time to get up to speed. Since it can have a major effect on how the kernel operates, it needs to at least be a compile-time option.

    Linus has even told IBM "no" on occasion. Not hurrying things like this is far better for the quality of Linux than any feature a contributor may want in. Linus isn't flatly refusing Montavista. He most certainly isn't flatly refusing a major feature like hard real time. He is expecting Montavista to participate the way other developers are expected to participate. In particular, Montavista doesn't get to disrupt the work of hundreds of developers because their gargantuan patch was simply dumped in the main dev tree.

    This isn't petty dictatorship. The kernel devs are a battle scarred lot who don't just chuck things in because it would be "cool".

    1. Re:It is the scope and magnitude of the patch by bfields · · Score: 5, Informative
      Historically, Linus has never liked merging in great glops of code that touch the kernel in many places. It is disruptive to his maintenance of the kernel and it is disruptive to his lieutenants and their sub projects. The article even hinted at how Linus expects those with a major patch like this to handle things. Montavista needs to break this up into bite size chunks that can be slowly merged into the kernel and gives everybody time to get up to speed.

      Note also that the patch hasn't really even been submitted for inclusion. The Montavista people posted it to LKML with a lot of warnings, making it clear this was intended as a way to get early feedback on the direction of their project, rather than as an example of a finished implementation.

      So the slashdot headline is more than a little misleading; everybody agrees this is early in the process, and it's no suprise no-one's rushing to apply the patch.

      --Bruce Fields

  8. Poo Poos? by Swamii · · Score: 5, Funny

    What kind of smooth-it-over headline is this? Poo Poo? If this were Bill Gates instead of Linus, we'd say he's "blatantly ignoring", "throwing aside", "totally dismissing". But Poo Poo??

    --
    Tech, life, family, faith: Give me a visit
  9. Re:Linus "appears to be in no hurry to accept" by augustz · · Score: 5, Insightful

    The article and reporters may enjoy "fueling steam", they tend to enjoy stiring up controversy.

    Linus saying it looks too invasive at the moment for him to roll-in without other testing? NO ONE is going to fault him for that. Linux has gotten where it is because people can actually use it, in contrast to plenty of other experimental efforts.

    No one is going to think he is arrogant for doing his jobs. These patches can work their way into some feeder kernels first, and the usual cycle can work itself out.

    Too many uninformed folks like to say, "Fork!" or "Arrrogant!" without ever having actually maintained any type of code base.

    What the dear poster probably doesn't realize is that there are ALREADY real time Linux kernel varients in use out there, moving stuff mainline is hardly a fork, if anything montevista is trying to get out of the separate kernel maintenance business.

    Am I missing something obviou here?

  10. The rah-rah supporters are missing the real issue by The_Laughing_God · · Score: 5, Insightful

    There's a hard, probebly irremediable fact about Real Time Operating Systems: the price for being able to [i]guarantee[/i] a specific response time is a [i]slower overall response time[/i]. "Realtime" isn't magic (though, as with all buzzwords, people tend to act like it is). It still must heed all the inherent limitations of the hardware.

    Imagine that you run a pizza shop that MUST meet a certain delivery time guarantee or fail (go out of business--an RTOS MUST meet the guarantee to "be in business" at all). Before you were an RTOS, you could afford to promise pizzas in 15 minutes, with a 90%+ success rate, but if your head will roll if you fail at all, you won't advertise anything better than 30 -or even 60- minutes. I mean, what happens if a custom pizza gets ruined in the oven? You need time to make a new one.

    You'll also need more hardware for the same tasks (more delivery cars), restrict services (smaller delivery area, fewer options), and institute effort-intensive safeguards to assure that no pizza order slips through the cracks. As I said: RTOS isn't magic; adding NEW performance demands won''t magically enable you to do more with less. Quite the contrary, it usually means doing less with more -- but presumably doing it better (assuming that the new requirement *is* better for your specific needs).

    Would you embrace a hardware technology that slowed down your computers, and offered little or no benefit for most (or all) of the tasks you do? There are plenty of examples in he market, and we rightfully shun them as "unnecessary for us". That's the choice Linus faces: most users won't experience any benefit, so why include it in the kernel and make everyone pay the (performance and complexity) price?

    I applaud the availability of a Real-Time patch or variant (I've wanted one for a long time, and I've used Wind River for those applications), but for most people or even 99% of my applications, it's pure downside, even if reworking the kernel to allow its inclusion only decreases performance or complicates programming by 1%.

    Sure, in time --maybe a couple of years-- it may be streamlined until the RTOS burden is miniscule. Until then, Let the Real Time people deal with the issues and limitations inherent in their task. 99.99% of us don't need the unnecessary baggage in our OS. It'd be like mandating infan/child car seats in all cars, whether they carry kids or not.

  11. Re:Might not be in a hurry.... by DAldredge · · Score: 5, Funny

    I am almost sure that Linus stated policy on IP violations is to not give a flying fuck till someone bitches.