> Its more than a spinlock cleanup at that point. To do anything useful you have
> to tackle both priority inversion and some kind of at least semi-formal
> validation of the code itself. At the point it comes down to validating the
> code I'd much rather validate rtlinux than the entire kernel
The preemptible kernel plus the spinlock cleanup could really take us
far. Having locked at a lot of the long-held locks in the kernel, I am
confident at least reasonable progress could be made.
Beyond that, yah, we need a better locking construct. Priority
inversion could be solved with a priority-inheriting mutex, which we can
tackle if and when we want to go that route. Not now.
I want to lay the groundwork for a better kernel. The preempt-kernel
patch gives real-world improvements, it provides a smoother user desktop
experience -- just look at the positive feedback. Most importantly,
however, it provides a framework for superior response with our standard
kernel in its standard programming model.
Robert Love
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/