Subject: Hard realtime: Directions?
To: None <email@example.com>
From: Oliver Korpilla <Oliver.Korpilla@gmx.de>
Date: 04/09/2005 12:43:27
Now that the discussion around hard realtime seems to have stalled, what
seems to be the consensus?
* 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)
* Waiting till the FreeBSD people fixed their "toothing problems" and port?
* Updating the scheduler to become truely O(1) first?
* Sticking to simple interrupt-based models of the kind "Realtime instead of
NetBSD" instead of "Realtime within NetBSD"?
What are your thoughts? Where would be your priorities?
BTW, is evolution even possible? Can large parts of the kernel remain under
biglock while others get finer-grained? In Linux it seems to have worked,
since they are gradually the kernel big lock - with 2.6.x it should be
pretty much gone, or not much of a "big lock" in all but its name anymore...
I'm very interested in where NetBSD is headed! :)
With kind regards,
Sparen beginnt mit GMX DSL: http://www.gmx.net/de/go/dsl