Re: Attempted summary of "RT patch acceptance" thread

[Bill Huey (hui) <bhuey@lnxw.com>]

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

The problem with the patch at this time is that many of the headers,
including the one you mention, need clean up as well as some
reorganization. The problem with general sloppiness of the patch from
rapid patch inclusion is different than the big event of integrating
the patch into the mainline. Also, folks like me and you in our
respective companies are much more aggressive about doing things with
the patch which is the exception of Linux kernel users and not the
norm. A little more testing wouldn't hurt as well, but I think the
patch is certainly worth getting into an semi-experimental kernel.

IMO, the patch should go eventually, but after some significant clean
up. There will be other areas in the kernel that will force some
more proper abstraction and compartmentalization.

That's my view on the matter.

bill

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