Re: Attempted summary of "RT patch acceptance" thread

[Paul E. McKenney]

On Mon, Jun 13, 2005 at 03:49:08PM -0400, Karim Yaghmour wrote:
> 
> 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-*.

I would guess that the end result would be a mixed strategy, where some
things (e.g., the existing CONFIG_PREEMPT) are intermingled with the
rest of the Linux code based, while other things (e.g., nanokernel
implementations) are in separate directories.  But this is quickly
getting -way- outside of my area.

So I must leave this aspect of the discussion to others.

> > 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.

OK.  However, should the discussion get to the point where something
like RTAI-Fusion has realtime versions of system calls that have
globally-visible side-effects (such as I/O, networking, IPC, ...),
then the issue of how to get the non-realtime and the realtime variants
to play nicely with each other will arise.

It may well be that system calls containing such side-effects need to be
Linux-only, or maybe someone will come up with the necessary tricks to
make it all work nicely.  Not particularly worried about it myself --
yet, anyway.  There are plenty of things to worry about before we get
to that point!

> > 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.

Sorry, side issue.

I was responding to your list of combinations of CONFIG_PREEMPT_RT, Adeos,
and Fusion, assuming (probably incorrectly) that you and Kristian were
looking to compare all the possible combinations.  If my assumption is
incorrect, then my question was irrelevant, and I apologize for the noise.

						Thanx, Paul
-
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/