Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software Linux

Linus Pooh-Pooh's Real-Time Patch 262

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

Linus Pooh-Pooh's Real-Time Patch More

Linus Pooh-Pooh's Real-Time Patch

Comments Filter:

  • Better link (Score:5, Informative)

    by Anonymous Coward on Wednesday October 13, 2004 @03:49PM (#10517285)
    Direct link to they story. [com.com]

    • Re:Better link (Score:2, Interesting)

      by Anonymous Coward
      And a link to the Slashdot story [slashdot.org] where we discussed the real-time patches on Saturday.
    • Here's something that Montavista has contributed to the Linux kernel - PRAMFS [sourceforge.net]. 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 use

  • Patents ? (Score:2, Interesting)

    by Anonymous Coward
    Wouldn't a real time patch violate software update patents

    • Re:Patents ? (Score:2, Interesting)

      by ryanmfw ( 774163 )
      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.

    • Re:Patents ? (Score:4, Interesting)

      by Rosco P. Coltrane ( 209368 ) on Wednesday October 13, 2004 @03:54PM (#10517354)
      Perhaps Victor Yodaiken might want to pull another one of his lame patent stunts [linuxdevices.com] on Montavista. That'd be rather amusing actually...

      • Re:Patents ? (Score:4, Informative)

        by pavon ( 30274 ) on Wednesday October 13, 2004 @04:09PM (#10517533)
        Uhm, no. He has given an irrevocable, royalty-free licence [fsmlabs.com] for it's use in GPL'd software. Montavista RT Linux is GPL'd. Besides if you read the patent you will see that it is for something that has nothing to do with Montavista's code. Yodaiken's approach was to run the linux kernal as a process of a smaller realtime kernal, and it is that technique that he patented. Montavista is modifying the Linux kernal itself to be run-time, which is a much more difficult task, and would not infringe on this patent whatsoever.

    • Re:Patents ? (Score:5, Informative)

      by d_jedi ( 773213 ) on Wednesday October 13, 2004 @03:54PM (#10517356)
      RTFA.

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

  • is Linus ever in a hurry? (Score:2, Funny)

    by Anonymous Coward
    - i don't think so!

  • RTOS (Score:4, Informative)

    by darth_MALL ( 657218 ) on Wednesday October 13, 2004 @03:51PM (#10517309)
    I learned something new!
    Real Time Operating Systems. [wikipedia.org] Now you know!

  • Might not be in a hurry.... (Score:3, Insightful)

    by ryanmfw ( 774163 ) on Wednesday October 13, 2004 @03:51PM (#10517311)
    He might not be in a hurry, but I'd be surprised if he doesn't realize how this could help Linux. Maybe there are some stability problems with it, but then, I doubt that too. Does anyone have any experience with it? Maybe he's just waiting for the right time, not the earliest time.

    • Re:Might not be in a hurry.... (Score:5, Informative)

      by Elwood P Dowd ( 16933 ) <judgmentalist@gmail.com> on Wednesday October 13, 2004 @03:58PM (#10517416) Journal
      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...
      • Oh. That's exactly what you said. I can't read.

      • Re:Might not be in a hurry.... (Score:5, Insightful)

        by metlin ( 258108 ) * on Wednesday October 13, 2004 @04:05PM (#10517496) Journal
        I'm guessing that maybe he has his own reasons that he does not want to divulge?

        Especially given the current sue-happy folks who're looking at suing everything that is Open Source, maybe Linus is just playing it safe.

        For all you know, he's trying to see if there are any IP violations before accepting them into the code-base. You never know.

        • Re:Might not be in a hurry.... (Score:5, Funny)

          by DAldredge ( 2353 ) <SlashdotEmail@GMail.Com> on Wednesday October 13, 2004 @05:36PM (#10518422) Journal
          I am almost sure that Linus stated policy on IP violations is to not give a flying fuck till someone bitches.

        • Actually, the article hints at Linus' mastery of the issue by clueing the reader in on a few consequences of hard real time systems. The problem is that while the OS would be capable of guaranteeing a response within tens or hundreds of microseconds, the overall response time of the system is reduced. Linus is quoted as saying he believes most people, even in the embedded space, don't want this as a standard feature of the OS. This is because there's a comparatively easy fix for getting quick response ti

        • For all you know, he's trying to see if there are any IP violations before accepting them into the code-base. You never know.

          Very unlikely. With respect to copyrights, Linus requires contributors to take responsibility for the ownership of their contributions, and takes them at their word. He doesn't really have any way to do anything else since our screwed up copyright regime provides protection to unpublished works -- so how could he even check? Same holds with trade secrets. With respect to paten

    • Re:Might not be in a hurry.... (Score:5, Insightful)

      by irokitt ( 663593 ) <archimandrites-iaur.yahoo@com> on Wednesday October 13, 2004 @04:02PM (#10517460)
      Not stability, complexity and responsiveness. Adding real-time elements to the mainstream kernel means that priority tasks get executed first, but the average time taken to finish a task is significantly higher. The result would be an excellent system for medical equipment or ilk, but it would make a sluggish desktop or server, and most Linux devices now are desktops or servers. And the complexity of adding this in would only be justified if it benefitted a lot of people. So Linus is waiting to see how things look a little later. It should be possible to create a custom kernel that uses these features, but they don't belong in the vanilla kernel yet.

    • Re:Might not be in a hurry.... (Score:5, Funny)

      by skraps ( 650379 ) on Wednesday October 13, 2004 @04:12PM (#10517563)
      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.)

    • Re:Might not be in a hurry.... (Score:5, Insightful)

      by richg74 ( 650636 ) on Wednesday October 13, 2004 @04:16PM (#10517602) Homepage
      He might not be in a hurry, but I'd be surprised if he doesn't realize how this could help Linux.

      I'd suggest the reason he is not in a hurry is that he does realize how this could help Linux, and also how it could hurt Linux. Adding real-time capability is not a free lunch.

      As the original C|NET article suggests, there is a class of applications that need real-time capability (which, BTW, is mostly about being able to say that interrupt X will be handled in not more than N time units). But for most applications, real-time capability is neither needed nor really desirable: having it comes at a cost in average processing efficiency.

      Incidentally, telecoms is mentioned as a possible application. I don't know enough about cellular telephony to say if it fits, and maybe there are some VoIP applications where it would make sense. But for conventional circuit-switched telecoms (e.g., a telephone switch), it really is not needed.

      • Re:Might not be in a hurry.... (Score:5, Insightful)

        by AaronW ( 33736 ) on Wednesday October 13, 2004 @06:39PM (#10518915) Homepage
        At my company we are using Timesys embedded Linux for its real-time options. For telecom, it is absolutely necessary to have real-time in many cases. I.e. if a packet is delayed, it will cause a glitch in the audio or somesuch. The major problem we have with Timesys is that their kernel is a bit out of date (2.4.18) and is missing some critical patches and that they have not applied their changes to the 2.6 kernel tree.

        Other things are things like priority inheritance support, to prevent problems caused by priority inversion (which caused problems in the original Mars rover).

        For voice support, if you don't mind crappy sound or are only handling one or two calls, you can get away without real-time, but for serious use, it is essential.

        Maybe for control path processing it isn't essential, but as soon as it becomes part of the data path, real-time is essential.

    • It is the scope and magnitude of the patch (Score:5, Insightful)

      by dmaxwell ( 43234 ) on Wednesday October 13, 2004 @04:16PM (#10517605)
      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".

      • Re:It is the scope and magnitude of the patch (Score:5, Informative)

        by bfields ( 66644 ) on Wednesday October 13, 2004 @05:14PM (#10518196) Homepage
        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

    • The only way it would help Linux is if it could be totally compartmentalized, such that:
      • "Regular" users could disable it in its entirity (and not be burnened by it slowing the rest of the system down) AND where...
      • "Power" users who specifically need Hard Real-Time could enable it in its entirity AND where...
      • The kernel is not so heavily bloated with the multiple ways of doing things that the kernel becomes less reliable AND where...
      • The different paths are sufficiently independent, such that if the path
    • I would agree . . . there are lots of applications in manufacturing that depend on realtime applications. Though safety and mission critical apps are still on more fault tolerant Sun, HP-Risc, and big IBM boxes, many of them are moving to the kludgy WinTel monopoly because of easy of maintanence and lower hardware cost. Windows has really made huge inroads on the client side of these large control systems . . . and they are slowing taking over the server side OS.

      I think that Linux has a real opportunity

  • Linus is right. (Score:4, Insightful)

    by Power Everywhere ( 778645 ) on Wednesday October 13, 2004 @03:54PM (#10517363) Homepage
    Linus is right not to accept this patch into the main kernel tree. What this would amount to is shoehorning Linux into a shoe it's too large to fill, and there is absolutely no reason burden all other Linux distros with this mess. 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.

    • Re:Linus is right. (Score:5, Insightful)

      by Rosco P. Coltrane ( 209368 ) on Wednesday October 13, 2004 @04:01PM (#10517451)
      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.

      • Re:Linus is right. (Score:5, Insightful)

        by 4of12 ( 97621 ) on Wednesday October 13, 2004 @05:11PM (#10518180) Homepage Journal

        why he doesn't want to include forever code that'll serve less than 0.5% of all Linux users.

        If the patched Linux goes into embedded devices there is a much bigger market than for conventional servers and desktop computers.

        The millions of current desktops and servers could become 0.5% of all Linux users if embedded devices run Linux.

        But I still agree that Linus' go-slow approach is wise and judicious.

    • Hmmm... (Score:3, Insightful)

      by temojen ( 678985 )
      What makes you think it wouldn't just be annother kernel config parameter to most people?

      • Re:Hmmm... (Score:3, Insightful)

        by Mysticalfruit ( 533341 )
        Because it's not.

        It's not just adding support for a filesystem. It's fundimentally changing how the kernel creates and schedules userland processes and kernel threads, prioritizes I/O, allocates memory and handles interupts. This in turn has a ripple effect on how applications work.
      • What makes you think it wouldn't just be annother kernel config parameter to most people?

        From what I understand of it, the issue is that it is a big chunk of code that touches and changes the core kernel code in many many places (which naturally has a lot of flow on effects down the line). That makes it a lot harder to make it a single config switch. I understand Linux is not fundamentally opposed, just opposed to trying to merge the patch in its current form in. I series of smaller modularised patche

    • Re:Linus is right. (Score:3, Insightful)

      by johannesg ( 664142 )
      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.

      Aren't they just being good citizens by offering up their patches for inclusion? You know, like that GPL thing says they should?

      • Re:Linus is right. (Score:3, Informative)

        by reynaert ( 264437 )
        Aren't they just being good citizens by offering up their patches for inclusion? You know, like that GPL thing says they should?

        Just to fight this stupid urban myth: The GPL doesn't say that. Please read at least the FAQ [gnu.org]. kthx.

      • Aren't they just being good citizens by offering up their patches for inclusion? You know, like that GPL thing says they should?

        That's not what the GPL says they should do. The GPL specifies that, if they redistribute a program, or any other work, based on the source code of Linux outside of "fair" uses [wikipedia.org] allowed by law, then that program or work must be licensed under the terms of the GPL as well. MontaVista could fork the kernel and provide their version of Linux as Montix under the GPL. Nothing say

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

      If you read MontaVista's original announcement, it was not posted for inclusion in the mainstream kernel, no one (including MontaVista) is claiming that it is ready. They merely posted their work to stimulate discussion and to avoid duplication of effort. So of course Linus is right, no one ever said it _should_ go in the kernel now or even anytime soon.

      Why was this modded "I

  • Barely a story. (Score:5, Insightful)

    by Elwood P Dowd ( 16933 ) <judgmentalist@gmail.com> on Wednesday October 13, 2004 @03:56PM (#10517381) Journal
    Linus' job is to say no. Here, he even gives rationale.
    • linus is not always correct.

      remember how linus stonewalled loadable modules?

      • Re:Barely a story. (Score:3, Interesting)

        by SnowZero ( 92219 )
        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.

  • Blackadder quote (Sorry, I couldn't resist) (Score:4, Funny)

    by lxs ( 131946 ) on Wednesday October 13, 2004 @03:58PM (#10517409)
    Gen. Melchett: Is this true, Blackadder? Did Captain Darling pooh-pooh you?

    Cpt. Blackadder: Well, perhaps a little.

    Gen. Melchett: Well then, damn it all, how much more evidence do you need? The pooh-poohing alone is a court-martial offence!

    Cpt. Blackadder: I can assure you, sir, that the pooh-poohing was purely circumstantial.

    Gen. Melchett: Well, I hope so, Blackadder. You know, if there's one thing I've learned from being in the army, it's never ignore a pooh-pooh. I knew a major: got pooh-poohed; made the mistake of ignoring the pooh-pooh -- he pooh-poohed it. Fatal error, because it turned out all along that the soldier who pooh-poohed him had been pooh-poohing a lot of other officers, who pooh-poohed their pooh-poohs. In the end, we had to disband the regiment -- morale totally destroyed ... by pooh-pooh!

  • Linus "appears to be in no hurry to accept" (Score:4, Insightful)

    by chance2105 ( 678081 ) on Wednesday October 13, 2004 @04:00PM (#10517428)


    Is it just me, or does this article sound like it's fueling steam for a fork of Linux development? If not adding steam for a fork, I have to say it's arrogant ...

    • Re:Linus "appears to be in no hurry to accept" (Score:5, Insightful)

      by augustz ( 18082 ) on Wednesday October 13, 2004 @04:22PM (#10517663)
      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?

  • Real Time enhancements as a fork (Score:5, Insightful)

    by Anonymous Coward on Wednesday October 13, 2004 @04:01PM (#10517443)
    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!

  • Probably because it's not "integrated" enough? (Score:2, Insightful)

    by Anonymous Coward
    RTLinux takes executive hold of the system and runs the Linux kernel as a mere user process.

    Perhaps Linus objects to this topsy-turvey approach and would prefer Linux to be re-written so it's actually completely preemptible, capable of handling interrupts with RT guarantees all by itself, etc?

  • From LKML (Score:4, Informative)

    by OverlordQ ( 264228 ) * on Wednesday October 13, 2004 @04:03PM (#10517477) Journal
    Dunno if this is even slightly relavent at all but this is from one of the other people doing Prempt things with the kernel.

    finally, i went for correctness primarily, not latencies. I checked
    out the MontaVista patches and they categorize roughly 30 spinlocks
    as the ones that are necessary to be 'raw'. Unfortunately this is
    inadequate, my patch excludes 90 such locks and it's still probably
    not a 100% correct conversion. The core kernel needs changes in the
    locking infrastructure to get rid of most of the these 90 non-mutex
    locks.
    • Could you explain what a spinlock is? Also, what is a non-mutex lock? Please excuse my ignorance.

      • Re:What's a spinlock? (Score:5, Informative)

        by Latent Heat ( 558884 ) on Wednesday October 13, 2004 @06:06PM (#10518679)
        A spinlock, generally, is a loop of the form

        while (CheckOKtoProceed());

        You see, the program "spins" until CheckOKtoProceed() returns true. The alternative is a call to a Yield(), Wait() or Sleep() function that 1) blocks execution until some condition is satisfied, and 2) tries to yield control to some other pending process while that is happening.

        The trouble with a spin lock is that it hogs the processor. The trouble with the other kind of lock is that it allows another process to proceed, but it may not be safe to allow that on account of a data structure not being in a coherent state of update. A mutex is a kind of lock that by agreement of its use allows only one such process to proceed. A non-mutex lock doesn't offer such protection.

        The argument is that the proposed modification make the kernel much more preemptable and do less spin locking that can kill response, but each element of the proposed modification would need to be checked and tested very carefully that after the change there aren't issues regarding the protection of data structures from multiple processes that could change it along with all kinds of mind-bending subtle bugs that can arise.

  • Links to better KernelTrap articles/email threads (Score:5, Informative)

    by dominator ( 61418 ) on Wednesday October 13, 2004 @04:10PM (#10517544) Homepage
    From the email threads and writeups on KernelTrap, it seems as though Linus (and his Lieutenants) have some issues with the invasiveness and maintainability of the patch, which are reasonable concerns from the maintainers.

    Ingo Molnar - a RedHat employee/kernel hacker - has some patches that are similar in scope but different (and most likely preferable from a performance and maintainability viewpoint) in approach.

    Read about them here and form your own opinion:

    Linux: Real Time Kernel Prototype [kerneltrap.org]

    Linux: Realtime Preemption [kerneltrap.org]

  • Another unexplained submission? (Score:3, Funny)

    by retinaburn ( 218226 ) on Wednesday October 13, 2004 @04:11PM (#10517553)
    First we had a post on Hibernate [slashdot.org] with no explanation. Then a post on OQO [slashdot.org] and now we have one on 'Linux'. When will the madness end?!?!? ;)
  • When this was first [slashdot.org] mentioned I had a feeling this *patch* wasn't approved. It was spoke of as if it had all but been accepted.

    I cannot wait till this functionality does finally make it into the kernel though.

  • Poo Poos? (Score:5, Funny)

    by Swamii ( 594522 ) on Wednesday October 13, 2004 @04:17PM (#10517611) Homepage
    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??
    • Its the kind of smooth it over headline about a penguin fanatic who shrugged off putting something in his branch of a free, open, and readily forkable bit of software.

      Billy G isn't doing Windows for the kudos of it, hes making money and stimulating an economy of babysitting a broken closed and not readily fork and fixable bit of software. And he has enough money that he can prolly buy you off if you dare suggest he Poo Poos anything.

      All things being equal, this wouldn't be noteworthy.
      • They never submitted a patch to Linus, they simple posted it on the LKML to get people's opinions, testers, developers, etc. They also had many warnings about the code may not be complete.

  • News flash: (Score:3, Funny)

    by lpangelrob2 ( 721920 ) on Wednesday October 13, 2004 @04:18PM (#10517619) Journal
    Tigger said to be hopping mad in protest; Piglet leading soft-spoken sit-in. Honey at 5:00.

  • There are TONS of non-mainstream things there (Score:3, Interesting)

    by MoralHazard ( 447833 ) on Wednesday October 13, 2004 @04:19PM (#10517631)
    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?

    • Answer: (Score:5, Informative)

      by warrax_666 ( 144623 ) on Wednesday October 13, 2004 @04:48PM (#10517945)
      Is the maintenance really that much more challenging?

      Yes. All the other obscure things which only 0.1% of everybody uses, they are small isolated pieces of code (like some random driver). What we're talking about here is adding lots of highly non-trivial code to the core of linux (you know the kernel/ subdirectory of the kernel source) which only 0.01% of people will actually need/use. So, yes.

      I also think it would be quite arrogant of the RT people to expect this to be added without serious thought (and possible reworking). (NOTE: I'm not saying they do/did expect it to, just that it would be arrogant to do so)

    • Re:There are TONS of non-mainstream things there (Score:5, Insightful)

      by discord5 ( 798235 ) on Wednesday October 13, 2004 @05:10PM (#10518174)

      Let me start out by saying that I'm not a kernel developer, as are most people on /., but I do get to maintain some C and C++ code on a regular basis.

      A lot of the stuff in 2.6 may be useless to most people, but it's there because it's being maintained, is 99% stable and compatible with the current kernel ABI. You see, thread locking in general is a complicated matter, and I can only imagine how complicated all the locking code in the kernel is.

      The RTL patch does some major adjustments to the internals of the linux kernel, and from what I gather has been just dumped into Linus' and co's mailbox. This is simply not done in ANY development project. Maintainers don't accept huge patches that change stuff everywhere on the belief that source code works. Hell, if there's a lock somewhere that isn't freed in some exceptional case your shiny new version of software X grinds to a halt often leaving end-users scratching their heads and developers gritting their teeth.

      I was on a development project once where one of the coders had an inspirational idea and rewrote some shabby but working code into (what he called) clean and efficient code. It was a hefty patch and didn't break the program at first. But due to a bug in thread locking in "some" conditions, only 2 months later we found out some really nasty things about this "clean and efficient" code. Alas, it was too late to revert to our old model, and eventually spent a lot of time debugging and banging our heads against the wall. The guy was fired.

      The point I'm trying to make is that you shouldn't judge people for being wary of accepting large globs of patches for software that already works great. Sure, linux can benefit a lot from this if it provides a foot in the door of telecom, but at the moment it's being used actively in many other areas. This article just seems bent on critisizing Linus for not including something because he believes there may be issues.

  • Real time Linux could win the house. (Score:3, Informative)

    by grunt107 ( 739510 ) on Wednesday October 13, 2004 @04:25PM (#10517691)
    Having smart appliances and energy controls securely networked would be a boon to Linux. The real-time kernel would allow speedy monitoring of these type of devices.
    • Unless all those devices are physically wired to the Linux machine, I doubt real time processing would make much difference. Smart appliances are probably going to use some wireless technology. The buffers on the controller's wireless interface is going to catch (and queue) all the events and they'll be processed in a timely manner. You don't need to have a sensor tell you that your house temp dropped a degree, and immediatly turn on your furnace. Even a second or two wouldn't matter.

      Now, if you were cont

  • Alternatives? (Score:3, Interesting)

    by Tellalian ( 451548 ) on Wednesday October 13, 2004 @04:28PM (#10517723)
    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 [fsmlabs.com] or DIAPM's RTAI [rtai.org]?

    • Re:Alternatives? (Score:3, Informative)

      by Voivod ( 27332 )
      Montavista's approach just involves patching the standard kernel to try to improve its behavior. This gets you soft real-time, but getting provable hard real-time is tough via this route due to the complexity of the kernel.

      RT-Linux (and RTAI which is roughly based on RT-Linux but offers a different API) is very different. It runs as a hard real-time micro-kernel which takes over your system and then runs all of Linux as a thread. When you run your hard real-time code it runs in that micro-kernel space r
  • A couple of years ago I worked on an embedded linux project, and we used the linux real-time and pre-emptive patches on the target. We actually applied the same patched to kernel of one of the development workstations to see if we could notice any difference, and within 15-minutes of booting, those that could were recompliling freshly patched kernels. The responsiveness of the system was so much better - start-up, multi-tasking, windowing, everything.

    Never looked back, especially since they made us all red

  • The rah-rah supporters are missing the real issue (Score:5, Insightful)

    by The_Laughing_God ( 253693 ) on Wednesday October 13, 2004 @04:36PM (#10517803)
    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.
    • It seems to me that Linus probably wants RTOS capabilities in the mainline. The issue is that most patches for it are excessively intrusive.

      Some of Ingo Molnar's work is just to push down kernel latency in a general way, which is acceptable and more incremental in the mainline, while laying down an archetecture that makes it easy for a hard RT patch to be maintained, with minimal impact on the kernel.

      Linux will never default to being a true RTOS across the board, forever and ever amen. So, while you're ri

  • What is it needed for? (Score:3, Interesting)

    by El ( 94934 ) on Wednesday October 13, 2004 @04:46PM (#10517920)
    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.

  • I would hardly call this "pooh-poohing." (Score:5, Insightful)

    by ZuperDee ( 161571 ) <zuperdee@nospAM.yahoo.com> on Wednesday October 13, 2004 @04:54PM (#10518007) Homepage Journal
    Linus merely said "not at this time," and gave his rationale. To me, this hardly qualifies as "pooh-poohing." Therefore, I'd say the article headline is misleading, and designed merely to stir up emotions rather than foster rational dialog.

  • The Linux kernel is too monolithic for this (Score:5, Informative)

    by Animats ( 122034 ) on Wednesday October 13, 2004 @05:00PM (#10518084) Homepage
    This is where the Linux architecture, with drivers in the kernel, really bites you. Because all the drivers have to be made preemptable, too. This is at odds with the traditional UNIX "top and bottom" driver architecture, with the "top" running as a process and the "bottom" running at interrupt level.

    If you want hard real time and protected mode, you need an architecture like that of QNX [qnx.com], where almost everything runs in user space. File systems, drivers, and networking are all user programs, intercommunicating by message passing. The kernel only handles CPU dispatching, memory management, and message passsing.

    In an architecture like that, everything in user space is preemptable, without any extra work in the system services. There are no long latencies in the QNX kernel; they were all taken care of years ago.

    As Linus points out, though, few consumer embedded devices really need hard real time. Most media-related stuff can paper over delays with buffering. A classic comment is, "You run your web server on Linux. You run your nuclear reactor on QNX".

    Automotive systems, though, really need it. QNX is big in that market.

    • Funny that your website also happens to appear in conjunction with QNX frequently in google searches :p
    • You run your web server on Linux. You run your nuclear reactor on QNX

      I'd rather have a nuclear reactor that has inherent safety mechanisms rather than one that depends on a piece of silicon running human-written software for not going into meltdown.

    • This is where the Linux architecture, with drivers in the kernel, really bites you. Because all the drivers have to be made preemptable, too. This is at odds with the traditional UNIX "top and bottom" driver architecture, with the "top" running as a process and the "bottom" running at interrupt level.

      Actually the Linux architecture isn't as bad as you imply in this respect. Although Linux does follow the traditional top/bottom separation (though in Linux terminology, at least, the "bottom" half is the

  • LKML reference (Score:4, Informative)

    by SmileR.se ( 673283 ) <smiler@nOspAM.lanil.mine.nu> on Wednesday October 13, 2004 @05:00PM (#10518088) Homepage
    Here [theaimsgroup.com] is the LKML thread discussing this (including explanation of why it isnt accepted into mainline).
  • Should we be worried that Linus is apparently capable of defecating C code?

    Huh? Oh.

  • No big deal (Score:2, Insightful)

    by B1gP4P4Smurf ( 790700 )
    Speaking as someone who actually downloaded and tested these patches, I would not worry too much. This stuff is all very rough around the edges, though it has amazing potential.

    If the patches were mature and worked well, and Linus rejected them, it would be news. For now he is just saying "Show me the money". Nothing new, the burden of proof is on people who introduce new features like this to prove them stable, and it just hasn't happened, yet.

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Close