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.
The 'appears' hyperlink in the summary is pointing to the wrong link. I think the author intended this article instead.
Wouldn't a real time patch violate software update patents
- i don't think so!
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.
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.
Heffalumps and Woozles. Heffalumps and Woozles!
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
And it's unnecessary (and wrong) in this story's title.
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
Imagine what a free common system might be a better starting ground for telecom equipment -- I can see devices brought to market quicker. What does that do to people like other RTOS developers?
Zhrodague.net - I do projects and stuff too.
The OP just wanted to let everyone know that he worked for IBM (as a Janitor, dusting off MontaVista CDs, no doubt).
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?
I think it's actually POO-POOs, but who's spel checkin'.
Also, it seems to me that I saw that in a War Games once, that they wanted to get the men out of the loop and let computers start making decisions on their own. Basically, in the movie, that was a bad idea.
Peace Out.
"This isn't a study in computer science, its a study in human behavior"
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.
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
Are you sure? I thought POO-POO would be more apropriate is the story were "Linus POO-POOs feces"
My other computer is a Jacquard loom.
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?!?!? ;)
When this was first mentioned I had a feeling this *patch* wasn't approved. It was spoke of as if it had all but been accepted.
I cannot wait till this functionality does finally make it into the kernel though.
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
Tigger said to be hopping mad in protest; Piglet leading soft-spoken sit-in. Honey at 5:00.
-Rob
Marriage doesn't have to suck!
Has anyone ever taken a look at some of the stuff available in the 2.6 configuration options? Do a 'make menuconfig' and browse through the "General Setup" and "Processor Type and Features" submenus. A bunch of it is wholly useless to 99.9% of the installations out there.
But it's there as an option, if you want it, like most everything else. Have a tulip ethernet card? Include the driver. If you don't, leave it out. Old BIOS doesn't do ACPI? Leave it out. Don't need a keyboard driver because it's an appliance system? Leave it out.
Why the hell not just include the real-time business as options? Is the maintenance really that much more challenging?
This article is not about RTLinux.
Here's something that Montavista has contributed to the Linux kernel - PRAMFS. A quote (emphasis mine):
/var/log, or a user address book in a cell phone or PDA.
Many embedded systems have a block of non-volatile RAM seperate from normal system memory, i.e. of which the kernel maintains no memory page descriptors. For such systems it would be beneficial to mount a fast read/write filesystem over this "I/O memory", for storing frequently accessed data that must survive system reboots and power cycles. An example usage might be system logs under
[...]
2. If the backing-store RAM is comparable in access speed to system memory, there's really no point in caching the file I/O data in the page cache. Better to move file data directly between the user buffers and the backing store RAM, i.e. use direct I/O.
They've described that they want to use this stuff in a cell phone or PDA, yet have described an NVRAM technology that does not exist (as fast as system memory?). Methinks that they're working with Intel on some new fangled NVRAM, (hint, look for Ovonic). Samsung appears to be working with PRAM as well.
So this MontaVista file system is a PRAM-File System, maybe...
Life is the leading cause of death in America.
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.
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.
I understand that you can be a bit afraid about stability and throughput of your DB2 system, but, as many other things, these characteristics can be enabled/disabled, still disabled as default, still compiled in the main branch.
About my, probably unfortunate, sensationalistic acusation for tergiversation: Linus was not saying about a "definitive no", as the "hard real time" capability has been discused by him long time ago, simply it was not developed nor designed, just as some kind of pray, waiting for HRT to fall from the skies. If MontaVista people got it, I understand that Linus don't get in a hurry, of course! Just because hurry it is never a good consultant/counselor (Napoleon one time said to Josephine: "dress me slowly, because I'm in a hurry", or similar).
"Hard real time" possibility it's a huge step ahead, making Linux a 4x4 in computer engineering, reaching almost not only every CPU and architecture, but also every reachable problem solvable using a Linux capable CPU. It's amazing, or may be not, what do you think?
So thanks for the inside scoop.
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?
From Series 60 Developer Platform 1.0/2.0: Basics paper:
Symbian C++ APIs enable extremely efficient multitasking and memory management. Memory-intensive operations such as context switching are minimized. Symbian OS is primarily event-driven rather than multithreaded. Multithreading is possible but is avoided because it potentially creates several kilobytes of overhead per thread. Conversely, a primarily event-driven approach doesn t need any context switching and can have an overhead as low as a few tens of bytes. Special attention has been given to designing the Symbian OS to be robust and reliable. Among the user requirements that were kept in mind when the Symbian OS was developed were that user data should never be lost and that the device should never have to be rebooted (there isn t a boot sequence when the device is turned on). This has been achieved by:
Effective memory management that prevents memory leaks Releasing resources as soon as they are no longer needed
Effective error-handling framework that handles out-of-memory errors properly
Secure data storage
Careful and device-specific power management
I know that there allready exists Linux smartphones, but how do they perform in "real life"?
As far as I know, it's not even possible to develop Symbian mobile apps on linux (lack of emulators), which is a drag, so come on, give us Linux smartphones, or Mr Symbian, release some emulators for Linux (a lá suns java-WTK) or else.....
Is a Real Time OS any relation to a Real Soon Now OS?
Or is the latter an exclusively Microsoft concept?
A couple of years ago I worked on an embedded linux project, and we used the linux real-time and pre-emptive patches on the target. We actually applied the same patched to kernel of one of the development workstations to see if we could notice any difference, and within 15-minutes of booting, those that could were recompliling freshly patched kernels. The responsiveness of the system was so much better - start-up, multi-tasking, windowing, everything.
:-)
Never looked back, especially since they made us all redundant, and closed the site...
Any fool can talk, but it takes a wise man to listen.
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.
Its usefull for all kinds of things. Robotics for example. Anything that has real time behaviour. Lets say you want to build your own segway that runs on Linux, you will need the motors of the segways to react immediately to inputs from sensors and user otherwise you risk crashing. I have worked on robotics projects where we where controling a robots arm with a PC. The fact that it wasn't real time was a real anoyance. We couldn't garanty that the robot would be able to hit a moving ball for example. I once wrote a program that generated music in real time from input from a sensor array. Again the fact that the PC wasn't real time was an anoyance. You could never implement a keyboard with a PC that doesn't have at least near real time characteristics. Otherwise you would get audible delays.
None. Whatsoever. He's just a suit with lots of money as far as the kernel maintainers are concerned.
Linus has a far different job (he's also not a CEO so he's harder to make fun of, because he's more like us).
Also, Linus is right.
Thank you Zapman Webster!
I just wasn't aware that the plural of OS was OSen.
What can an RTOS do that Linux can't that wouldn't be better handled in hardware? If responding to a given event is really THAT time critical, then perhaps you shouldn't be handing the event all the way up to your systems software for a response... In my experience, most problems that people claimed demanded "real time" to solve could be more easily solved by adding more buffers.
"Freedom means freedom for everybody" -- Dick Cheney
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.
The existence of the code in the main kernel, regardless of whether it is enabled at compile time, affects everybody. It's not like you're going to have a single place with
...lots of code
#ifdef REAL_TIME_KERNEL
#endif
It's going to change a lot of things in a lot of places. Ideally, it will make infrastructure changes which benefit everyone, by abstracting certain elements of the code, which then makes its own specific features fit in nicely. Unfortunately, this is very difficult to do with real-time scheduling.
It seems to me that Linus probably wants RTOS capabilities in the mainline. The issue is that most patches for it are excessively intrusive.
Some of Ingo Molnar's work is just to push down kernel latency in a general way, which is acceptable and more incremental in the mainline, while laying down an archetecture that makes it easy for a hard RT patch to be maintained, with minimal impact on the kernel.
Linux will never default to being a true RTOS across the board, forever and ever amen. So, while you're right on the money that some people hunger after RTOS when it isn't what they want, it doesn't change that some people really _do_ want RTOS in the kernel. Linus is rejecting it because of technical issues with the patch (dangerously intrusive, MontaVista can simply maintain the patch external for those who really need it, and did I mention that it's intrusive?), not because he thinks that a real time Linux is a bad idea (though it certainly is for me as a desktop user)
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.
...but this IBM audio cassette I listened to said it was "the way of the future". We have to keep the future in the kernel...for the children.
"A man talking sense to himself is no madder than a man talking nonsense not to himself."
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).
I swear, people who get their submissions accepted don't know how to link. Seriously, wtf is up with the first link to http://news.search.com/search?q=red+hat&search.x=0 &search.y=0?
there is not one mention of Real Time or Linus on that page. Come on, can't you learn to link to the story?
Here's how you should have linked the first line:
"Speaking with CNet via email, Linus Torvalds appears to be in no hurry to accept..."
I find it ironic that you linked "appears" in correlation to Linus to a page that had "Linus" appearing nowhere in the page.
i20 is used by alot of TV tuner cards. Not to mention who knows what else.
I have a machine that has both arcnet and token ring, and I'd like a PCI HIPPI card for it (anyone have one they want to get rid of?). Slip is maybe archaic, but useful to anyone connecting older machines. Touchscreens usually present as ps/2 or serial mice... dump them too?
I've personally used the amiga and macintosh filesystems when recovering files.
But hey, let's make linux less useful to people like me. I've only been using it since mid 97. Heck, get rid of one of the things I tell people is exceptional about linux, its support of just about anything hardware wise. (Ever try to get arcnet working on windows 2000?)
Should we be worried that Linus is apparently capable of defecating C code?
Huh? Oh.
"Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
i20 is used by alot of TV tuner cards.
um no, it most certainly is not.
Brain fart, read that as i2c. But you do earn 10 demerit points for being a retarded asshat. Anyone but you would have replied with "you're thinking of i2c". Do you like wasting space while adding nothing to the discussion?
You're thinking i2c. i2o is something else entirely.
This is brilliant. Submit to k5 queue pls thx.
Could you explain what a spinlock is? Also, what is a non-mutex lock? Please excuse my ignorance.
It is impossible to enjoy idling thoroughly unless one has plenty of work to do.
- Jerome Klapka Jerome
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.
mean, what happens if a custom pizza gets ruined in the oven?
Sue the oven manufacturer and issue a press release, duh!
Or, if you want a Free Software system, try the Hurd (Scheduled for completion circa 2047).
Linus has pooh-poohed other important patches in the past as well. That doesn't mean it doesn't go into the kernel, it just means that one needs to demonstrate the advantages of it to Linus and show it doesn't cause other problems.
We are currently successfully using Timesys Linux in an embedded product and are having great success (despite problems with Timesys). Realtime support is essential for telecom and networking applications. It also is quite useful for multimedia, so that video appears smooth and not jumpy. Granted, realtime is often not very useful for a general purpose computer, but in the embedded world, it is extremely useful.
-Aaron
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
Yes - you would notice the difference, but I suspect that would have been due to the pre-emptive patches, not the real-time patches.
(The RT side would have been idle if it was never given a RT task to do on the dev workstations.)
FWIW, I believe preemptive is in mainline now.
I could be wrong, but from memory, only specalised software can use the RT side of things, but pre-emptive improves latency for all Linux processes.
No, it usually takes a few hours.
Not that this wasn't entirely predictable.
I know that it does increase complexity, and therefore hinders future maintainability.
From the comments Linus made, he seems to be concerned about complexity (and he is right in this regard), and performance. This approach eliminates the risk on performance or any other impact that *running* this code would cause.
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
The other thing everyone seems to be missing:
Hard Real Time means you presumably give a damned about your system working consistently 100.00000000000000% of the time. It must NEVER break in any way.
Frankly, even if your timing routines are able to provide this real time assurances, I dont think the linux kernel itself is designed with the sort of bulletproof internals Hard Real Time implies. Linux is stable, yes, but it is not thoroughly audited enough to form the basis of a Hard Real Time system. Kernel panics DO happen, and then your hard real time timing is for naught.
There is no price to pay for running a good real-time OS in terms of efficency. There is a monetary cost (licensing fees).
.2 ms if you are running a control app that needs higher frequency. Then you have more overhead.
/net/bob/* ~"
:)
Folks who say otherwise are just quoting the silly wickipedia and have never worked with a good real time OS (like QNX - www.qnx.com).
For example, on QNX the scheduler runs every 10ms by default. You can increase the frequency, say to 1ms, or
Oh - you get to set real priorities for your processes, and scheduling disiplines per process (FIFO, RR, "fair", etc.)
There is nothing in the definition of a real-time OS that requires it to be slower or less efficient than a non-real-time OS.
QNX transfers disk data at platter speeds, and has done so forever. Network data at the rate of your network.
It is just a far superior OS than Linux, and I use both professionally and have written device drivers for both. It lacks 3rd party software and driver support - and some people won't understand why that doesn't mean it is inferior as an OS to Linux.
Want to write a device driver? In QNX just write a user mode program, use the language of your choice (C, C++). Debug it with DDD or your favorite debugger. You're not stuck in kernel mode using C like in Linux.
Want to access the serial port on another machine without writing any network code? Open "/net//dev/ttyS0" instead of "/dev/ttyS0". The OS handles it transparently for you.
Same with any file/device. Copy all the files from machine "bob" to your home directory on your machine? "cp -r
Need more processing power? Just move some of your processes to another machine, no need to rewrite your code to use a network protocol - the built in msg passing works with a global namespace and connects you to the right process on the right machine.
The GUI system is unbelievable, designed for networking from the ground up. You can move a window accross machines on the network, or have multiple people sharing the same desktop, or different portions of the same desktop, or multiple sessions (a-la traditional windowing systems). Without writing any special networking/gui code.
QNX is free for non-commercial use. Read about it. Use it. Don't be a wickipedia fool, badmouthing real-time operating systems
It's been around for 20 years. It was the best when it was multitasking on my 286 and it still is the best now on a P4/3GHz.
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.
This is a bummer. I work in telecom and we won't be porting our stuff to linux anytime soon if there is no support at least for a high resolution timers like Solaris' gethrtime().
And you [i]need[/i] to realize that Slashdot doesn't accept forum tags!
See subject. Problem solved. What's Linus holding out on anyway? Remember that he also was initially opposed to a pre-emptible kernel space, yet that eventually became a compile-time option too.
generally speaking linus is a fairly well rounded individual. He would include things in and not include things that have some sort of reason behind it. Its not generally a "i dont like you its not going in" thing if its better for the community.
I poo pooed some partially digested corn this morning.
Next time you design a reactor, you go ahead and do it your way.
If you were blocking sigs, you wouldn't have to read this.
Go on, Mr Don't Know The Difference Between Embedded and Realtime. List them.
If you were blocking sigs, you wouldn't have to read this.
I love how all these InstaExperts spring up on the rare occasion that Slashdot runs a tech story.
Beyond the level of a lightbulb and switch, the concept of a Real Time Operating System is spurious. Better to say Very Low Latency Operating system. There's always a delay in reacting to an input, and it's always buffered in some way. Even a lightbulb and switch buffers the signal along the length of the wire from the switch to the bulb. More complex systems, like a phone PBX that has to respond to signals coming down the wire buffers them in a DSP before actually responding to them. If the operating system (in the sense of the executable running on the CPU as we're discussing here) had to respond in 'real time' to every signal on the line or even from the DSP, then you'd be dropping calls or missing other scheduled tasks.
All OSes involve a compromise. An 'RTOS' is only more interruptable by degree than an already fairly low latency OS like Linux. Linux has some way to go yet, but it's already good enough for a lot of systems. And - gasp - even an 'RTOS' can and does miss inputs.
If you were blocking sigs, you wouldn't have to read this.
here, and I don't see where it "specifies" anything about fair use.
If you mean that making fair use of GPL'd source offers you a defence against charges of copyright infringement, you're correct, but that's not even remotely what the GPL says.
If you were blocking sigs, you wouldn't have to read this.
here. It's work in progress. The patch, as submitted, is based on the wrong tree, needed further patching even to make it work with a stock kernel, busts 4k stacks and spits error messages. The submitters make it clear that there are a lot of versions to come.
Their intentions and goals are good, but it's a long way from ready for inclusion. It's a step along the road, but they need to submit a final and fully debugged version that doesn't bork anything, and with less marketdroid spin and more comprehensive testing and performance metrics.
If you were blocking sigs, you wouldn't have to read this.
Ingo's patches have been developed out in public view with participation from many other people. Rather than just dropped as a PR bomb shell. If you think RedHat isn't a "RealTime" company TimeSys' Scott Wood has been involved as well.
i think computer is something that can do many ... if you ... ... i'm sure every os vendor / ...
different things, it's programable
want realtime smart people build a circuitry that
does nothing but that. see a switch for a light
bulb. so if you want that missile abort NOW and not
in 5 sec you BUILD curcuitry for just that, if
you're smart
of course everybody wants a responsive computer to
use, but why are we buying biger/faster computers
more ram etc.? maybe this software realtime thingy
is a bit over-hyped
creator are working hard to make their OSes
responsive / interactive.
real realtime doesn't exist! not with computers,
that operate binary-ly / serial
I'm sure you're not a super elite hacker like me, so you probably didn't know this, however it's possible to put the entire kernel in one big text file and compile it.
so you could do EXACTLY like you were saying, except that you would need an #else before the #endif and the non-real-time code there.
In fact, there is already a secret kernel branch, called the ONE_TEXT_FILE_LINUX_KERNEL_SOURCE project (yes, the all caps are part of the name) which will be releasing it's single file soon and will be taking over from what you know as Linux today.
Just to spite you they are going to implement the real time parts in a single ifdef in the file.
And before you say it, they have tricks for doing EVERYTHING, the assembly for the loader and the jump into protected mode on the 386s, etc plus the c (and secret cobol code included in the new single file project) and compiling everything from a single text file. they use the new GNU kernel compiler, which is a unified compiler that produces a kernel from a heterogenous text file.
the next version of the GNU Linux Kernel Compiler (v1.0) will compile the entire kernel from a single statement, "compile_linux()" which makes it trivial to have the entire kernel in a simple file. In fact, it makes it hard to have it in different files! What a program.
thank you for you time reading this interesting post, and I wish you a healthy and prosperous day.
Can we settle on "Deterministically Low Latency OS"?
Almost. However, the initialism "DLL OS" brings to mind shared library version conflicts.
And Michael Eisner wouldn't say "Pooh Pooh" either; instead he'd say "money money".
Are you saying that if someone in another article said "Pooh" and meant "Poo" and people commented on it, that it would be relevant in THIS article?
NOTE TO ALL MODERATORS: I'm not necessarily talking about rarities like equating Milne's Winnie-the-Pooh to feces, no matter how many people have grown tired of watching a small child watch a Disney movie dozens of times. I'm talking about the first post/you fail it, Goatse, Tubgirl, GNAA, In Soviet Russia, In Japan, BSD is dying, Stephen King is dying, Natalie Portman, underpants gnomes style business models, and other well-understood Slashdot trolling phenomena.
What do you want, LiveJournal crap? Here's the last 24 hours of Team Overbot.
If you want that level of detail, join the team. We have papers, videos, and photos on the Overbot web site for those casually interested.Received rev. 2 front connector panel for motion controller interface board. It fits the connectors perfectly. Rechecked interface board on vehicle by jacking up the rear two axles (It's a 6x6, remember) and running the engine. Driveshaft encoder, tach, and throttle control tested and work. Ordered more boards, new optoisolator parts for boards (the old ones didn't source enough current to drive the big solid state relays) and matching front panels. We should have final interface board hardware working in a week. This will finish all chassis control gear except transmission control.
The roughness in the laser rangefinder tilt head drive turns out to be an out-of-tolerance shaft. The shaft and motor have been removed and sent out for rework.
The bogus readings from the laser rangefinder simulator turned out to be a wierd behavior in Blender. We have a workaround and have reported a collision detection bug.
Tomorrow is trash day. Empty trash.
Not only is it a ton of #ifdef's throughout the code, it also forces the requirement of anyone changing code in that area to not only test their changes how they would today, but now they would also have to test with the real time code enabled. This includes any drivers using any type of locking.
-DJBS
Sure it would be useful in all the embedded devices etc. Right. But you want desktop apps.
Never more buffer underruns in non-burn-proof CD writer.
Some "l33t" just hacked you and started a wabbit which not only hogs your CPU 100% and slows your shell down to a crawl, but also corrupts things at random. Launch "realtime shell" and work at full speed, without waiting 40s for killall -9 to execute.
Write an app that's bit-banging data in some obscure protocol like 1-wire Dallas or something, and don't worry about it missing its time frame.
Switch to a console and kill -9 that frozen mplayer NOW.
OO.o is saving your work in the background, while you keep typing with no slowdown at all, saving takes a bit longer but your interactive process has realtime priority.
Surf the web. You open a webpage with 10.000 dancing monkeys. Suddenly each monkey takes a minute to move one animation frame. You click "close". Webpage closed NOW. Not in 5 minutes when the process gets to receive the "close" event and process it.
You're playing Doom. You don't smell smoke. You don't see fire. The system with broken CPU fan has just shut down saving the CPU, due to thermal alert which wouldn't otherwise get through because of the game hogging the CPU.
Anagram("United States of America") == "Dine out, taste a Mac, fries"