MontaVista, a Californian start-up has proposed a hard real-time response system for Linux, but the proposal has already been rubbished by Linus Torvalds.
Real-time responses for Linux possible, but unwanted
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Thats awfully strong. He just thinks that their current patches are to intrusive to be dumped into the kernal all at once. Seems more then reasonable to me.
journalism at its best…. never miss a chance to hype.
I just don’t think it’s a big deal. Worse comes to worse, you can always (and by you I really mean not me and probably not you either) can build a Linu kernel with it for your own use. For me, real-time would lead to no benefit since I’m not running an embedded device. I’m running a computer. Eh.
Considering the news is from an english website, I wouldn’t consider the wording strong. Here is the same news, american version: http://news.zdnet.com/2100-3513_22-5406291.html?tag=default
Anybody has the Australian version?
Maybe ‘bollocked’ would have been a better choice of words?
i think it is better to use “rejected”, or “turn down” 😉
hard real time often comes with more burden on the OS and longer average delays as the article points out. much better to have good soft real time, at least in the mainline kernel. montavista can always maintain a real time patch which people can use if they really want hard real time.
“But the company has had some success in getting its ideas accepted. MontaVista programmers wrote a “pre-emption” patch useful in embedded devices that’s now part of the main kernel — not a mandatory component, but an option that can be selected.”
Ingo Molnar doesn’t work for MontaVista does he? Credit where credit is due….
Another bunch of people trying to get embeddability into the mainstream kernel were Metrowerks; recall one of their guys showed how to prioritise maskable interrupts or something. What happened to that?
>Ingo Molnar doesn’t work for MontaVista does he? Credit where credit is due….
No, he works for RedHat.
Robert Love however, who did the preemtion patches, works for Montavista.
>> Robert Love however, who did the preemtion patches,
>> works for Montavista.
Didn’t he work for Ximian/Novell now?
> Another bunch of people trying to get embeddability into the mainstream kernel were Metrowerks; recall one of their guys showed how to prioritise maskable interrupts or something.
The “rtirq” patch (for i686) by Bernhard Kuhn : http://home.t-online.de/home/Bernhard_Kuhn/rtirq/
> What happened to that?
This is the last post i have seen about it:
http://lkml.org/lkml/2004/1/8/300
Yeap, I heard nothing after, which is a shame. Not sure where it all fits in.
http://www.kerneltrap.org/ has headlining today a Ingo Molnar patch for realtime preemption. Guess that ought to show up linked here on osnews right soon!
/me goes submits the kerneltrap to osnews to be sure..
What good would RT be in the Linux kernel, does the Windows kernel use it?!
Michael
http://phantasyrpg.com/main.php?view=9898
RT areas of importance: Process automation in manufacturing environments (QNX is used heavily here), high def. audio recording where a DSP algorithm is being applied to the audio in real time, ditto for video…
I’m sure he won’t pass up on the opportunity to slag another Linux shortcoming. I guess Green Hills must be fearing that they won’t be profitable this year.
It’s no use for the mainstream kernel so it won’t get in, but whoever is interested will be able to use it, work on it, and offer patches for it.
That’s why Montavista did it. And also to draw a bit of attention to the fact that they have this kind of expertise around the linux kernel 😉
Only fair PR.
Can you point me in the direction of some detailed articles about Real Time Linux, and no I will not follow the link to the story about MontaVista as it’s more of a PR article in my opinion.
Michael
http://phantasyrpg.com/main.php?view=9898
That article is not bad at all. In fact, it made my day. Especially amazing are passages of Illuminata analyst Gordon Haff. Unfortunatelly for him, overprovisioning hardware doesn’t transform GPOS to RTOS. There are lot of techniques that are highly beneficial for GPOS but unwanted in RTOS: lazy things like COW, memory swapping etc. I don’t know if Linus wants to see Linux in hard real-time sector, I guess not. Otherwise he needs to rethink concepts of Linux OS and probably make new branch “real-time linux from scratch” (please mind a difference between embedded OS and hard real-time OS, it is not the same and in embedded sector Linux OS has and probably will have some success).
Few words about headline of the article. Obviously it’s a PR. The story is pretty close to this one. Handyman got a van, but he needs a bike. (Why he did not buy a motorcycle in the first place? Because he got a van for free.) He turned his van into motorcycle and sent his “patches” to, say, GM. Now he got a response from GM. That’s it.
Untill that van is free, obviously there is interest to those patches and there are people willing to pay for them (sometimes even more than price of the new bike).
I wish everyone to get the right tool to accomplish the task.
Cheers,
Ingo Molnar has been working on pre-emptive patchs and lowering latency in the kernel.
The MontaVista patches were turned down because they were too intrusive. Ingo did a major review and rewrote most of the patches to fix most of the problems Linus objected to. It looks like Ingo’s modified patches have a chance of moving forward and becoming part of the mainline kernel.
This is normal practice for the Linux system. Someone steps up with a way to do soming and the other developeres review the patch looking for problems. If there are a lot of problems, then several groups start looking for better solutions.
PS: Instead of trying to “nice” your video & auto players to make them work better; it would be better to declare the jobs as being RT. That way they would get a dedicated time slice. And yes, Windows has a way of declaring a process as being RT (it doesn’t work very well, but you can do it).
ed1k wrote:
> I wish everyone to get the right tool to accomplish the task.
POSIX compliance might account for (RT)Linux consideration in some cases. Maybe LynxOS would technically be the better choise there (idunno) but that’s not OSS/FS – eCos is though.
As Linux gets more and more popular, people will surely start breaking off from the main tree and start making their own kernels. Linux has proved that it is stable. Now everyone wants to use it for all purposes. Of course, you can’t conceivably support everything possible really well. As the 2.6 kernel has started to run into problems, kernel hackers are starting to realize some goals are even contradictary. Other times, people will be forced to fork the kernel because Linus and co might not want to support certain things like a new architecture. Regardless, I do suspect that the Linux kernel will soon face one of two problems: 1) Growing so large that it simple becomes unmanageable or 2) Fragmenting into smaller, more specific kernels.
Yeah OSNews is really good at diminishing Linux kernel development to some kind of illogic, authorian process. Their arguments for that often don’t hold water and it is far more informative, non-biased to read the summary at kerneltrap.org or the actual mail-thread.
Regardless, I do suspect that the Linux kernel will soon face one of two problems: 1) Growing so large that it simple becomes unmanageable or 2) Fragmenting into smaller, more specific kernels.
I don’t really see that happening. Linus does a very good job at excepting patches once they have been refined and polished and serve a valid purpose.
Just because options are contradictory doesn’t mean they can’t both be part of the kernel. The kernel hackers are very resourseful at getting competing ideas to coexist. For instance: There are competing schedulers for the kernel, each of which have their merits. Just recenetly a means was developed to swap out schedulers like modules.
If it serves to advance the kernel for the community as a whole and is well done, it will get in.
I don’t think size is much of a concern. There are projects that manage just fine with many times more code than the kernel.
so fork it.