[lkml]   [2005]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Attempted summary of "RT patch acceptance" thread

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

Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits || || 1-866-677-4546
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-06-13 21:43    [W:0.134 / U:0.380 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site