Side note: we could, of course, mark some spinlocks (and thus some
code-paths) as being RT-safe, and then make sure that those spinlocks -
when they disable interrupts - actually disable the _hw_ interrupts even
with the RT patches.
That would make those sequences usable even from within a RT subset, but
would obviously mean that those spinlocks have to be checked for latency
issues - because any user (also non-RT ones) would obviously be truly
uninterruptible within these spinlocks.
Every single RT person out there is already painfully aware of (and used
to) having to limit the set of functions he can use while RT, so this is
something you guys tend to be pretty familiar with..
So the "hard-RT" thing doesn't need to be a complete on/off thing.
This kind of "limited kernel functionality" tends to help only RT kernel
modules, though. Full system calls (except the trivial ones like
"getpid()", of course) simply tend to have to require too much "real"
infrastructure that they can't use the RT subset.
Also, some people will he happy to know that soft-RT ends up getting
continually improved, and many people might be able to find that just the
regular preemptible kernel gives good enough latency at least if you can
limit the workload on the machine (which, on embedded devices tends to be
somethin gyou take for granted anyway).
That may not make the hard RT people happier, but at least it might shrink
the number of the die-hard hard RT'rs.
"If you can't beat them, try to make them extinct" ;)
Linus
-
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/