Montavista Software has submitted patches to the linux kernel mailing list which aims to convert the Linux kernel in a real-time operative system.
Real-Time Enhancements to the Linux 2.6 Kernel
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I don’t think you quite understand the meaning of “patch” in this case.
I can’t wait to try these patches on my Linux DAW. Does anyone know if they break or remove features from the generic kernel in a way that makes using them in a normal desktop system impossible?
RE: Oh yea. (Anonymous)
What has this got to do with security?
what is “real-time operative system”?
For those of you that want to try it, read all thread to succeed with minimum effort.
😮
Go back to Slashdot!
Steve Furr:
“…realtime operating system must guarantee that a feasible schedule can be executed given sufficient computational capacity if external factors are discounted. External factors, in this case, are devices that may generate interrupts, including network interfaces that generate interrupts in response to network traffic.
In other words, if a system designer controls the environment of the system, the operating system itself will not be the cause of any tardy computations. We can apply this term to conventional operating systems – which typically execute tasks according to their priority – by referring to scheduling theory and deriving a minimum set of conditions that must be met. Without getting into too much detail, scheduling theory demonstrates that a schedule can be translated into static priority assignments in a way that guarantees timeliness. It does so by dividing the time available into periodic divisions and assuming a certain proportion of each division is reserved for particular realtime activities.”
Source: http://www.qnx.com/developers/articles/article_298_1.html
from someone who works with linux in real time applications aka, radar processing, I for one am glad to see this. Linux looks like it’s going to be the multimedia OS of the future as well as a wonderful server.
sounds good on paper, but until i have one of these right here in front of me…..
oh well, i wish Monte-Vista good luck…
Of course, after the SCO threats, the kernel maintainers won’t just blindly accept something posted to a mailing list. It’ll have to go through an examination to ensure there’s no problematic code.
I think some of you are misunderstanding what these patches are for. “Real Time” operating systems are used in mission-critical systems, such as the radar example above.
I beleive they are more focused around a guaranteed minumum level of service delivery for certain applications in which even the smallest delay is unacceptable. Again, radar example – an air traffic controller needs to have constant, accurate, timely access to all the information they require or the outcome could be disasterous.
> Of course, after the SCO threats, the kernel maintainers won’t just blindly accept something posted to a mailing list. It’ll have to go through an examination to ensure there’s no problematic code.
Um…. no? What do you mean by “go through an examination” in this context, anyhow? Obviously, it’s not going to be applied without looking at it, like any other code. If it’s not included, things like how it still deals poorly with heavy-load/low memory situations strike me as much more likely reasons.
This is not the first set of realtime linux patches. It incorporates work by Ingo, who’s done quite a lot of original work for the linux kernel. Etc.
Where would these patches be taken from, anyhow? It’s not like you can just take the real-time code from Windows and diff it against the Linux kernel to get a patch, or from SCO…
Transfering code that makes a kernel realtime between different kernels and kernel architectures isn’t that trivial.
SCO is beyond irrelevant. If you were talking about a totally new implementation of a major feature, like a filesystem, utterly out of the blue, fine, bring in SCO. A set of real-time patches to the linux kernel? … No.
actually, in this case it would. from the original msg:
————————————————————-
WHY IMPLEMENT PRELIMINARY RT SUPPORT IN LINUX:
Our objective is to enable the Linux 2.6 kernel to be usable
for high-performance multi-media applications and for applications
requiring very fast, task level reliable control functions.
The AV industry is building HDTV related technology on Linux,
and desktop systems are increasingly used for similar applications.
…
————————————————————-
.. some folks have been doing this sort of work already on the 2.4 and 2.6 kernels, primarily for audio, namely planet ccrma, suse 9.x, agnula demudi but i hear there are issues with 2.6 and jack. i hope these RT patches will allow the 2.6 kernels to establish some kind of consistency or stability with regards to low latency performance.
These patches are still uber unstable, so don’t expect to see these for a couple months. I predict Reiser 4 will go into 2.6 before these patches do