What's in a Kernel?

Recently my cohorts Paul Parkinson and Doug Gaff have been making a bit of noise about changes in the software industry - evolution of software, and specialized software for military and commercial avionics,and other applications that have strict time and security requirements.  Aside from requiring strict adherence to standards, critical systems software - especially medical or flight related - have an increasing litany of certification inspections it must pass.  In the secure-systems markets the same trend is evident.  Each of these markets are starting to require time- and space- critical systems.

Let me define time and space critical. 

Time critical is pretty straight forward - anything that has to be done within deadlines, is time critical. Sometimes time-critical functions are also periodic in nature, requiring periodic service with deadlines.

Space-critical is a bit more slippery.  This is about RAM, but not just "how much".  I'm talking about space in terms of RAM that other processes are protected from, and RAM that is protected from this process, and even memory shared between processes.

There are a lot of examples of time critical periodic applications.  Any aspect of handling telemetry - course, attitude, velocity, housekeeping (checking fluid levels, etc) - has time critical periodic attributes.   It's easy to think of time-critical tasks.

Space-critical is a little more elusive to both define and decide where to use, especially in embedded and real-time applications.  The answer to time-critical is somewhere between having fast enough hardware, efficient enough software, and proper scheduling. Protecting memory areas on a process-by-process basis has excellent benefits, but those benefits usually come at a cost of slower execution.    Sure, you never want your stack to be overflowed, your text to be zero-cleared, or your exception table to be  the victim of an uninitialized data pointer, but when is the trade-off in execution speed penalties worth the  overhead of enabling such protection?  The answer has more to do with security than with protection from poorly-debugged code - the separation, multiplexing, encoding, decoding and proper sorting of information streams.  There may be situations where every function of your application must have it's own data spaces because of the nature of the data being handled.  In fact, this kind of design is becoming more common.

It seems like it would take a fantastic amount of processing power to be able to do what's described above - guarantee on-time scheduling to handle deadlines, and mix-in varying levels of RAM-security, and still provide all the services and infrastructure necessary from an O.S. to build effective applications on-top of.  Even though processors are being created now with incredible horsepower, it wouldn't seem like they could keep up with much of this kind of work.  All that partition scheduling and context swapping would bog down the best of processors if it had more than just a few partitions and contexts to handle!

...or would it?

Come on down to the Regional Devlopers Conference in Manhattan Beach (Los Angeles) on May 24th, and we'll talk about it.  :-) See you there!