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."
Direct link to they story.
I learned something new!
Real Time Operating Systems. Now you know!
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.
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
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
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.
Not exactly real time response here.
Linus' job is to say no. Here, he even gives rationale.
There are no trails. There are no trees out here.
I guess Linus does not realize the full potential of what real time functionality can do to Linux.
Yes, I'm sure he has no idea...
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
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
Gen. Melchett: Is this true, Blackadder? Did Captain Darling pooh-pooh you?
... by pooh-pooh!
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
and that it will give high priority tasks all the time they need.
DOS did this back in the 80's....
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!
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.
Your hair look like poop, Bob! - Wanker.
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.
Uhm, no. He has given an irrevocable, royalty-free licence 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.
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
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
Linux: Realtime Preemption
First we had a post on Hibernate with no explanation. Then a post on OQO and now we have one on 'Linux'. When will the madness end?!?!? ;)
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".
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
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?
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.
Actually, it does exist, sortof. If you look at how a Sharp Zaurus sl-5500 is set up, you have 64 meg of ram which is split by the kernel, part of which is used as ram and part is mapped as a block device. This second part survives system reboots and resets (but goes away once the internal battery dies).
Shared libraries also save ram -- multiple programs using the same shared library all point to the same copy that is in memory. Which also ends up giving a speed boost (more memory free).
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)
HAND.
Here, have a cookie.
My other first post is car post.
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.
If you want hard real time and protected mode, you need an architecture like that of QNX, 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.
Here is the LKML thread discussing this (including explanation of why it isnt accepted into mainline).
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?
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.
People throw around bloat with great abandon, and usually without any real rationale behind the term.
My OS is full-featured. Yours has feature creep. His is bloated.