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!
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
I'd be shocked if he didn't realize exactly how this patch would impact Linux. From the article:Iduno what else there is to discuss...
There are no trails. There are no trees out here.
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.
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.
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
Having smart appliances and energy controls securely networked would be a boon to Linux. The real-time kernel would allow speedy monitoring of these type of devices.
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.
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).
Note also that the patch hasn't really even been submitted for inclusion. The Montavista people posted it to LKML with a lot of warnings, making it clear this was intended as a way to get early feedback on the direction of their project, rather than as an example of a finished implementation.
So the slashdot headline is more than a little misleading; everybody agrees this is early in the process, and it's no suprise no-one's rushing to apply the patch.
--Bruce Fields
Brain Surgery (Simple Way)
1: Cut Head Open
2: Poke brain with stick
3: Close Brain.
It's just a little harder than you make it out to be. Look how many of the subsystems have to be touched by this driver.
Just to fight this stupid urban myth: The GPL doesn't say that. Please read at least the FAQ. kthx.
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.
If you read MontaVista's original announcement, it was not posted for inclusion in the mainstream kernel, no one (including MontaVista) is claiming that it is ready. They merely posted their work to stimulate discussion and to avoid duplication of effort. So of course Linus is right, no one ever said it _should_ go in the kernel now or even anytime soon.
Why was this modded "Insightful", the poster clearly has not bothered to understand the situation.
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.
Actually, the article hints at Linus' mastery of the issue by clueing the reader in on a few consequences of hard real time systems. The problem is that while the OS would be capable of guaranteeing a response within tens or hundreds of microseconds, the overall response time of the system is reduced. Linus is quoted as saying he believes most people, even in the embedded space, don't want this as a standard feature of the OS. This is because there's a comparatively easy fix for getting quick response times: over-provision the hardware.
For HRT systems, however, it's not good enough that the response time is "probably good enough, most of the time." HRT systems require a guarantee, and that guarantee has a net effect of slowing down the system.
Compare it to "guaranteed-secure" encryption. It's possible (quantum encryption), but it requires a physical fiber connection (a polarized light-pipe) and some serious detection hardware.
The article goes on to say that Linus may consider putting pieces of the patch into the kernel in the future.
Every PC has a small amount of writable NVRAM...it's where my CMOS settings are stored. If you look at the Linux kernel configuration, there's an option to allow writing to this area of memory.
However, it goes away if your CMOS battery dies. (I believe it's SRAM based.)
I suspect you're thinking of FLASH memory, which isn't as fast as SRAM, or, generally, even DRAM.
Here's a good overview on DRAM and SRAM, if you're interested.
tasks(723) drafts(105) languages(484) examples(29106)
Montavista's approach just involves patching the standard kernel to try to improve its behavior. This gets you soft real-time, but getting provable hard real-time is tough via this route due to the complexity of the kernel.
RT-Linux (and RTAI which is roughly based on RT-Linux but offers a different API) is very different. It runs as a hard real-time micro-kernel which takes over your system and then runs all of Linux as a thread. When you run your hard real-time code it runs in that micro-kernel space rather than Linux user or kernel space. All of Linux gets preempted by your software.
Here is a great article covering this subject in more detail with tons of links.