> Now that the discussion around hard realtime seems to have stalled, what
> seems to be the consensus?

The following is not the consensus, but just my opinion:

>>>>> On Sat, 9 Apr 2005 12:43:27 +0200 (MEST),
	"Oliver Korpilla" <Oliver.Korpilla@gmx.de> said:

> * A little bit finer-grained locking to enable preemption and later make it
> more and more fine-grained? (not all-at-once, but evolutionary, with every
> step tested out to work and regression test)

This is definitely the way to go, but the reason is not to satisfy
hard realtime requirement, but to achieve multiprocessor scalability.
(See below)

> * Updating the scheduler to become truely O(1) first?

Well, our 4BSD scheduler is already mostly O(1), isn't it?
Although it's better to make it deal with CPU affinity and
SMT aware, and also may be better to split the queues into
per-CPU ones.

> * Sticking to simple interrupt-based models of the kind "Realtime instead of
> NetBSD" instead of "Realtime within NetBSD"?

For "hard realtime" purpose, I think current interrupt-based model is
best at least while predictable future.
Unix-like kernel is too complicated and it's really too hard to
identify longest code path until a realtime process gets scheduled.
Interrupt based model is far easier to see the worst case, and
I believe this is the only doable way for some time, if you really
want hard realtime application.
Linux kernel is better than NetBSD about fine-grained locking,
but it's still far far away from hard readtime process scheduling.

If you only need soft realtime, it's different, of course.
--
soda