Linus Pooh-Pooh's Real-Time Patch 262
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."
Might not be in a hurry.... (Score:3, Insightful)
Linus is right. (Score:4, Insightful)
Barely a story. (Score:5, Insightful)
Re:MontaVista Rocks (Score:3, Insightful)
Linus "appears to be in no hurry to accept" (Score:4, Insightful)
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
Real Time enhancements as a fork (Score:5, Insightful)
Probably because it's not "integrated" enough? (Score:2, Insightful)
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?
Re:Linus is right. (Score:5, Insightful)
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:Might not be in a hurry.... (Score:5, Insightful)
Hmmm... (Score:3, Insightful)
Re:Linus is right. (Score:3, Insightful)
Aren't they just being good citizens by offering up their patches for inclusion? You know, like that GPL thing says they should?
Re:MontaVista Rocks (Score:3, Insightful)
Whether this "aim for everything"-attitude is a good one for the Linux kernel as a whole remains unquestioned for now.
Re:Might not be in a hurry.... (Score:5, Insightful)
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:MontaVista Rocks (Score:5, Insightful)
It would not suppise me at all if this lives a long and fruitful life outside of the standard kernel, as a stand-alone patch set. That's not even a bad place to live, especially since the requirements are rather esoteric.
Re:Might not be in a hurry.... (Score:5, Insightful)
People throw around bloat with great abandon, and usually without any real rationale behind the term. In this case, you have the creator and current maintainer of one of the world's most complex pieces of software which handles millions of different configurations across hundreds of devices and architectures saying, in effect, "this patch would make the kernel too complex." That speaks to me of a level of complexity which I cannot even reasonably grasp (and I can grasp a hell of a lot of complexity).
Personally, I'd love to see RT linux for real (as opposed to semi-real-time features like low-latency and preemptability), but not at the cost of the stability of the OS. Let it mature the way PCMCIA did. Linus didn't accept that right off the bat either, and we were better off for it in the long run, as I think the PCMCIA subsystem had to work hard to maitain itself coherently while not shipping with the OS, and/or not being updated regularly.
As for bloat... I've yet to see anything that is not modularly removable from the kernel which was not essential to a modern OS. There are many cases where I'd love to drop old hardware, but that's not usually realistic. There are many modules which I have no use for, but I can always turn those off. There are many features for hardware I don't use, but removing them would be unfair to people on those platforms.
What bloat did you have in mind?
Re:Might not be in a hurry.... (Score:5, Insightful)
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.
It is the scope and magnitude of the patch (Score:5, Insightful)
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".
good for linus (Score:1, Insightful)
Re:Linus "appears to be in no hurry to accept" (Score:5, Insightful)
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?
The rah-rah supporters are missing the real issue (Score:5, Insightful)
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.
Re:Hmmm... (Score:3, Insightful)
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.
I would hardly call this "pooh-poohing." (Score:5, Insightful)
Re:There are TONS of non-mainstream things there (Score:5, Insightful)
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.
Re:Linus is right. (Score:5, Insightful)
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.
Re:Patents ? (Score:5, Insightful)
No big deal (Score:2, Insightful)
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.
Re:Might not be in a hurry.... (Score:3, Insightful)
My point? Get off my lawn you damn kids! Heh heh heh...
Re:Might not be in a hurry.... (Score:1, Insightful)
http://www.linuxdevices.com/articles/AT3524337625
Personally I agree with Linus. Many embedded applications don't need "hard" real-time. Actually, hard real-time is a bit more of a burden.
I'm guessing that Linux can probably do most of what is required for a "soft" real-time system already....
Re:Might not be in a hurry.... (Score:5, Insightful)
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.
Re:Blackadder quote (Sorry, I couldn't resist) (Score:2, Insightful)
Re:Might not be in a hurry.... (Score:3, Insightful)
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 patents, Linus has publicly stated that he's been advised not to bother searching for patents, which is exactly the same advice corporate attorneys give to corporate software developers.
I guess he could check the code for infringing trademarks. Not likely, though.