These negative characteristics bleed into other areas like security and modularity — supporting RT is not the only goal of this OS. Basically I think that innovations in the OS space are hurting from the fact that no one can justify investing the resources to wipe the slate clean and start over. Companies that did (BeOS) came up with some really good stuff, but the applications problem was too high a barrier and they eventually shriveled and died.

Yes, the driver problem is obviously huge. All I can hope is that if I deliver something compelling enough, it will drive people to invest the work of porting ALSA drivers or something. Or if there’s an embedded device that wanted to use the OS and will have to write drivers for their new hardware *anyway*, they can write drivers that work with my OS from the get-go.

This is obviously very hand-wavey. I’m working on this on my own time, and my approach/motivations are somewhat of a mix between academic and commercial. I want to really break new ground by integrating a lot of good ideas that are floating around in academia, but I also want it to be a usable system. Whether I can convince anyone *else* to use it is totally unknown, but I have to try.

it also models IRQ lines as processes (well, strictly, as kernel threads). the thread doesn’t get run just because the IRQ line was raised, its scheduled along with everything else, just as you describe for L4.

you’re also slightly wrong that interrupts are not demands. from many devices, thats true. for audio interfaces, its not true. the interrupt is a *demand* for more data. you don’t meet the demand, the device “malfunctions” from a user perspective

you might not like that linux started out as so-non-RT and requires a substantial patch to make it so. but … more and more of Ingo’s work is now in the mainstream kernel, and his work does actually create a system where, given correct IRQ thread priorities and no drivers with absurd code in their interrupt handlers (yes, its prioritized but it can still do wierd, illegal stuff), you can get hard realtime from 2.6.

starting a new OS based on L4 to accomplish this seems basically nothing more than a self-learning experience. an RT OS is useless without drivers and the driver situation on linux is bad enough already. it is guaranteed to be at least as bad on anything you eventually cook up.

Interrupts are not demands, they are notifications. Sure, you might starve hardware by not listening to these notifications, but they are nothing more than tools for getting information about external stimuli as soon as possible.

IRQ lines in L4 are modeled as processes, and interrupts are modeled as IPCs from those processes. The priority of the drivers that subscribe to these IRQ lines determines whether they preempt the currently running thread when an interrupt comes in. So in that sense, L4 already provides what Ingo’s patches do.

The specifics of how the system should behave when an interrupt comes in are more complicated than belong in a blog comment. But the point I want to leave here is that my plans are to give user-space programmers as many tools as possible for designing robust systems, and for the OS never to be the bottleneck. Nothing you’ve written gives me reason to believe I cannot do that, or that I fundamentally misunderstand the problem space. I’ve been thinking about this a lot, and I think my ideas have merit.

When a computer is working, at least when it is dealing with handling real-time streaming of continous data flows, it is trying to satisfy *two* masters: the user and the hardware.

the hardware places demands on the CPU by interrupting it. when it does, the OS has to decide what to do. interrupts can be blocked, handled by just noting that they happened, or fully serviced.

if your Very Very Important Super-Dooper RealTime Application is in the middle of its work when an interrupt arrives, what should the CPU do? Should it waste cycles servicing it? Should it block interrupts? Or something else? It appears after a little thought that the correct answer depends on what the interrupt was from. If your VVISDRT application was processing audio, and the interrupt was from the audio interface, you should probably handle it, because it probably implies that you’ve missed some deadline. Or might. But if it was from the keyboard controller, you can and probably defer doing much more than noting that it executed.

Ingo’s latest RT patches basically allow you to configure even interrupt handlers themselves to have scheduling priority at the same level as application threads.

There is much more here that you are wrong about, but alas I don’t have the time to comment further – I have to get back to writing real time audio applications, which amazingly enough, actually work.

For the first post in Josh’s new blog I figured I ought to lay it all on the line. My essentially disagreement with Josh isn’t technical so much as philisophical. Now I may from time to time try to pretend like I’m moving at this problem from a unbiased technical perspective, but I thought I’d lay things on the line from the outset. I can pretend to be objective later.

The things that seem to stress Josh about about technical things never really seem to be particular problematic to me, and this is especially true of waiting for stuff. It seems crazy to me. You know how when you’re at line at the bank, and you’ve been there for *for-ev-er* and then you notice two perfectly good tellers hanging in the break room talking about last night’s American Idol episode? My opinion is that if you let that annoy you you’re gonna spend a lot of time angry in banks. Talking about American Idol is part of bank teller’s jobs too, you know?

What I really don’t want to do is have my OS allow me to allocate resources as precisely as possible and then respect these allocations. I don’t even know how much RAM any of the 3 computers in my house have.

Next time you’re sitting there being annoyed by how slow your computer is being, do what I do: grab a magazine from your nearby stash (I personally like hardcore porn but it can be about efficient realtime OSes if you really want…whatever gets you off) and “browse” for about 20 seconds.

To your first point: there are ways to mitigate this. You might configure a system policy where your real-time thread gets absolute first priority, BUT only for 20ms every 40ms. The goal of the OS should be to allow the system owner/administrator to allocate resources as precisely as necessary, and to respect those allocations as fully as absolutely possible. If you can write an audio thread that promises to only use 20ms every 40ms, then you can give that thread the guarantees it needs without starving the rest of the system.