Paul Davis wrote:
>
> >Kernel could also disable badly behaving driver. Once too long in driver
> >and *bang* driver is unloaded and device disabled.
>
> Ouch. You mean instrument every place where we block and unblock
> interrupts? Linus and 99.9% of the rest of the world are going to
> really love that!
Umm, yep, I can imagine that.
Forced cli/sti through specific kernel functions (as I believe is current
situation).
hard_disable_interrupt()
{
enter_tsc = rdtsc();
cli();
}
hard_enable_interrupt()
{
sti();
if ((rdtsc() - enter_tsc) > limit)
unload_module();
}
Hmm, it looks like time to do some kernel hacking...
> that are impossible to use in a low latency system: even BeOS warned
> against any use of *any* joystick driver on their kernel for precisely
> this reason. Certain MIDI implementations (*cough*sblive*cough*) could
> be considered in the same category. Are their drivers "badly behaved",
Not to even mention XFree86 4.x with some graphics cards...
> The point is to identify such pieces of code, and make sure people know
> about them, ideally to the point of someone (the original author, or not)
> rewriting the code in question and/or making sure users know the
> implications.
Problem is also to find situations and drivers that behave badly. One good
example of very problematic driver is Intel's own EtherExpress/100 driver
(e100). I've been getting alot of problems with that.
- Jussi Laako
--
PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B 39DD A4DE 63EB C216 1E4B
Available at PGP keyservers
