Re: Attempted summary of "RT patch acceptance" thread

[Paul E. McKenney]

On Mon, Jun 13, 2005 at 01:03:53PM -0700, Daniel Walker wrote:
> On Mon, 2005-06-13 at 15:49 -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 think this is mistake. Projects that create separation like this are
> begging for the community to reject them. I see this as a design for
> one, instead of design for many mistake. From what I've seen, a project
> would want to do as much clean integration as possible.

It depends on the details of the situation, right?  For example, it
would not have made sense to integrate RCU into spinlock.h, where most
of the other Linux synchronization primitives live.  On the other hand,
spinlock variants, such as spin_lock_bh(), are integrated into the same
spinlock.h file as the the base spin_lock() functions.

For example, CONFIG_PREEMPT_RT separates out some of its realtime function
into separate files (e.g., kernel/rt.c and include/linux/rt_lock.h),
while other parts of its realtime function are integrated into the rest
of the kernel.

						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/