Re: Debian non-x86 kernel arches
On Sat, May 22, 2004 at 01:22:16PM -0500, Troy Benjegerdes wrote:
>> I'd like to propose we attempt to build x86, amd64, ppc, and ia64
>> kernels from the same source tree. Arches like mips and m68k will
>> probably still need extra patches. But we should really be working to
>> mainline those patches.
On Sat, May 22, 2004 at 08:37:01PM +0200, Christoph Hellwig wrote:
> Even if they need additional patches there's no reason to have separate
> patches for those. There's three cases:
> (1) touches only arch/$ARCH, include/asm-$ARCH and arch-specific drivers.
> This is an absolute no-brainer and can go in all the time
There are such things as mainline merge delays for architectures, so
it's not entirely possible to rule these out, however, as an eventual
goal, I'd like to keep any variance from mainline down to critical
bugfixes whose merge into mainline is pending and that are necessary
to ship right away. This is obviously not the status quo, and I'll
do my best to incrementally convert things to this state of affairs
in the least traumatic manner possible.
But to get to where I'd like things to be without regressing, I'll have
to do work on some of the patches that have already been applied to the
debian sources and get those sent upstream and hopefully merged. Well,
actually it appears that you've taken that on for Herbert's tree and
have done all of that work yourself, so all kudos are due to you.
On Sat, May 22, 2004 at 08:37:01PM +0200, Christoph Hellwig wrote:
> (2) touches common code but makes sense for other arches
> Needs review from people knowing that area, but we have enough
> people understanding the kernel weel enough to do that review.
> And while we're at it we could just pass it upstream ourselves..
> (3) touches code and looks fishy.
> Either needs sprinkinling of idefs or if everthing else fails
> conditionally applied patches at the end of the patchkit.
> In either case we should work with upstream and arch maintainers
> to resolve the issue.
I'd say we should be even more aggressive about upstream, and eventually
either drop or rework anything not passing review there. The stability
of the kernel is too critical to entrust to patches not passing peer
review, or to forego peer review for any patch whatsoever.
-- wli
Reply to: