MontaVista Rolls Out Fully Preemptable Linux 185
A couple people wrote with a link to an article about MontaVista. They've introduced "a fully preempetable Linux". It's based on kernel 2.4, but the timing is interesting, considering 2.4 isn't completed yet - and if this had come out earlier, perhaps some of this could have been included. The article's a bit press releasely, but has some good info.
What's with the switch to 2.4? (Score:1)
This could be good (Score:1)
-- Rich
Re:preempetable (Score:1)
I don't know much about MontaVista, but ... (Score:1)
For a company that claims to be revolutionizing Linux kernel development (I assume it's them making the claims, considering this sounds more like a press release than a news report) -- shouldn't they know that the next version of Linux is 2.6, not 2.5?
Cheers,
IT
Real Time Linux? (Score:4)
Flaws in the control structure of Linux (Score:2)
This article points out an area in which Linux has one major weakness over traditionally developed operating systems such as Windows, Solaris or even BeOS, and that is that essentially one man has control over the entire operating system, and it is his somewhat capricious wishes that govern the addition of new features and the acceptance of patches.
Whilst I'm sure Linus Torvaldes is a competent, possibly even brilliant programmer, his quirks make the entire project too reliant upon him - his disdain for CVS springs to mind as an important example. Were he to be hit by a bus tomorrow then development would be stunted as people like Alan and Inigo fight over the "hot seat", and the open source movement would fail without Linux.
What Linux needs is to be incorporated under law as a non-profit organisation which can then be run by Linus at CEO/CTO. This way they can implement a professional approach to things like source code control, copyright and trademark infringements, and reviewing new proposals for the kernel, like the one rejected by Linus for specific preemption points.
Unless this happens, the Linux operating system is left vulnerable, and if its creator should leave for any reason, its progress would most likely shudder to a halt.
---
Jon E. Erikson
this is already planned for linux 2.5 (Score:3)
The problem, though, is that the approach taken doesn't work on multi-CPU systems. The overhead of synchronization between CPUs is prohibitive when doing preemption in the manner that MontaVista describes.
Re:I don't know much about MontaVista, but ... (Score:2)
Re:What's with the switch to 2.4? (Score:1)
2.4.0-test8 has fixed most of my problems with USB and IDE.
Itching the scratch (Score:4)
Re:What's with the switch to 2.4? (Score:1)
Brave Penguins (Score:2)
Somebody has to be first.
In Antartica, when the penguins are ready for a swim to go get some yummy fishies, they all cluster around the edge of the ice. No penguin wants to be the first one in, because there might be penguin-eating seals in the water. If only some brave penguin would jump in first, then they could watch to see if he suddenly turns into a bloody chunky cloud in the water.
I guess Montavista is one of the brave penguins.
Re:I don't know much about MontaVista, but ... (Score:1)
Basing it on 2.4 makes good sense. (Score:4)
It's not as though 2.4's contents are unknown, they have probably been working with 2.3 builds all the way through. they mention they have been in contact with linus torvalds, i'm sure that for something this big he would have provided them with as much information about 2.4 as soon as possible.
Integration into 2.5 makes sense, not 2.6, so this can be tested and refined within the full linux kernel development environment, and then subsequently released into 2.6 as part of the full stable kernel.
i really look forward to this, this is _good_ corporate involvement with useful goals.
fross
Re:Flaws in the control structure of Linux (Score:1)
Re:This could be good (Score:1)
I work for one now. In the beginning (circa 4 years ago) we considered several real time OS solutions but, as you point out, they were quite expensive. So in the end we avoided them all by essentially writing our own. Nothing fancy but it works. (Two tasks always running, a resolution-adjustable real time task and an interuptable background task to handle the user's needs.) Unfortunately this announcement is much too late for our product (but I'll keep in mind for any new products we develop
2.4 Kernel (Score:1)
Okay, it is impressive and nice! but (Score:1)
HARD HAT? Make me say uggghh! uuggghh!!!!!
Gee, Even PinkHat sounds better.
Hell yeah (Score:1)
Now other projects, like GNOME, are gaining a 'critical mass' of interest from developers and industry. I expect progress will be made by leaps and bounds.
The future looks bright.
Re:Please Explain (Score:5)
> it about the linux we know that makes it not fully preemptable?
Current Linux only switches processes when the kernel explicitly decides to. (in other words, when a system call finishes all its work, or when a system call decides that work will take so long that it is time to give another process a chance to run)
This patch makes Linux able to switch between processes every time that an interrupt hits, even if it is in the middle of a system call.
The trick is to avoid deadlocks. Consider the following case: process A enters a system call, and the system call takes a lock. Then, an interrupt hits and process B is scheduled, preempting A. Now B does a different system call. This call disables interrupts and tries to take the same lock. It can't get it, though, because process A already has it. But since interrupts are disabled, process A will never get a chance to run again.
Your machine hangs hard.
The solution to this problem chosen by MontaVista is to simply disable all preemption whenever _any_ lock is taken by the kernel. The disadvantage to this approach is that:
- even when it is not possible for a set of locks to conflict, preemption will still be disabled.
- all locks become slightly slower (because every lock operation must now disable preemption too)
Scheduler (Score:1)
Linux BELONGS TO Linus, you idiot (Score:1)
cp -a
You can then incorporate or whatever the heck you want. Remember to abide by the GPL and good day.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
Terminology (Score:2)
Re:What's with the switch to 2.4? (Score:1)
Re:2.4 Kernel (Score:1)
Media OS and RTOS (Score:4)
drew me to Linux in the first place.
For a time I explored BeOS and the BeBox in particular, but the slowness of that development and the abandonment of the hardware left me cold. Still it had some interesting ability that other OS's don't have involving streaming media, and anything that brings such things (Rendering in a window continuing smoothly while window was being dragged as one example) is a good thing for the user community as well as for the embedded.
While people DO seem to throw alot of hardware at problems to make operations smooth, with my Athlon 500 and 256 ram I cannot run an IE 5 session without getting skips out of winamp. This sort of performance depresses me so much I have already begun to switch over to Linux on the machine for normal use, despite it being purchased for windows development (necessary evil).
I don't know how long it will take to get this sort of performance up, and I know that the danger of RTOS functions is that a badly programmed high priority thread can cause havoc, but if there were proper guards against such things, it would probably be enough to make Linux my OS of choice for interactive exhibits (which it is close to being as it stands).
As to why we are already talking about 2.4, what I really want to know is why 2.5 is meaningful, when it is an unstable track and thus unlikely to be seen until 2.6 in most desktops. What does this mean? If we are talking about something that is done now that is not going to be in a stable release for another year, but with 10 and 100 fold improvements, does that mean we are going to have to start supporting development kernel releases for clients because the feature set is too important to miss? It hasn't been the case for me since 1.3.. I really DON'T want to be doing kernel catchup in the modern era.
If this is important technology, then why can't we postpone 2.4 a little and move it in?
What kinds of schedules are we really talking about?
Is 2.4 expected this week? Is this RT stuff expected this year?
Unlike with Windows and Mac, I don't think that many people are sitting on the edge of their seat waiting for 2.4. I don't think it is keeping folks from choosing Linux. I am not sure I can understand the purpose of rushing forward if there is good technology that can become PART of the mainstream kernel without causing radical change in usage.
Or is this not so important after all?
Definite 2.5 material (Score:4)
It will be interesting to see how much the preemption infrastructure impacts performance (throughput) on a uniprocessor.
On a perhaps related note, I've been thinking about the growth of locks in the kernel. Many of these will have little contention, and locking is a pessimistic approach that incurs overhead. Plus, more locks means more locking discipline required.
Can we changed the article subject? (Score:3)
Read the article, as there are several paragraphs in there talking about where this code will be going. They're hoping to get it incorporated into 2.5.x NOT 2.4.x.
Re:Itching the scratch (Score:1)
Jeroen
Linus Torvalds vs. the uncoming bus (Score:5)
Francis Hwang
Re:What's with the switch to 2.4? (Score:2)
Re:Media OS and RTOS (Score:1)
Considering I can do this with a Celeron 300A (not oc'ed), I can safely assume your computer is phuX0red.
Re:Please Explain (Score:1)
I think that should read, "one trick among many tricks is how to avoid deadlocks".
To have decent real-time performance, they need to:
- Optimize interrupt handling code so that drivers get out of the handlers and into preemptible threads as quickly as possible;
- Find an efficient synchronization mechanism for dealing with multi-processor system lock issues;
- Deal with the priority inversion problem, which happens when a low-priority thread has control of a resource needed by a ready-to-preempt high-priority thread;
- Optimize the scheduler
None of these problems are new, they're just a pain, particularly when you're trying to wedge them into a kernel that wasn't really written with these things in mind from the start.Re:Flaws in the control structure of Linux (Score:1)
Re:Is Linux really open? (Score:2)
> to do with the kernel should be handed to Alan
> Cox,
Hmm. a few things spring to mind..
Don't you think Alan should have some say in what "should be handed to" him? The last I heard, he wasn't terribly happy that he was even seen as second in command, never mind first.
You don't think Linus should be in charge, but what makes you think others would be happy if someone else were?
The only reason Linus is still in charge is because he is bloody good at his job. Do you really believe Linux would have got this far if he weren't?
>
> benefit to the vast majority of Linux users
It would if it was better. Do you really think anyone would hold back on forking the code if they thought they could do a better job than Linus? I know I wouldn't
But it will certainly help on single cpu's . . . (Score:3)
While I generally prefer FreeBSD, one of the reasons is exactly the desktop responsiveness spoken of. On the same machine, I find FreeBSD far more repsonsive than Linux when using X under load. On Linux, I can feel the lag in system response at a load of about 3--even though that load is from doubly niced makes and there's plenty of physical memory left. Under FreeBSD, I've gotten to loads of 10 without any noticable degradation in response.
NOw if anyone can find a way to quantify this . . .
Re:What's with the switch to 2.4? (Score:1)
Re:Media OS and RTOS (Score:4)
For instance, the computer I'm on now is a slightly old Hewlitt Packard dual chip system. I can't even use the SMP in Kernel 2.2, it crashes on boot up when compiled in. That means I either have to choose between running the Debian approved 2.2.17 or downloading 2.4-test5 and crossing my fingers.
Right now I'm crossing my fingers. While the factors are different for other machines, the choice remains the same. Do you run your website with old-tech SMP(or none at all!) or run the risk of being slightly unstable, not fully tested, but with more modern performance?
Delaying 2.4 for 6 months or another year would really set back a lot of people dependant on the newer features of the Kernel. I don't imagine that a fully RT Kernel is going to be rolling around any sooner than that, I could be wrong, but this is a rather massive project. Just developing it is going to be a large project, fully testing it and getting it solid enough for the big-time is going to take lots of time.
Re:Linux BELONGS TO Linus, you idiot (Score:1)
Quit replying to "Jon Erikson" troll account.
--
It must be a bad crack day :) (Score:2)
Seems a couple of folks who drew moderation today took the "I am your God" comment a bit too literally, and must smite all unbelievers . . .
Re:Okay, it is impressive and nice! but (Score:1)
make like humpty dumpty (Score:2)
Of course, the penguin that gets pushed gets the best herring.
Then again, the second mouse gets the cheese . . .
which reminds me, I better go check the traps in the attic. I could have four-day dead mice by now . . .
Re:What's with the switch to 2.4? (Score:4)
Oh, except when it randomizes your hard drive and suddenly all your data gets eaten because of the truncate() bugs. But apart from that, its okay to try.
Ah, theres also the random oopses. Thats the other thing I forgot, Apart from the truncate() bugs and random oopses, its okay to try.
Whoops, I forgot the memory leaks. you have to reboot quite a lot 'cos of the memory leaks. But... apart from the truncate() bugs, the random oopses, the memory leaks its okay to try.
Eek. theres the memory corruption. It scribbles on your memory. If you can put up with truncate() bugs, random oopses, memory leaks and random corruption then it's definitely stable.
Seriously folks, get linux2.4.0test8-pre6 and test it as much as you can and submit ____proper____ bug reports of any problems. But I would _not_ reccomend using it near "real" data yet - even if you do have 2.2 to srop back to like the previous poster does. remember: fsck is not magic.
(BTW, the truncate() bug is fixed now AFAIK and I made most of the other stuff up for a laugh.)
Re:Terminology (Score:3)
Re:this is already planned for linux 2.5 (Score:3)
discussion, my understanding was that while Linus though low
latency was a desirable goal for the kernel, he thought that `hard
real time' was a bad thing for the kernel as a whole, becuase somtimes
you do need to lock the kernel to have other important features like
robustness and reliability. That ws in the context of RT linux, but I
didn't see any big changes in that attitude since.
The conclusion was that if you really needed these kinds of tiny
latencies, then the right approach was to use a derivative kernel, but
for the rest of us, it wasn't worth the candle. So I guess hard real-time isn't in the pipeline for 2.5.
Re:Media OS and RTOS (Score:1)
Which kernel version are you using? (Score:1)
The 2.4 will include some code to make the kernel more "responsive", but I suspect that this will be true only for "soft-real-time" processes (audio application).
I'm wondering if the desktop responviness will be better under 2.4..
May be, you could try using XFree86 4.x if you have a supported card, I suspect that it would help more than a new kernel release..
Are you using KDE, if yes KDE 2.0 should help..
The beauty of GPL at work (Score:1)
Contrast this with a non-GPL work, where if a single marketdroid decides to quit selling it (even if it is a good product), all the product's users are permanently and irrevocably screwed.
People can bitch all they want about the GPL, but it is clearly working to everyone's advantage here. Thanks, RMS!
b.g.
Well, that's what they do. (Score:3)
Btw, I happen to work at MontaVista Software (not their main office right now, which is why I'm kinda' out of the loop and don't have more to say about this), and can attest that they're really cool folks! <grin>.
2nd opinion (Score:1)
This is covered in the Winamp FAQ and/or help file (last time I checked), about why the music skips when someone scrolls in a window, etc
you on the phuX0red diagnosis.
But hey, it's always easiest to blame microsoft, right?
"Linus Torvaldes"? (Score:1)
Most people don't need RT support... (Score:3)
With CPU speeds being what they are today (and constantly increasing), the number of cases in which the regular schedular can't handle things correctly is really very low.
On the other hand, some of the improvements done for RT purposes (eg. finer-grained locking) help other people too (eg. SMP users).
Re:Media OS and RTOS (Score:1)
I'd dispute that to a certain degree, I think 2.4 is eagerly awaited, as the first really scalable kernel, and also for the consumer-type stuff such as USB and FireWire. Let's not start saying 'delay the kernel' now, we don't want to get into NT5/2000 territory, let's go with what we have, which is, by all accounts, pretty damn good already and getting better as the bugs and performance issues are dealt with.
Re:this is already planned for linux 2.5 (Score:3)
I gave up trying to get smp to work and just went with a NI (network-interconnect) cluster of single cpu systems. each cpu has full cache-coherency on a single cpu system [vbg]. each has its own private ram bank and spinning-disk, pci bus, etc.
with the cost of pc's these days, I really wonder if dual cpu systems even are relevant anymore.
now with something like sgi's origin systems - now THAT's a real multicpu system. but linux is far from finished for such large systems; irix, as weird as it is, still rules for that level of scalability in cpu counts.
my point is: for consumer level systems, smp might as well not even exist. its an intel hack - and a bad one, at that.
--
Ooops, not 'time sharing' anymore. (Score:1)
Has the 'nice' command been disabled? What happens when User 27 on the teletype down in the basement of the Physics building is plonking away at the keyboard and the response locks up for ten seconds? Do we really want User 18 up in the third floor of Mace Hall to be able to lock up the whole system to run that data acquistion program?
Sounds like there's some cool potential for DOS attacks here.
Re:Media OS and RTOS (Score:2)
What's a `schedule'?
"When it's ready" will suffice, not before, and any later due to continuing testing.
None of this "January 2001" crap here, please!
~Tim
--
Re:Flaws in the control structure of Linux (Score:4)
You could have ended that sentence four words earlier.
What makes you so sure the project would grind to a halt if Linus left? Very little development on this scale has been done in this way before. There is nothing in the past to compare this to that tells me Linus leaving would be a drastically bad thing. Some people (I'm not among them BTW) think it would even be good for Linux.
> Alan and Inigo fight over the "hot seat",
Do you even know these people? I don't, but I know enough about Alan at least to say that I would be very surprised to "fighting" over anything in that way.
I'm almost regretting replying to this. I almost think it's a proper troll.
I don't mean to be insulting, but all I see in what you have said is that you are afraid because you don't understand why the Linux development model works. It seems you would be more comfortable seeing a more traditional approach, but for no rational reason.
Re:I don't know much about MontaVista, but ... (Score:2)
Yeah, but can you actually use it? (Score:2)
The rep Ready Systems had some years ago with people buying real time systems is that if it visibly works in the demo, it will probably work in the product you buy. If the salesdroid talks about it working, it won't. Perhaps that's just in the Southeast US, but their reputation where I work was far from enviable.
In VxWorks one of the things we learned to do early was get the hell out of interrupt level as quick as you could. The driver I ported to VxWorks for an FDDI board, for example, basically shuffled stuff onto a ring buffer that fed the process (at high priority task level) that did the actual work. That's because interrupt level was honest-to-god interrupt level.
Please forgive my ignorance here, but is that the way people are writing Linux drivers? If not, then you're going to have a massive job of driver rewriting before preemption is actually usable for (e.g.,) cyclic schedulers like we use in training simulators and some kinds of hardware-in-the-loop simulations.
Simply turning off preemption every time a process or a driver takes a lock is a far, far cry from usable preemptive scheduling. If I need a 60 Hz scheduling event, then I bloody well need it at 60 Hz, and a pause for a few dozen milliseconds for a filesystem sync (etc., etc.) is right out.
And there was a need for a number of parallel utilities in VxWorks. For example, printf() takes a semaphore, so it's unusable at interrupt level and you have to use another function to print things out at interrupt level. Note the way VxWorks did it: it doesn't let you take a semaphore at interrupt level, which is just the opposite of what Ready is suggesting. Why? Because they believe real-time is important, and it's at the core of the philosophy behind the operating system, not an add-on.
Unless I've badly misunderstood this, it looks like preemption in Linux is going to be a toy.
Re:this is already planned for linux 2.5 (Score:1)
"Evil beware: I'm armed to the teeth and packing a hampster!"
Re:2nd opinion (Score:1)
You don't understand about Linux licensing (Score:3)
Anyway, Linux only has a few years of development left. The system we run 10 years from now will be Free Software and will contain a lot of the same tools, but might well have a different kernel. I'm surprised that people don't consider this more.
Thanks
Bruce
Re:Real Time Linux? (Score:3)
I'm about to install a more recent kernel and reboot that system. 2.4.0-test1 had lots of flaws, but it happened I don't exercise any of them and the later releases are much more stable.
If you think putting this mod in 2.4.0 is a bad idea, consider that operating systems other than QNX and Linux try to provide real-time services and are probably less stable than either in their full release versions. We've got to get the code in if we're going to get it tested, and there's really no good test but actual use. Developing something this intimate with kernel internals for 2.2.17 would waste a good deal of developer time.
Thanks
Bruce
Personality cultist! (Score:2)
HAHAHAHAHA!
I'm not even convinced he played a significant role in any major trend except promoting the TLAs: FSF, GNU, GPL, and RMS. That, and injecting a lot of moralistic nonsense into what are essentially economic and engineering issues.
Free software is not like free speech. It is like public domain text: nice to have, but not a fundamental property of a free society. Going around convincing people that it is essential is harmful both to them and to the people who have rational reasons for releasing free software.
If he was never born, the major difference would be that Emacs wouldn't be around. If he died today, nothing would really change. He hasn't really done anything significant in a long time, he just goes around as a figurehead of the "free software movement" who is hated by half of the people involved in free software.
--------
Re:Flaws in the control structure of Linux (Score:3)
RMS is a great inspiration to me. I now use and write free software because I believe in it, and this is due in part to RMS's work. However, if he were suddenly abducted by aliens I wouldn't suddenly stop believing in, using, and writing free software. In time another figurehead would emerge. There is always someone else.
Similarly, if Linus disappeared, I wouldn't stop reading the kernel source, trying to find and fix bugs and I doubt others would either, and in a short time the right person would assume his position, (probably Alan in the short term I have to admit,) it would ultimately be the best person for the job as decided by all Linux contributers. Such is the nature of the development model IMO.
Yes, of course there would be short term upset if Linus left, but there is upset in any model if the key people suddenly leave. The question is, in which model is the quickest recovery? I know where my money is.
Re:this is already planned for linux 2.5 (Score:2)
This may be gross ignorance on my part, since I've never done any realtime programming, but aren't most common RT apps designed to run on single-processor systems? MontaVista's solution is surely not the end of the journey towards a realtime Linux, but it will probably satisfy a lot of needs in the meantime.
--
I read some of this thread in kt (Score:2)
This was in kernel traffic either last week or the week before. I think that it was not added cause it was either alot of changes or it was messy code. I think also that Linus has his wants and not wants in the kernel.
I wonder if this is the start of the forking of Linux that so many have said woudl happen. May the best kernle win.
I also wonder if they are releasing there changes to the kernle as Open Source under the GPL? ;-)
~~~~~~~~~~~~~~~~~~~~
I don't want a lot, I just want it all
Flame away, I have a hose!
Re:Please Explain (Score:2)
- Linux does fully preemptive multitasking, which means that CPU time is shared by multiple processes, that each process gets his part, and that if some process waits (e.g. for I/O), his "part" will be used to run other processes in. So all in all, this is a fine "time-sharing system".
- The kernel however, doesn't do this internally (yet!). If you do a kernel call, e.g. write to a device, the kernel call is the _only_ thing that runs at that moment. If it has to wait for something, it just _waits_. Only after the call has returned, Linux starts looking at the scheduling system again.
A fully preemptive kernel means (anyway in this context), that it is also preemptive internally, so if kernel code has to wait for something, other tasks can be performed. As you might understand, a fully preemptive kernel must be _very_ sophisticated. I'm glad we're gonna get it (well, if Linus permits it, anyway
It's... It's...
Re:Most people don't need RT support... (Score:3)
Of course in the long term everything will be fast enough that clever schedulers won't be so necessary. But you could say the same of optimizing compilers, transparently-compressed network links, or almost any performance improvement invented over the past thirty years. Most of them are still with us. Even if the need will eventually disappear, there will be at least a five-year window when people will need a better RT scheduler (is my rough guess).
Re:Real Time Linux? (Score:3)
As for "preemption", QNX takes this much further than Linux does. For one thing, networking and file systems are in preemptable processes already. Beyond this, in QNX, priority is preserved through calls to services. For example, if a high-priority process reads from a file system, its I/O request goes ahead of requests from low-priority processes. This falls out of the priority-oriented interprocess communication system. It's something needed for streaming media if the machine has other work to do as well.
Re:Most people don't need RT support... (Score:2)
If you're using realtime for your videoconferencing box, you're running pretty much the following threads (depending on how the thing's designed, of course):
Network Input
Display
Video Input
Compression
Decompression
Output
With a hard real-time schedular, you can guarantee timings for some or all of these... so what are you going to do?
Be sure that your video input thread is awake in time for each frame? Doesn't do much good if compression or output are falling behind; the received video is then getting buffered (and memory for those buffers potentially being allocated... or time is being spent on frames which get dropped... or some other Bad Thing like that, depending on your design).
Verify that compression gets the CPU frequently enough to keep up with video input? First, that presumes that input is keeping up itself -- and if you starve decompression, or anyone else, Bad Things happen.
And so on for the rest of the system.
Real time doesn't give you more CPU cycles; it just gives you a little more control over where they go. Most of the time, though, this control is something which is much more trouble than it's worth. If you've got enough total CPU time to run your videoconferencing box, then it'll generally run -- whether your schedular supports RT or not.
Re:Terminology (Score:3)
Much of this is based on the OS design. The original RTLinux people looked at implementing realtime in plain old Linux, but decided it couldn't be done without massive work and risk to the API integrity. Of course, they were after hard realtime. Mainstream Linux would benefit greatly from "as good or better than Windows" realtime; hard realtime is only truely necessary for certain classes of embedded apps.
Another thing they don't mention, but should, is the need for a reentrant kernel and real, actual, useful, and working threads in Linux. This goes hand in hand with well written realtime/near realtime applications. Being preemptable is a whole lot more useful when the multitasking is far more fine grained than you have in today's Linux. Also, kernel-mode threads (as you have in BeOS and NT) are particularly useful for realtime-sensitive data.
Going preemptable shouldn't be hard in principle. (Score:3)
I'm glad that someone is taking the effort to actually do this.
Re:2.4 Kernel (Score:2)
Molog
So Linus, what are we doing tonight?
Re:Definite 2.5 material (Score:4)
Efficient Implementation of Fundamental
Operating System Services' has all kinds
of good stuff about high-performance system
software, including fairly cool lock-free
synchronization ideas.
I can't find a url for it -- Columbia University
has apparently dumped Henry's pages from their
server.
Re:Media OS and RTOS (Score:2)
with my Athlon 500 and 256 ram I cannot run an IE 5 session without getting skips out of winamp.
That's amusing, given that my Celeron 400 with 64 megs can do it fine. Hell, even my P75 can play MP3s and run Opera at the same time (just barely). There's something very very wrong here...
---
Re:Media OS and RTOS (Score:2)
cd
tar -xzf kernel-source-2.4.0-test5.tar.gz
cd kernel-source-2.4.0-test5
make (config|menuconfig|xconfig)
make dep
make bzLilo
And you're done, WITH a Debian approved 2.4.0-test5 kernel at that. It's probably not as modular as the binary release will be.. but do you really care?
---
Re:What's with the switch to 2.4? (Score:2)
Re:Linux BELONGS TO Linus, you idiot (Score:2)
Re:Which kernel version are you using? (Score:2)
It's stock debian potato with proposed-upgrades and security, except for the cvs version of lyx.
I'm not using KDE; plain old X is fine for me. I need to see how long it will take to get my new machine once ordered; I don't want to spend too much time on this one. However, if 2.4 will work better with my eepro network card . . . I have to have a script force-reloading the netwrokd with five second pauses, and I still need to power down to completely reset the card once a day (warm boot doesn't do it).
The card stayed up under FreeBSD, but I don't have the disk space for the compiles (make world and make lyx together take more space than I have . .
hmm, now that I think of it, I used to run X at a -2 nice on macbsd to solve some of these (and xfs at +2 or some such
Re:What's with the switch to 2.4? (Score:2)
Depends on your technique.
Oh wait, that wasn't a euphamism, nevermind
You know, I get a good laugh... (Score:2)
And, since I haven't posted here for awhile, and so dislike people who nit-pick an issue simply to look intelligent, allow me to take the very same sentance and explain it to you:
"MontaVista would like to see this technology, or similar technology, utilized as a foundational feature of Linux 2.5,"
"... this technology, or similar technology", referring to the preemptive structure changes and coding they have been working on. Very cool, and I think everyone can follow it this far.
"... utilized as a foundational feature", meaning they would like to see these largish to major changes made early on, either all theirs, part theirs, worked on by them, others, or a better way, whatever works out to be the Best Thing for Linux. Again, seems fairly clear to me.
"... of Linux 2.5", meaning they would like to see it begin incorporation in Linux 2.5. This seems proper to me.
As I see it, it was stated correctly, a new, and fundamentally large change such as this would be inculded in a DEVELOPMENT kernel. Hence, the term DEVELOPMENT.
A large change like this would NOT get directly incorporated into a STABLE kernel series.
You're beef seems to be more of a grammatical one than anything else. Would Montavista stating it this way have satisfied you - "MontaVista would like to see this technology, or similar technology, utilized as a foundational feature at the beginning of Linux 2.5,"? Probably not.
Long ago, I read the explanation of the versioning system being used in Linux, and understood it. And ever since, I've gotten a chuckle out of anal-retentive grammatical nazi Slashdotters like yourself who feel the need to try and show the world that they know it too.
Get over it.
And now that I'm guilty of doing the exact same thing I so dislike here, I'm moving on before I end up conditioning myself to be guilty of it more often.
Performance under load (Score:2)
For me, the difference was that make -j 27 (which help get a ludicrous load) didn't destroy interactiveness. I was able to type, etc, as if nothing else was happening on the system. This partially has to do with the atomic timeslice going from 200ms to 50ms, and partially from the general updates to 2.4. If you've not tried -test6, I suggest you do
--
Re:Kernel truly atomic on all platforms? (Score:2)
It's not interruptible when interrupts are disabled. So interrupts are disabled to protect critical regions in this type of kernel.
"Fully preemptible" means always preemptible by default, except when it isn't. The alternative is non-preemptible by default, except at certain well-defined preemption points. There have been some kernel patches proposed that add more preemption points, but I believe that a fully preemptible kernel is cleaner, more maintainable and higher-performance, when it's done correctly. SGI's IRIX works this way, for example.
Re:Real Time Linux? (Score:2)
Don't worry too much about that. It will take *months* for the dust to settle on this pre-emption patch. There are just too many parts of the core kernel that are unanalyzed and unprepared for arbitrary preemption, let alone device drivers. The VFS comes to mind.
Even with full preemption the Linux kernel can still be only a soft-realtime system. There are too many drivers holding off interrupts for unknown amounts of time, and the scheduling algorithm is not deterministic. Treat this as experimental. If you want solid, hard realtime for Linux, use RTLinux or RTAI.
--
Re:Basing it on 2.4 makes good sense. (Score:2)
You don't quite get it. (1) Linus doesn't have to provide anyone with information about linux, 2.4 or otherwise, because they can get that information themselves. It's open source, right? (2) Even Linus never knew and still doesn't know what the final 2.4 is going to be. Somebody out there is staying up all night as we speak preparing a killer patch that Linus doesn't know about. Linus will like the patch and include the patch. So much for Linus giving out prefered information to prefered collaborators. You got the wrong OS, son.
--
Re:Ooops, not 'time sharing' anymore. (Score:2)
Re:Personality cultist! (Score:2)
True, but these are just names. Other free software organizations exist, other free software licenses exist. Neither is really necessary for anything.
Free software has been around since they first let university students touch computers. It went on just fine in the public domain or with simple blanket permission-granting documents and without any central representative. The dramatic increase in free software production is a natural result of internet growth: suddenly students and hobbyists could show off their software to everyone interested in the world and collaborate with them, regardless of distance.
Without either of these there would be no gcc or GNU,
Without the gcc project sucking in most of the people who are interested in writing a C or C++ compiler, another free C or C++ compiler would have been made.
GNU is one of several "let's remake Unix in our own image!" projects. Unix was poorly marketed and overpriced, but popular, and lots of people had seen the source, so naturally someone would recreate it. FSF propaganda made GNU high-profile, thus it sucked in more programmers than other efforts.
Again, the primary difference is the names, the basic product was inevitable, regardless of the actions of any one individual.
Remember, the existence of a good, working program available freely is a disincentive to produce another one that serves the same purpose. People understand that they'll eternally be playing catch-up to the earlier project, and won't bother unless they strongly disagree with the way parts of it are done, and want to do something significantly different. With something like a C compiler producing a certain type of object file, once it is approaching compliance to the standard, the only differences are in the optimizer; even if you strongly disagree with how the optimizer is done, it only makes sense to fork the existing project (gcc, egcs).
Besides, other C compilers were written, like lcc and vbcc. You just don't hear about them because gcc is so much better. And, of course, gcc is better because the gcc project attracted the most attention at first, then once it was going, it didn't make sense to waste effort by working on others. There's only room for one great community C compiler.
without either of which there would be no Linux.
That Linus used GNUtilities doesn't mean they were necessary to produce Linux. Assuming, for the moment, that nothing like the GNU utilities that were running at the time would have existed at the time, the most you can say is that they made the early development easier. After that, I'd say Linux drew more people to work on "GNU" tools than the GNU project drew on its own before that.
Remember, Linux was based on Minix, which had a large community. Anyone who seriously undertook to convert Minix into a full-fledged useful OS would have had lots of support. There was much interest and several abortive attempts before the cheap and powerful 386 processor and the growth of the internet made Linux the successful one.
all of the *BSD's and XFree86 depend on gcc
No, they are compiled with gcc. Believe it or not, you can compile them without too much trouble with other C compilers. For the moment, let's ignore that in the absence of the gcc brand the same people would have just put their work into another free compiler project and made one of comparable quality. You don't need a free compiler to make free software. It's very handy, but not strictly necessary. Before free compilers, programmers just bought commercial compilers (or used the licensed ones at their school). These produce object files, the formats of which are documented, when you're making your own executable format, a linker isn't too hard to write (for basic utilities such as compilers, linkers, web browsers, etc. the biggest problem is conforming to someone else's standard, especially when it was "grown" in a haphazard manner).
It's amazing how many of you just have no idea how much RMS has done
It's amazing just how many of you attribute everything that's GPL'd or that has the "GNU" stamp on it to RMS. He didn't do that stuff, he didn't make it possible, he just provided some popular names (and a popular license that is the root of most license conflicts), then he went around bitching like spoiled brat when a popular piece of free software didn't include "GNU" in its name.
--------
MontaVista's reply (Score:5)
Re:this is already planned for linux 2.5 (Score:2)
Re:this is already planned for linux 2.5 (Score:2)
Re:Media OS and RTOS (Score:2)
1) Listening to an MP3
2) Coding in Visual Studio.
3) Doing graphics in 3D Studio
4) Doing textures in Photoshop.
This is without any skips from the MP3 player!
If my significantly weaker machine can do all that, I have a hard time believing that your 500MHz 256MB machine can't run IE and WinAMP at the same time. Unless you abuse your Windows installation that much, I can't see how it would happen.
Re:Linux BELONGS TO Linus, you idiot (Score:2)
Re:Media OS and RTOS (Score:2)
Re:WinAmp is not a realtime application.... (Score:2)
As for Mp3 playing being implemented under any OS, that's also false. It's not if you can play an MP3 without skipping, but how many you can play, and what load the system will take before it starts skipping. Linux starts skipping at a lot lower load than does NT, which handles a lower load than BeOS. That's just the truth of it. You can totally max you the processors in BeOS and still have the system stay responsive, while doing something proc intensive (like gunzipping the kernel archives, which can fit into main memory) will cause the system to become unresponsive.
Re:MontaVista's reply (Score:2)
---Begin quote---
I'll try to answer/respond to the most significant questions and points made here.
Re:Most people don't need RT support... (Score:2)
Remember, your CD burner has a nice fat buffer on it. You don't have to push data into the buffer at exactly the right time (which is what hard RT is for) -- you just need to be sure you push data in.
Your standard schedular is perfectly capable of giving your CD burning app all the CPU time it needs if you pump up the priority all the way -- it just won't give you the ability to decide exactly which millisecond you want that time to arrive at. Realtime doesn't make performance come out of nowhere -- it doesn't suddenly make your machine faster if you decide you want that app to have realtime priority. It may get you a guaranteed timeslice, but that's all -- and it's not as useful a thing as most folks seem to think.
Note that I'm saying this from the POV of someone running an app on an embedded system or other dedicated machine. If you're using RT as another way of setting a really high scheduling priority to deal with preempting other, lower-priority user apps... well, you're misusing it -- there are other, lower-overhead ways of doing that. If you need to be damned fscking sure that data gets read in from that device at EXACTLY THAT TIME or else it's going to be lost... well, that's where hard RT comes in. But it's really not needed for much anything else.
ack, ack, ack! I meant 2.2 and 2.0 (Score:2)
Re: No toy - But is the ship date in real time? (Score:2)
I wish them luck - the more realtime capabilities are available in Linux, the more applications can use it instead of either specialized embedded system OS's or close-enough Windows products.
Re:WinAmp is not a realtime application.... (Score:2)