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."
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.
Hurricane Ivan: A 17th century prison collapsed. All of the inmates escaped.
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.
BLING BLING. Meet the architecture that's changing everything.
Linus' job is to say no. Here, he even gives rationale.
There are no trails. There are no trees out here.
While useful for certain applications (if I press the "abort" button on a missile, I want it processed NOW and not 5 seconds after it explodes..), I don't see what a hard realtime operating system would do for desktop systems.. then again, maybe I'm completely missing the point?
I am the maverick of Slashdot
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
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!
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?
What makes you think it wouldn't just be annother kernel config parameter to most people?
You are missing the point insofar that Linux doesn't aim just for the desktop and/or server market, but also, as stated above, for the embedded market where hard real time often is simply necessary. Or why else do you think OSs like QNX still exist? :)
Whether this "aim for everything"-attitude is a good one for the Linux kernel as a whole remains unquestioned for now.
After digging around some (see the posts above), Linus seems to feel that the patches are too intrusive, which I can certainly understand. Hard Real time promises are not good in the general case, which is why most OSen don't bother. For the cases that require them, traditionally there are specialized OSen (QNX for example) that have the functionality needed. I'm not sure about this, but I believe that there are some specific hardware requirements for true RT. The scheduler is also radically different.
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.
Zapman
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".
Much as I think Linus is often an arrogant blowhard who often goes off about things he doesn't know about (microkernels, his original views on SMP, and his theory on solaris's /dev/poll implementation just to name a few), I would have to side with Linus here. Hard realtime is a different beast than soft realtime, and even if these patches work perfectly now, Linus doesn't want to be in a position to have to ensure that some update to a SATA or network driver or whatnot causes hard realtime to break. Validating the realtime response of the system is NOT a simple task, and has to be engineered in from the start. Linus knows Linux isn't built that way, and doesn't want to set the expectation that it will.
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.
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.
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.
It saves as many versioning problems as it causes. Imagine there's a buffer overflow in libc. Would you prefer to patch every app on your system from ls to mozilla? Or would you rather update just libc?
I still have more fans than freaks. WTF is wrong with you people?
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.
Hmmm, I think the whole story was just an elaborate setup for that joke.