The future of realtime Linux in doubt

I think that's effectively saying the same thing, using soft sub-goals which mitigate a "miss". By definition of "hard" RT, being allowed to miss a deadline, makes the system no longer "hard" but "soft" so I ruled out this strategy as not meeting spec.

The idea of an "up-clocking" strategy to increase resources "on demand at cost of power" was to mitigate the inherent indeterminism of modern CPU.

I considered how you can make case to be able to meet "hard" deadlines, and assumed any "hard" RT program that risks paging from disk, waits on non predictable event, or as in Mars Pathfinder case blocking on a lower priority process due to inversion is inherently "broken" thus not "hard" RT.

This came out of considering a conversation in late '89 with an RT developer colleague of control systems. Hard RT just loved polling because of it's predictability and simplicity, never mind the performance disadvantages. It seems that just runs counter to philosophy of Linux, which appreciates performance over predictability or simplicity.

A "fast path" which conserves power, but falls back to brute force, polling of registers etc, might be a viable hybrid strategy.