Re: Attempted summary of "RT patch acceptance" thread

[Karim Yaghmour]

Paul E. McKenney wrote:
> OK...  Then the idea is to dynamically redirect the symbolic link
> to include/linux-srt or include/linux-srt that you mentioned in your
> previous email, or is the symlink serving some other purpose?

What I'm suggesting is that rt patches shouldn't touch the existing
codebase. Instead, functionality having to do with rt should be
integrated in separate directories, and depending the way you
configure the kernel, include/linux would point to either
include/linux-srt or include/linux-hrt, much like include/asm
points to one of inclux/asm-*.

> So your focus is on system calls that can have totally separate
> realtime and non-realtime implementations?  Or am I missing some
> trick here?

There's no trick. It's just a layout thing. Hope the above
explains what I'm trying to say.

> How are you and Kristian looking to benchmark/compare the various
> combinations you call out above?  Seems like one would have to look
> at more than straight scheduling/interrupt latency to make a reasonable
> comparison.

I'm not sure that benchmarking would be relevant. This is just a
integration/layout/configuration/build suggestion. I don't think
that this organization will change anything to the benchmark
results.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@xxxxxxxxxxx || 1-866-677-4546
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/